RE: Re[2]: [PEAR-DEV] Contribution for PECL

> -----Original Message----- > From: Katana [mailto:katana@katana-inc.com] > Sent: Saturday, December 28, 2002 3:50 AM > To: Maxx > Cc: pear-dev@lists.php.net > Subject: Re[2]: [PEAR-DEV] Contribution for PECL > > M> php_templates' synthax is very simple because it keeps Presentation > M> level free of any kind of logic, leaving it for the Code (Business > M> Logic) level of an application. I would call it a Classical > M> approach to N-tier architecture. > > M> Smarty is a one of the best engines I've ever seen, but it has a > M> totally different ideology of templating, and can not be compared > M> with php_templates. Despite of the fact that it has too much code > M> to be parsed for every request, and therefore needs something like > M> ZendCache to be installed on the server for faster work, this is a > M> one of "language inside of a language" projects. You still have to > M> be a programmer to create Smarty's templates. > > Did you read Monte's "why use smarty" page on smarty.php.net ? It > explains quite well why trying to have "no logic in the template" is > useless... You NEED logic in your template. If it's not in the > template, it's in the code, and if the design depends on this code, > then you don't achieve the layout separation you were using templates > for. Final dot as far as i'm concerned... Yeah in theory the designer should be able to do anything. I mean why should he be locked in when he has some nice interface idea? He should be able to do anything! Wait a second ... isn't the designer then the programmer? Ah yes he is. Is this a good idea? Maybe. For everybody? Probably not! If there is something missing from the package that the designer needs in my company he goes to one of the programmers and asks for this feature. Actually I even have designers that also program, but when they design an interface I don't want them wearing their programmers "hats", because in that situation I want them to be thinking how they can make the users life easier and for that its best not wearing a programmers "hat". Finally I want to keep custom programming to a minimum. I want as much logic to be in the php module. Different behaviours should be controlled by configuration scripts. And each template should only have a minimal amount of differences from one customer to another. That why upgrading is much easier. This is just my opinion. But so it goes. I would only use Smarty if it had 10% of the features. Not because I think its slow because of he additional 90%, but because I think the additional 90% have the potential to break this workflow. So far I have not decided it would be wise to fork Smarty to Smarty Light. Regards, Lukas