There is also very interesting Savant Template System for PHP (http://phpsavant.com/). Like mentioned in articles above, it also uses PHP itself as its template language so you don't need to learn a new markup system. It has an object-oriented system of template plugins and output filters, so it supports almost all of the power of Smarty with almost none of the overhead.

There is also very interesting Savant Template System for PHP (http://phpsavant.com/). Like mentioned in articles above, it also uses PHP itself as its template language so you don't need to learn a new markup system. It has an object-oriented system of template plugins and output filters, so it supports almost all of the power of Smarty with almost none of the overhead.

... and almost none of the features. Just use the right tool for the job.

Bah, that article was written from the point of view of a programmer. I am not a programmer. He totally trivialises the awful mess that is a foreach statement. There is too much complex, frustrating punctuation in using shorthand PHP, and more room to totally screw it up. PHP is simply *too powerful* to give to someone who does not come from a full programming background (ie. a designer who knows HTML, and let's say some basic Javascript).

Unfortunately it's programmers who tend to write the articles arguing the pros and cons of templating engines, Smarty included.

Now, which is easier to understand from a non-programmer's point of view (I'm going to whack in a full foreach, as I use them all the time at work in Smarty based projects)?

Wait, endforeach? That's a whole separate word (and knowing PHP's rather all-inclusive PERL / C / C++ / whatever other languages they felt like mashing together syntax, it's likely that there's be something that is written in a different from this, such as maybe it uses the word 'close' instead of 'end'. I wouldn't put it past PHP, that's for sure).

It's so much clearer for a designer to have Smarty lay things out into individual chunks (though Smarty still suffers from the PHP problem of naming inconsistencies, something that I would love to have the team address in a future release)

Having the data separated into three separate, logical options is far, far easier to understand and comprhend than it is to have to grasp => and -> and all those other terribly confusing pointer thingies in PHP.

And writing
<?=$var;?> is far more dangerous and error prone than {$var} because THERE'S ONLY ONE SET OF BRACKETS YOU NEED TO REMEMBER. With the former god-awful syntax, you have to remember not only brackets and question marks, but if you're using a variable, heaven forfend you forget the all-important = sign.

Anyway, that's just my views on some of the points raised in that article. Make of them what you will.

And now, representing the dolts of the world, we turn to Graphic Designer X:

I've read Lozier's article and am happy to report that I understood his points and their benefits. Sadly, I did not comprehend his code examples. I read both of the code examples posted by dthought and neither of them make sense to me, either.

I have no desire to be just another dolt Graphic Designer. I know that programmers are required to know a lot of different languages and tools. The same is true for Graphic Designers, especially those that work with print and web design. Becoming tied to your tools is not a good idea. Its a hard sell to get a designer (and programmers for that matter) to learn a new system when Dreamweaver is working well.

Designers are smart, but not smarties like you programmers. You have an aptly named template engine to prove it. Dreamweaver has shown itself to be a leader in WYSIWYG web design. I love the "separation of business logic from the presentation of data." Now can we just get it to work easily within Dreamweaver?

I realize that I am oversimplifying the issues and might be seen as another dolt designer with a party-pooping, lazy attitude. Quite the contrary, if you want to help designers and programmers work effectively together in this manner give us something that works with tools we already know and possess. We're not afraid of learning a new system, just help it be somewhat familiar. Macromedia has a similar approach when they designed Dreamweaver's UI to be similar to Photoshop.

Also, debugging is HORRIBLE. A simple syntax problem, because of the interim XSLT file, can take a long time to solve. Not to mention the ability to have it all go to hell if someone uses an international character in the XML....

Another problem:

Natively on most hosting locations XSLT is NOT included in PHP -- the sablotron engine is not compiled in. Thats a problem for PHP folks.

MS folks have it easier, as its built right into IIS -- but then your talking windows.

Personally, and philisophically, I think building a GUI and using XSLT, XML etc. is a bad choice and you tend to have layers of complexity that you shouldn't have to deal with when you want to maintain a GUI.

Sure, you could go and use some application server to make it easier, but then thats yet another layer of complexity, or you could have a big ass wrapper that makes the templating in XSLT easier for GUI's -- but its still a performance hog when you have to start up a parser.... Smarty, or any PHP template engine for that matter is far easier in the grand scheme of things.

XSLT is a great language for manipulating XML. Taking it and shaping it for something else. But its terrible for using it as a presentation layer.
IMHO.

There is also very interesting Savant Template System for PHP (http://phpsavant.com/). Like mentioned in articles above, it also uses PHP itself as its template language so you don't need to learn a new markup system. It has an object-oriented system of template plugins and output filters, so it supports almost all of the power of Smarty with almost none of the overhead.

What overhead? It's amazing how many people overlook that Smarty compiles the templates into PHP. There is no parsing done once the template is compiled.

There is also very interesting Savant Template System for PHP (http://phpsavant.com/). Like mentioned in articles above, it also uses PHP itself as its template language so you don't need to learn a new markup system. It has an object-oriented system of template plugins and output filters, so it supports almost all of the power of Smarty with almost none of the overhead.

Savant is a very bad solution. I tested it for a while and it doesn't seperates php(logic) from layout(html). If you don't believe me look at their website.

Savant is a very bad solution. I tested it for a while and it doesn't seperates php(logic) from layout(html). If you don't believe me look at their website.

It's true that Savant does not separate php from html, and that's not the purpose behind it. Like many template engines, the purpose is to separate business logic from display logic and Savant acomplishes just that with minimal overhead by limiting itself to using plain PHP.

I think it all comes down to the discipline of the programmer. Even when using Smarty, I've made mistakes like adding business logic in templates and display logic in PHP code (even though Smarty provides all the tools to separate them). The boundaries are not clear for some people or in some situations, but we can all agree that the distinction exists, it's all about discipline.

btw, the URL you mentioned in the Savant website is a perfect example of business/display logic separation, I might be wrong but I didn't see any problem there, perhaps you could point it out.