NYCPHP Meetup

[Peter Sawczynec]

Rob: 

I believe that your comments revealed compelling reasons to go a Smarty-type

template route.

Using a Smarty-type support template support structure to create:
i) several different looking sites all driven efficiently by the same data,
and 
ii) gain performance by caching page(s) and/or data 
...seems more like true genuine good reasons to use a Smarty than to solely 
go a Smarty-type route just so that designers can tweak the colors 
of tables as the months go by.

Additionally, I wanted to clarify here in the context of my previous Smarty
remarks.

I advocate OO techniques for small or large projects, in the long run 
OO techniques will return coding organizational and maintenance ease and 
accuracy that every organization will benefit from. Though, yes, this OO
issue 
has been beaten to death, I think in the scope of this list that promoting 
OO again is quite alright. Much like how by necessity the don't drink and
drive 
message is never curtailed.

Warmest regards,
 
Peter Sawczynec,
Technology Director
PSWebcode
_Design & Interface
_Ecommerce
_Database Management
ps at pswebcode.com
646.316.3678
www.pswebcode.com




-----Original Message-----
From: talk-bounces at lists.nyphp.org [mailto:talk-bounces at lists.nyphp.org] On
Behalf Of Rob Marscher
Sent: Wednesday, September 06, 2006 11:00 AM
To: NYPHP Talk
Subject: Re: [nycphp-talk] To Smarty Or Not to Smarty: That Is The Question


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
>
>   
_______________________________________________
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