[nycphp-talk] To Smarty Or Not to Smarty: That Is The Question
rmarscher at beaffinitive.com
Wed Sep 6 11:00:09 EDT 2006
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.
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
> 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:
> 'adminlist.tpl' might look like:
> <table class="someClass">
> 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.
> New York PHP Community Talk Mailing List
> NYPHPCon 2006 Presentations Online
> Show Your Participation in New York PHP
More information about the talk