RE: [SMARTY-DEV] case-insensitive plugins

From: Date: Tue, 29 Apr 2003 18:02:40 +0000
Subject: RE: [SMARTY-DEV] case-insensitive plugins
References: 1  Groups: php.smarty.dev 
Request: Send a blank email to php-smarty-dev+get-1303@lists.php.net to get a copy of this message
While it is true that Smarty can be used to produce many different presentation languages it is also a known fact that most interfaces will be HTML based that's why XHTML is important. Smarty functions generating HTML already support XHTML and it's clear that that's good. That's why IMHO if XHTML is case-sensitive Smarty syntax should also be case-sensitive, Smarty is more related to XHTML than PHP you mix Smarty syntax with XHTML constructions not with PHP code (or should not). If template writers learn that {FOO} is wrong and {foo} is right they will understand that <B> is wrong and <b> is right. That's one of my reasons for case-sensitiveness: consistency with presentation languages embedding Smarty. Other presentation languages based on XML like WML are also case-sensitive. -----Original Message----- From: Wom.bat [mailto:wom.bat@gmx.net] Sent: Tuesday, April 29, 2003 2:56 PM To: messju mohr Cc: smarty-dev@lists.php.net Subject: Re: [SMARTY-DEV] case-insensitive plugins mhm... well... but why? nobody except of Andrei complained (and he didn't give convincing points against this), nobody reported problems! {foo} will call smarty_function_foo, {FOO} will call smarty_function_foo, with the patch, and without the patch, only file names differ. this is just not logical! it's against what you would think as a PHP programmer, and we are using PHP here, and Smarty is NOT imitating PHP or whatever if it handles function calls the same. Actually, case-insensitivity are the ONLY way to make function(,modifier,block,blaaaah) declarations transparent. I declare them at my will, and I use them at my will, and they are stored in lower cases. There are programmers who use underscore notation, and so they do {please_do_something}, while those programmers who do this camel notation would TRY to do {pleaseDoSomething}. This is not in any way bad style, it's just the RIGHT style to sustain coding conventions trough the ENTIRE project. And templates are part of the project, so if I declare a damn smarty_function_pleaseDoSomething() I want to use {pleaseDoSomething} in templates. Sure you might well say here, that all plugins and built-in elements of Smarty use underscores, so I should do so, too, and you'd be right. But it's not logical from a developer's view, that Smarty behaves different from PHP here. It calls the same, LOWER-CASE, function. PHP doesn't forbid to talkNonsense() though it handles it as 'talknonsense' internally. So why does Smarty? Believe it or not - out there are people who don't throw their custom functions into the plugins dir, but use for example object methods. And these people probably need this case-insensitivity feature, for example I, for example, need it, because I have plugins in a class, named after certain rules, and then use a get_class_methods() with a preg_match to automatically register all plugins I drop into this class. And it is NOT, in NO WAY "unnecessary featurism". This does NOT make Smarty heavier, and Smarty is - in my eyes - far away from "being too full of features that hardly anyone uses". We don't have a simple "replace-this-funny-token" piece of code that calls itself that bitches itself a "template engine". Smarty is the only serious solution if you want to seperate presentation from application logic. I take modifiers as an example. Modifiers are NOT dispensable or whatever. They are NOT overkill. Modifiers are indeed the only serious method to ensure that you don't need any PHP code to specify how this timestamp shall be formatted, or anything else. The only thing that, in my eyes, doesn't fit into the distribution are these html_* functions (but they are standalone plugins anyway) messju even said "it wasn't done in a rush. it was carefully decided and now committed", and now it's changed back, and I can't see even one GOOD reason for this revert. Just my 99 cents, David P.S: this discussion about XHTML and it's case-sensitivity was WORTHLESS, because it doesn't have _anything_ to do with this discussion. ----- Original Message ----- From: "messju mohr" <messju@lammfellpuschen.de> To: <smarty-dev@lists.php.net> Sent: Tuesday, April 29, 2003 7:01 PM Subject: Re: [SMARTY-DEV] case-insensitive plugins > okay, i backed out the patch for case-insensitiv tagnames. > > as i said, anybody should tell me, if he has problems with it, that > was to be taken for granted. to me it makes no differences. i don't > use mixed, or studdly capsed or uppercase tags, anyway. > > the change was intended as a precaution against the problems that may > occur if smarty disinguish case in it's plugin-names, but php does > not, since plugin-names are mapped to function-names. > > but the source for potentional problems tends from null to tiny, > against the impact that a change in the case-handling seems to have > for the majority of us. > > i appreciated the feedback. it's far more productive to complain early > than being silent to be just whining some months later, how beautiful > the past was, and how things turned bad. > > greetings > messju > > -- > Smarty Development Mailing List (http://smarty.php.net/) > To unsubscribe, visit: http://www.php.net/unsub.php > > -- Smarty Development Mailing List (http://smarty.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

« previous php.smarty.dev (#1303) next »