matthijs wrote:If you need
Mordred wrote:Does the job. Short. Easy to read. Easy to maintain. Steals from the rich and gives to the poor.
you can indeed look at some of the available template languages. But you can also use PHP, but then just use a limited amount or a specific set of variables/logic.
Ah, you misread me. I need that, so that's why I
developed it. The examples posted before are not mockups, but real samples.
matthijs wrote:
Take a look at some of the blogging tools/cmses, for example wordpress. It's pure PHP in the templates, but it's not too difficult. Even noobs who build their first site can get it done with the help of the manual.
The argument that the template builders (designers?) are not able to deal with those few lines of PHP in the templates is an argument I don't accept. If you're smart enough to write accessible HTML, deal with all those IE bugs and get your site working cross-browser, you are smart enough to understand those few snippets of code between <? and ?> tags

Eew, wordpress themes. My hairs stand on the back of my neck every time I see one (and let's not start about the security implications, it's just staggering). I don't think it's a successful example of doing things right, even if there are hundreds of people who happily hack at it. They do so because the platform is popular, not because it's easy. Also check this recent posting here:
viewtopic.php?f=6&t=83997. Biggest market share != themes are easy to mod.
arborint wrote:First I wanted to address Mordreds three points:
Mordred wrote:Some problems are:
1. One must "manually" loop the loops and enumerate the vars to be replaced
2. Runtime string replacement is ... slow.
3. The template snippets are separated (assuming you'll read them from file or something), which, if one wants to change something, make it hard to identify in which piece a particular string resides.
#1 can be dealt with if the template library has a call that will loop for you.
#2 is not necessarily true. Reading a template and doing str_replace() is not that slow compared to include().
#3 can be dealt with by having blocks in the template.
This was a reply specifically to
mpetrovich's
post, I enumerated some problems in his implementation, not template engines in general.
arborint wrote:My argument with this statement, which I agree with, is the idea the the template engine is the View. I think the template engine is sometimes the whole View, but the View can also simply use a template engine for part of its work.
I lean towards the latter, but only since I use a PHP+template combo.
Everah demonstrated an OOP PHP-only template that just works standalone.
arborint wrote:The main place I do not use PHP templates is when an untrusted user can edit the content.
+1024 on that!
@
dbevfat
I understand your sentiments, but there are other cases where the developer needs you think are wrong are in fact right.
1. Not trusting the template writer is a natural thing when he is not a part of the team that builds a monolithic site, but is a 3rd party modder who customizes - say - blog themes. See my above comments on wordpress.
debfat wrote:All in all, templating engines always start out lightweight, but have to extended to fulfill certain needs. Echoing and loops are soon not sufficient, so you get functions, then parametrized functions, object support and whatnot. Not rarely the templates also support PHP directly, which is just silly and undermines their own existence. The templating language capabilities approach that of PHP, only with a different syntax, which is often ugly. In Smarty, for example, the syntax for parametrized functions is just awful. At some point, the template engine will be a bloated retarded little brother of PHP, and designers will have to learn it. But, if they can learn that, surely they could learn PHP?
I totally agree, and so I did what you argue against in your next paragraph:
debfat wrote:To protect the template engines from becoming a language of its own, developer often refuse to expand the templating language. Echos and loops, that's all you get. But all you've done now is move the data preparation logic to php, which results in a major drawback: the programers have to deal with content output (ie. they have to call uppercases, uc_words, number formattings, ...), which bloats their code, that should be more or less business-oriented.
... which I disagree with.
The point of limiting
my template language (can't talk for the others) is that this is the point where usability and simplicity meet. It also covers more than 90% cases (actually in my usage, I could only think of only one instance when I had to format the output on the PHP side). What's more, my API on the PHP side
also allows short and meaningful expressions, so the overall result is even shorter. You are invited to write out the example in the previous pages in your style, so we can compare.
I also disagree that the designer/template writer should have controll over things like uppercase and number formatting. This is view/business logic, in the sense that it is tightly coupled with the domain of the business object. As such it belongs on the "code" side of the view.