enigma1 - 8:02 pm on Nov 17, 2011 (gmt 0)
IMO none of the template systems does the job. They increase overhead in general, its another interpreted language you need to learn and because of the massive segmentation of the html it increases the time to do something.
Now having php/html spaghetti code also has disadvantages. You may have one or two files to work with, but the code becomes hard to manage or read pretty quick. With templates the code maybe more manageable but it splits over multiple files and takes longer to debug or change something.
So there should be a balance and not only. You don't want to search 50 files on the one hand, because the html is so segmented and at the same time you may have to work with web2.0. These dynamic scripts can be a pain if the framework isn't designed to support them. You may spend ages to implement ajax, replicating code all over the place to have support for both regular and ajax requests.
And unfortunately the current structure of PHP doesn't make things easy although it began as a template language - which is an oxymoron.
The closest I thought of is to use some common sections as templates and leave the rest of code with mixed html and php. It's not something rigid so I can always move more stuff into templates, increase the number of php files a bit to support ajax but keep it as flexible as possible.
In terms of actual implementation, I won't use eval, for example I will use "include" or other native php functions to load other php/html segments when necessary. The include for instance won't give an error if the segment isn't there it can work as an option. So I could include the same number of segments for all pages but point to a separate folder to make exceptions if required and generate different layouts. So I could avoid template scripting at the top of the html.