NYCPHP Meetup

[Rob Marscher]

I currently use Smarty on a couple projects.  I didn't make the 
decision... but I certainly don't mind using it.  We created a theme 
system so that there's a folder with a default set of Smarty 
templates... but for each different site we run off the same backend 
install, we can specify a different theme folder and our view will look 
there first to get the template and then go to the default folder if it 
doesn't find it.  This allows us to run sites that can have extra copy 
in the templates or pieces removed or whatever we want and none of the 
main set of code needs to change.  Smarty has an easy to use caching 
system and I like using the variable modifiers to do things like 
truncate text, capitalize strings, and format dates.  Also the custom 
plugins can be pretty handy... we have one that iterates through a adodb 
record set.  We had an html production guy come in to do some work and 
he had no problem using the Smarty templates.

Obviously there are tons of templating systems out there and I see the 
point about a compiled template system vs. one that's already in php.  
Personally, I don't find all the <?php ?>'s to be asthetically 
pleasing... but that's a sorry excuse =)

On the note of OO vs. procedural, after switching to OO-style php two or 
three years ago, it's hard to imagine now not having at least the 
encapsulation and reuse that comes with it.  I agree that for small 
sites, procedural code can be written faster... but if it's something 
you'll reuse on other projects or if you're on a team of developers, 
there are major benefits of using OO code.  It might seem to be a big 
pain to be switching files all the time, but a good editor will make 
that easy for you.  The whole idea is to reduce the amount of code you 
have to write and make it easier to incorporate other people's code into 
your project.  The term that keeps popping in my head is "Set it and 
forget it."  Anyway... this subject has been beaten to death.

-Rob

Tim Lieberman wrote:
> Mikko Rantalainen wrote:
>
>   
>> The only thing you need to change for different rendering of the 
>> above data is to set $class variable to another value. I don't 
>> understand how many different ways there could be to encode that 
>> same information in XHTML. Therefore, I don't understand the need 
>> for templating engine to generate/modify that part of the source. To 
>> me, the only question is what solution has the best performance? A 
>> template engine is seldom the correct answer.
>>  
>>
>>     
> I use Smarty extensively, but mostly as part of my ad-hoc framwork for
> rapid development, along with DB_DataObject. 
>
> I wrote a little subclass of PEAR's DB_DataObject that I call
> DB_DataObject_renderable
>
> The subclass provides two new methods to DataObject: 
> render($tpl,$extra=array) and renderlist($tpl,$extra=array).
>
> render() (sometimes) pulls in related table via getLink() or getLinks(),
> assigns object variables, plus the contents of the $extra hash, into
> smarty, and then returns the result of Smarty->fetch($tpl).
>
> renderlist() iterates over $this->fetch() (where this is essentially a
> DB_DataObject), concatinating the result of
> $this->render($tpl."_listitem.tpl") into a string, then passes that as
> $extra['listContent'] into $this->render($tpl.".tpl"). 
>
> Keeping with DB_DataObject's convention of an object being both a
> "current record" and a "record set", and with all the handy getLinks
> stuff, which is nice for pulling in lookup-table stuff, you have a nice
> way of rendering either a record or set of them.
>
> For clarity's sake, if I want to show a form, I might have a template
> called "form.tpl".  If I want a table of records, I might have a
> template called 'adminlist.tpl', and one called 'adminlist_listitem.tpl'. 
>
> 'adminlist_listitem.tpl' might look like:
>
> <tr><td>{$id}</td><td>{$name}</td><td><a
> href="edit.php?id={$id}">edit</a></td></tr>
>
> 'adminlist.tpl' might look like:
>
> <table class="someClass">
> <tr><th>ID</th><th>Name</th><th>*</th></tr>
> {$listContent}
> </table>
>
> While this example is trivial, the pattern scales well to various
> things.  And if you need even more "extra" data, it's easy to override
> the render() function in the class files autogenerated by DB_DataObject
> to pull in the ... weird ... stuff.
>
> -Tim
>
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
>
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
>
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php
>
>