This could end up a heated debate, so jump on in and get your feet wet. Originating from a response to: [Q] Development Best Practices
On Tue, 2003-11-18 at 09:09, Luis Lebron wrote: > Before considering using templates you may want to take a look at > > http://www.phppatterns.com/index.php/article/articleview/4/1/1/ > You might want to take the above article with a HUGE grain of salt. It over generalizes and pretty much slots all template systems into the same category. One of it's large claims is the overhead of the template system itself and that PHP is a templating system itself. First off I'd like to agree that PHP "can" be used as a templating system, but providing some of the functionality available in many of the dedicated template frameworks will require you to jump through hoops (often jumped through for you by Smarty or InterJinn, or <insert templating engine here>, and once again you, or your designer will be using PHP (fine if that's ok with you). The argument that there is performance loss from the template system strongly depends on the the model used. For instance in my own (yes I have my own so I am probably biased, but I make logical arguments here that you can feel free to debate) the templates are compiled to pure PHP which results in a performance gain since many content includes no longer need to occur at run time. Arguably there is a bit of performance loss in InterJinn though since it is also an application framework and thus has a lightweight architecture to load first. But InterJinn can be used for templates without the application portion and in those cases would outperform templating via PHP using the below style: <?php include_once( 'someHeader.php' ) ?> Now to address the supposed "Deadly Sins of Templating" as layed out in the following link: http://www.phppatterns.com/index.php/article/articleview/4/1/1/ "PHP is too complicated for web designers. They just want HTML!" ---------------------------------------------------------------- Here the author attempts to prove that because Smarty offers conditional steps that you have reverted back to rewriting PHP. To some extent you have, but really, conditional operators are provided to allow display logic (not to be confused with business logic which is what the author mixes it up with). Generally speaking you should not have a lot of display logic, but regardless, it is specific to the content, not to any database queries, news feed parsing, etc. etc. In my own case of interjinn I also supply very limitted conditional tags (I created a tag system since it reflects the HTML style): <jinn:if name="authenticated" test="$GLOBALS['authenticated']"> Some content for authenticated users only. </jinn:if> <jinn:else name="authenticated"> Content for non authenticated users. </jinn:else> This style allows any PHP expression in the test attribute, but the framework also allows retrieval of complex data saved within InterJinn components via the embed syntax. "It seperates code from content!". ---------------------------------- Here the author argues that the code and content are not separated. Once again he attempts to confuse the reader by implicating the use of loops as business logic, which once again is not true. Simple looping over the contents of an array to format the contents is display logic, not business logic. However if you were to iterate through a series of URLs and retrieve the data then display it, that would be business logic. here the author also argues that the template HAS to interact with the code, this is not true, the content should only have to interact with the data. I'll give credit to the author that most template system do need to interact with code at some point, but once again InterJinn does not. For instance in Smarty you need to load a new Smarty object, populate the object with data, then tell the object to render a given template. In InterJinn the approach is reversed. You include modules and components into your template via tags, then you can access data in the component via tags. The components know nothing about the template in which they reside. The following example illustrates this: ----------------------------------------------------------------------- <jinn:module name="displayNews"> <jinn:component type="logic" name="manager" source="//InterJinn/modules/news/manager.inc" /> <jinn:component type="render" name="render" source="//InterJinn/modules/news/dhtmlPopup.inc" /> </jinn:module> ----------------------------------------------------------------------- The above is one style which would generally have the entire HTML output for the news feed to be output via the render component; however, the following micro managed style would also be available if the component sets up the data: ----------------------------------------------------------------------- <jinn:module name="news" noRender="true"> <jinn:component type="logic" name="manager" source="//InterJinn/modules/news/manager.inc" /> <jinn:component type="render" name="render" source="//InterJinn/modules/news/dhtmlPopup.inc" /> </jinn:module> The following news articles were retrieved today:<br /> <table border="0" cellpadding="3" cellspacing="0"> <jinn:foreach name="feeds" value="{jinn:getValue name=feed}"> <tr> <td>{jinn:getValue type="foreach" name="feeds" path="title"}</td> </tr> <tr> <td>{jinn:getValue type="foreach" name="feeds" path="title"}</td> </tr> </jinn:foreach> </table> ----------------------------------------------------------------------- As you can see from the above, no business logic exists, only content logic. And all data is manipulated via tags or embeds. Admittedly though, this is possible because of the relationship between the InterJinn framework and the TemplateJinn framework. Smarty and many others don't really have this luxury. To go even further with the above style, InterJinn allows the creation of custom tags. So if the development team really wanted to make things easy on their content team, the could create the following tag: <acme:newsFeed /> Which would expand to: <jinn:module name="news" noRender="true"> <jinn:component type="logic" name="manager" source="//InterJinn/modules/news/manager.inc" /> <jinn:component type="render" name="render" source="//InterJinn/modules/news/dhtmlPopup.inc" /> </jinn:module> And subsequently be expanded to PHP code. In case you didn't know before InterJinn allows tags to render tags, to render tags, ... This is very powerful since even complex content can be simplified. Now onto the next point to argue against. You can cache your templates to improve performance!" ----------------------------------------------------- This point is a good point for any template framework that doesn't compile to the actual page retrieved by your web server. Since InterJinn compiled templates to the pages your browser will serve, this is a non-issue and as stated before, makes InterJinn faster even than using PHP include statements. "It makes my application easier to maintain!" --------------------------------------------- The author doesn't state much on this point, just asks a few questions, possibly to try and get the user to infer that they have more maintenance. That's another huge misnomer. The number of templates doesn't really have much to do with maintenance, at least not as much as digging through a mixed HTML/PHP file to hunt down your bug. Also if you properly organize your PHP code because you've decided to use raw PHP as a templating system, then you'll find you have lots and lots of files too because your trying to do all the hurdles that a nice organized templating framework does for you. So the question is: how many PHP source files do you have exactly? Admittedly, the author does have a bit of a point about debugging a template, but then that assumes you've got all kinds of strange logic in your template, which probably means (though not always) that you're not using the templating framework properly or you'd be better off with a different design. PHP Templates! -------------- Here the author makes an unprovable claim: "Everything you can do with templates you can do better with PHP and include() or eval()". From his very words you can see the inefficiency in the approach, include() and eval() both require run-time evaluation. Then the other goes on to suggest using fopen(), man this guy is going to take forever to create his site, sounds like he's missing something that would probably be done better in a templating engine. The Bottom Up Approach ---------------------- The author now states that "templates come from the idea that you probably design your user interface first then match your application to it". Hmmmm, I think he's full of it. Personally I designed InterJinn and the corresponding TemplateJinn to meet my desire for pluggable components, better efficiency, and encapsulated logic via custom tags (since I'd rather do custom tags backed by PHP code than by XSL). The author then goes on to say: "how many PHP coders can honestly say they work daily with a web designer who does all their HTML dirty work for them?". Is this really a valid question? What happens tomorrow when your site needs to be redesigned but it's all PHP sprinkles with no concept of separation? You'll probably need to rework every single page since the pages include their header templates and footer templates. With InterJinn you would probably only need to modify the template, since content templates are mixed into a master template via a pattern declaration. ==================================================================== In conclusion I'd just like to say that even if you don't use a templating framework, at least you will have read a second point of view before making your decision. Whether you use PHP, InterJinn, Smarty, FastTemplate, BTemplate, etc, etc, should not be an issue if you are making an informed decision. Cheers, Rob. -- .------------------------------------------------------------. | InterJinn Application Framework - http://www.interjinn.com | :------------------------------------------------------------: | An application and templating framework for PHP. Boasting | | a powerful, scalable system for accessing system services | | such as forms, properties, sessions, and caches. InterJinn | | also provides an extremely flexible architecture for | | creating re-usable components quickly and easily. | `------------------------------------------------------------' -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
