Stuart wrote:
2009/5/24 Nathan Rixham <>:
LinuxManMikeC wrote:
On Sun, May 24, 2009 at 11:09 AM, tedd <> wrote:
At 12:01 AM +0100 5/24/09, Nathan Rixham wrote:
LinuxManMikeC wrote:
I was recently researching template engines for a small in-house
project, with a bias toward simple and lightweight.  I found this
interesting article in my search.  I think its worth considering if
you don't need all the bells and whistles of the big template engines.
 Simple and elegant.
cheers, it certainly is simple and elegant - however a bit too simple
(specifically as it's in template php); gives me immediate visions of a
wordpress template - and that's more than enough to scare me off! <lol>



Anytime I see embedded style elements within html, that's more than ample
warning to make me look elsewhere for the solution -- because IMO that's
a solution.

I find it interesting that the articles states "the separation of
logic from presentation" but then combines content with presentation. I
don't see any real gain here.

My efforts are always trying to separate content from function and
presentation. Make everything as unobtrusive as you can. Place styling in
remote css, client-side javascript enhancements unobtrusively, and use
server-side php/mysql to create secure and accurate function to generate
proper html and deliver desired content. I can understand someone wanting
simplify their work, but exchanging one problem for another doesn't cut
for me.



You're missing the point just because he threw in some old HTML
styling attributes.  The main issue is the overhead of added parsing
layers to find where content goes in the HTML.  Aren't we already
using a language (PHP) that parses for place holders for dynamic
content within HTML tags?  Write the template in XHTML, style it with
CSS, and insert content place marks with PHP short tags.  Do the
programming work of calculations, validation, and DB access in another
script which will include the template at the appropriate time.  Even
create classes to hold various data sets (think JavaBeans) if you
want.  Adding a layer of abstraction just so your designers don't have
to write <?=$var?> is silly at best.  At lest that's my opinion.  Do
whatever works for you.

which is lovely, but then you realise you have business logic tied up in the
presentation layer, and the client suddenly wants 3 different web based
interfaces and a roaming flash version which calls the system via an api;
and then you have the joy of telling the client its 6 months work and huge
figure to rewrite the application layer to included an abstracted
presentation layer, but it could have been avoided months ago with a days
worth of work (or even an hours worth) and a different decision.

Using PHP for templates has absolutely no bearing on whether your
presentation is tied up with your logic or they are completely
separate. Almost every project I work on day-to-day has at least 2
front ends, XHTML and an API. In addition several have mobile versions
of the presentation layer. All of them use pure PHP to render output.

all in though, hardly matters on a personal site, or a quick client job
where, or a.. I guess there's a place for each technology and method; and we
could throw scenarios around all night getting no where.

IMHO there is only one scenario where using a template engine is
justified and that's when you're working with people who insist on
using it and you can't talk them round.


and now I'm questioning myself - not on the client scenario based decisions - but on my own personal projects and things only I work on.. why do I use a template engine? habit? some old logical decision I made based on abstraction which somehow ruled out php (the pre-hypertext processor) - I fear I may have implemented some false logic at somepoint a few years ago and never gave it any more sense.

a risk of sounding like a complete dick - i wish I could unit test myself and give myself a peer review every now and then.

might hire somebody to question every statement it make - (for some reason Mr Sperling comes to mind - question me!)


PHP General Mailing List (
To unsubscribe, visit:

Reply via email to