Jochem Maas said:
1. 'Template Engine' - you can justifyably call PHP a template engine
Correct. Seems that Smarty is, for the most part, redundant (see my last post called "PHP makes a great templating engine (Was: smarty)").
I was not intending to pronounce Smarty redundant; on the contrary if anything - but thats not the point...
but I think calling Smarty a template engine confuses the issue - it would be clearer call it something like 'Presentation Component' which encapsulates output caching, output string transformation, markup generation, presentation logic security & seperation of (code & possibly human) tasks. viewing it as a component means viewing it as a tool, tools are used when appropriate and according to their capabilities and the scope of the job at hand. in principle a sizeable proportion of all the.
Tool. Look at it as just another tool. I was seeing it as a "must have" because I was somewhat ignorant of PHP's native capabilities. It adds complexity and does indeed slow down your program (the Smarty class must load on every page) so keep those in mind. On the other hand, you're
the Smarty core is smaller than, for example, PEAR::QuickForm (if you use all the plugins its about 40% larger) - and PEAR::QuickForm is usually used with a Renderer (e.g. Smarty!!), think of it like this: how much do you charge per hour, what does an extra CPU cost & how much, if any, time does Smarty save you. (besides which I think its quite easy to develop something in Smarty which does what QuickForm does but more transparently and with alot less hassle - IMHO).
Code is code; it might not be perfect but it might scratch an itch.
almost forced to separate business and presentation and you gain caching
Smarty does force that at all; you have to make the distinction and apply liberal self-restraint.
(though native PHP options or Zend are available). So it's a weighty decision. But it is a good tool.
Realise that Smarty (usually) only re-compiles the template if it changes. The compiled template are full of generated PHP - there is little overhead in including that.
if you use a native PHP option then:
a, what is Smarty? (not important!)
b, what are the chances that your output code/module/class/etc will
not employ similar solutions to something like Smarty? because broadly speaking
3. 'Lock In'
I believe "Lock In" is a big problem unless you document well. For
instance, my supervisor is probably going to choose ASP.NET (don't ask
why) for our next project. But all along, I plan to document it well in
case we hit a stumbling block. With a bit of effort and the source code I
can port it to PHP. I've even toyed with the idea of keeping a
fully-functional copy written in PHP while he's working in ASP.NET ;-) But I've got better things to do.
Limitations are often purely percieved rather than actual
I believe that's why I chose Smarty for my last project. I thought PHP limited me to keeping business logic mixed with presentation logic, but it's hardly the case.
and funnily enough Smarty is actually a pretty good example of a possible PHP based solution to the problem logic seperation.
When you consider that it's just another tool in your box, it works well. It's not the only way to let designers design and programmers program
(Jochem is a big believer in CSS for that). Just think of it as another
PLEASE WORLD: GET BEHIND CSS, AND FREE CONTENT FROM STYLE ON THE CLIENT.
why because it allows the structrully mark-uped to be display more flexibly, for diff. display, aural readers, braille etc. removing the styling definitions it also allows you to specify different markup.
Ever written a print version of a page? why bother when all you need do is specify alternative stylesheet(s) to use for print media.
Ever heard you page say 'IMAGE' 'TABLE' & 'DATA CELL' 50 odd times as a blind persons screen reader trys to make sense of your pretty new data-driven creation... where the f*** is the menu?! did you know there is even an extensive specification for markup of aural media (e.g. tone of voice, male/female, speed etc etc)
In my little world I have officially declared a Good Thing. of course
it leaves the problem of how to manage all those stylesheets effectively. something PHP might be able to help with.
my best shot so far at seperating the style from mark and creating something (vaguely) valid (don't think the w3c validator is 100%) & crossbrowser compatible (no doubt its not :-S). it quite image heavy - backgrounds, headers, graphic mouse-overs, 'quotes' etc but if you look at the HTML source you'll see its quite devoid of any 'imagery':
http://www.oneworldtrade.nl/
-- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
