Re: [SMARTY-DEV] case-insensitive plugins

and as i posted: smarty is case-sensitive to *any* content outside the tags (it doesn't touch it, only if explicitly asked to do so). so it is a good clear and consequence to treat the inside of the tags case-sensitive also. the designer editing the template doesn't care how php sees it's things. he gets the tags he uses from the smarty-manual or gets custom ones from his programmer. and i'm sure he wouldn't swallow if the programmer comes with two new funcions "{foo}" and "{FOO}". he will get his baseball bat and the programmer will get hell. so potential problems regarding the subjective limitations of the php-function-name-space versus smarties plugin-namespace will be solved biologically. (and in theory both namespaces are of equal power anyway) sorry for you wom.bat. i see pretty good reasons to change this back, far more reasons than to keep it. it was't done in rush, but wasn't backed out in a rush either. On Tue, Apr 29, 2003 at 03:02:40PM -0300, luis wrote: > 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