

Inner-platform effect - Hexstream
http://en.wikipedia.org/wiki/Inner-platform_effect

======
shaunxcode
I do not feel that it is fair to dismiss php as merely a "template engine". It
probably outgrew such a small scope of use around 3x. On a more philosophical
level: the reason programmers long to create/control/extend the platform on
which they exist is because they are programmers. I think once you reach this
point you should go for it but also be prepared to move onto a programmable
programming language.

~~~
hellotoby
I read it as referring to a templating engine such as Smarty (for PHP).

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.

~~~
jquery
As a highly satisfied user of the smarty templating system, I want to refer
you to this (from <http://www.smarty.net/whyuse.php>):

 _) 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.

~~~
derefr
When you end up with flow-control, and other such complicated constructs,
inside your templates, either the designers are already smart enough to
"modify or completely redesign it from scratch, all without intervention from
the programmer", or the programmer will need to be "messing with templates"
anyway, to help the designers fix their _logic errors_ , which no amount of
abstraction will help overcome.

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.

------
madair
_In the database world, developers are sometimes tempted to bypass the RDBMS,
for example by storing everything in one big table with two columns labeled
key and value._

Ironic, if you look at the Wikipedia schema. (At least last time I looked,
which I admit was a few years ago.)

~~~
pohl
Would it be irony for a random HN user to post about an antipattern that
happened to be reflected in the underlying HN implementation?

~~~
madair
Good point, except the the irony is the reverse of that.

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.

~~~
madair
On the other hand, perhaps Wikipedia proves the point, and perhaps it could be
argued that something other than a SQL DBMS would be more appropriate. I think
the more rabid of the noSQLites would go that way.

Personally I prefer to be more descriptive than prescriptive and judge them on
their success under extreme duress.

