Inner-platform effect
en.wikipedia.org
en.wikipedia.org
And you need to put a $ in front of every variable. Seems like someone did not know how to write a parser..
http://docs.plt-scheme.org/web-server/run_ss.html#%28part._i...
Secondly, there's nothing in PHP that guides one away from packing more and more functionality into the template instead of the template's caller; it's easy to find snippets of PHP that do something "cool" online, and it's hard to explain to your designer why they shouldn't use them.
So, too verbose and less maintainable, is what it boils down to.
<div class="dog" id="dog_{{__id__}}">
<h1 class="name">{{__name__}}</h1>
<p class="sex">{{__sex__}}</p>
<p class="breed">{{__breed__}}</p>
<p class="images">{{__pictures__}}</p>
<div class="description">{{__description__}}</div>
(The formatting appears to be lost; accept my apologies)
That said, I am also working on fixing a restaurant site that a friend programmed, and it is littered with the type of disgusting syntax you mention. It's the difference between a designer who does snippets of PHP and a programmer.
The article suggested that it was obviously a bad idea to write a templating engine in PHP, since PHP is already in the category of "templating engine". As you point out, it's easy to implement a template system in PHP that's better to use than raw PHP would be.
I've never really understood the need to abstract things in this way even for novice front-end developers since it's the concept that is important not the syntax.
e.g. I don't see any real difference in using a) <?php foreach($key as $val): ?> or b) {foreach from=$myArray item=foo}
To me the Smarty abstraction is pointless.
) Designers can't break application code. They can mess with the templates all they want, but the code stays intact. The code will be tighter, more secure and easier to maintain.
) Errors in the templates are confined to the Smartys error handling routines, making them as simple and intuitive as possible for the designer.
) With presentation on its own layer, designers can modify or completely redesign it from scratch, all without intervention from the programmer.
) Programmers aren't messing with templates. They can go about maintaining the application code, changing the way content is acquired, making new business rules, etc. without disturbing the presentation layer.
) Templates are a close representation of what the final output will be, which is an intuitive approach. Designers don't care how the content got to the template. If you have extraneous data in the template such as an SQL statement, this opens the risk of breaking application code by accidental deletion or alteration by the designer.
) You are not opening your server to the execution of arbitrary PHP code. Smarty has many security features built in so designers won't breach security, whether intentional or accidental. They can only do what they are confined to in the templates.
The problems solved by Smarty could be solved simply with a single try-catch block around the rendering-kickoff logic (that forwards to a nice 500 error page if something happens), and a convention to not do any business-layer stuff within the templates. [Also, source control + a dev/testing server to deploy on so "break[ing] application code" isn't a concern, but this should really, really not need to be mentioned.] This is exactly what I've done on any [non-framework] PHP project I've touched, and no one has ever complained that it was hard to edit the views.
) Errors in the templates are confined to the Smartys error handling routines, making them as simple and intuitive as possible for the designer.
- Ok, but this is an abstracted error message, when the designer could simply learn to work with PHP error messages.
) Programmers aren't messing with templates. They can go about maintaining the application code, changing the way content is acquired, making new business rules, etc. without disturbing the presentation layer.
- If you are using an MVC design pattern programmers will rarely need to mess with templates anyway.
) You are not opening your server to the execution of arbitrary PHP code. Smarty has many security features built in so designers won't breach security, whether intentional or accidental. They can only do what they are confined to in the templates.
- I thought it was possible to execute abritrary PHP code by using the {php} template tags?
I suppose at the end of the day you use what feels most natural for you and what your designers find easiest (or are familiar with). It's totally up to personal preference. For me it has always felt like too much of an abstraction to be worth utilising.
There are large numbers of programmers who have moved on to "programmable" programming languages. (Languages where meta-programming is comfortable and very useful.) It's no longer a fringe thing. Either you use this wording tongue-in-cheek, or you haven't gotten that far yet.
Ironic, if you look at the Wikipedia schema. (At least last time I looked, which I admit was a few years ago.)
I think that many observers would say that the Wikipedia system works quite well considering they are one of the most widely used sites on the Internet. Since this article is published on Wikipedia, it would seem an ironic disproof of the article's contents that the publishing platform uses the very strategy that is claimed to be an anti-pattern.
I would go a step further and suggest that the technique listed uses the relational database such so that in the end it is more like a columnar database, although I have to think about that further before I feel more sure.
Personally I prefer to be more descriptive than prescriptive and judge them on their success under extreme duress.