[dev] interesting article on templates

[Nuno Loureiro]

Okay!

I do have some things to say about this subject...
Anyway, these will be just comments and different points of view. I'm
*really* not trying to start a war of any kind. Peace & Love! :D
I already knew the article for some months, and I only disagree with him
in the end of the article.

On Tue, 2003-09-16 at 04:26, Chuck Hagenbuch wrote:
> Quoting Jan Schneider <jan at horde.org>:
> 
> > > http://www.massassi.com/php/articles/template_engines/
> >
> > Good point. And nice to see that his template files almost look like Horde
> > code. ;-)
> 
> True. :)

Actually I don't quite agree with that... 

Brian defends in his article a separation between logic and presentation
(not PHP from HTML), and he concluded that a templates engine wouldn't
worth the extra overhead (I'll go deeper about this later). 

I don't quite agree with you because Horde, or at least IMP, has not
business logic completly separated from the presentation logic. In fact,
I just realized that when converting IMP to Horde_Templates. Obviously
an application has both logics separated when you don't need to change
business logic to change its presentation. Some examples of problems
about this separation in Horde/IMP are a lot of class methods that
produces HTML, like:
- Menu::customItem()
- Horde::link()
- Horde::widget()
- Notification_Listener_status::notify()
etc.
These are just some examples.. There's a lot more of other examples that
break this separation. 

>(...)
> We do want to be able to have things like Horde_Mobile, though, and to be able
> to easily change the UI of an application like IMP. I just don't think
> Horde_Template is the way to do it, though.

What I've tryed to do so far, and I have some new stuff done, was to do
both things at once, i.e., -separate both logics, and -"templatatize"
the presentation. Now I realized that this task would had been a lot
more easier if I splitted it in 2. I should have done in first place,
the separation between both logics, and only after its commit, proceed
with the templatization.

I think the first part (separate both logics) we all agree, at least in
theory. I think we might disagree about the second part
(templatization), and this is what I disagree with Brian's article. Not
thinking only in Horde, but thinking widely, you have some advantages in
having a templating language over using PHP, like:
- You can have a separate department or team or outsource the interface
and you don't have several security concerns because the template
language is rather limited, comparing with PHP.
- If later you want to change the main language of your application, the
interface doesn't need to change at all.
- You can do template parsers in more languages, than PHP.
- In a company, like where I am, that lots of sites are made in perl and
some in PHP, you can have a unique templating system and you only need
to teach to designers a unique and simple "language".
- And like Brian says, a templating language is a bit simpler than PHP.

At least for me, those reasons are worth for using a templating system.

I'll send one more time, in a near future, a set of patches (after the
last changes I've been doing) to convert menu, quota, login, mailbox and
the master template and the compilation class. If of course, you really
decide that you don't want to follow that path, I'll split my tree to
continue my work in a non-contributing way (I only mean with that, that
I'll do more oriented to what I want and with more freedom). I really
understand if you don't want IMP with horde_templates, because I know
it's a big change to the application. I just can't agree with you that a
template system is not "meant" for big applications. I do agree that a
big application that was not made from start with that in mind, could be
really complicated to transform, and couldn't worth it.

Any thoughts, opinions?

-- 
Nuno Loureiro <nuno at co.sapo.pt>
PTM.com - http://www.sapo.pt/
PGP fingerprint = 8A32 5174 E80C 2D40 9075 405E C107 6592 054A 4D05