David Cantrell wrote:
> Let me clear up a few things here. I wrote my toy system because I had an
> itch which needed scratching.
Great!
> The only reason I'm even bothering
> to argue about this is because of the incorrect assertions coming from
> people who really should know better that my sort of solution inevitably
> leads to spaghetti code and all the rest of the nastiness from Revelations.
Er no. Well, not me at least. I've said absolutely nothing about your
solution. You clearly understand the principle of separating application
from presentation. The fact that you're using Perl syntax code is neither
here nor there - it's what you do with it that matters.
The point I originally made was that *PHP* doesn't allow you to make this
clear distinction. Sure you can write separate modules but they're still
embedded-in-the-HTML type and the whole flat namespace thing makes it
hard to plug separate "modules" back together.
So I stand by my point. Using *PHP* tends to lead to a poor separation of
concerns typified by spaghetti code.
I certainly wasn't having a dig at your personal template solution. In
fact, I think you're the only person who has mentioned it. The rest of
us are talking about *PHP* :-)
There is one point I would like to make about syntax, however. For TT
I deliberately chose an abstract syntax (e.g. 'user.name') rather than
sticking with Perl syntax (e.g. $user->{ name }). For one, I find this
simpler to read and write. But more importantly, it allows the underlying
data types to change without requiring changes to the templates. An
abstraction of the implementation, if you like.
For testing purpose, you can define a hash of data which your page designers
(or you) can use to mock up the web pages. Later on, you can replace the
use hash with an object and the same template sytax will call object methods
instead of referencing hash items.
In Perl you have to care about the difference between $user->name() and
$user->{ name }. But TT hides all that from you. I think that's the
Right Way To Do It. When you're doing "presentation" you shouldn't be
worrying about different data types and other "programming" crap like
that. You want the name of the user and you don't (or shouldn't) care
where it comes from or how it is calculated. That's for the back-end
code and data designers to worry about.
Some people think that calling object methods from a template is a no-no
because it changes flow control. Personally I think this is nonsense.
Your example code demonstrates this point well. What matters is how you
partition the system. Things that deal with one thing should be in one
place. Things that deal with another should be in another. The particular
language, syntax or implementation details are largely irrelevant.
That's why it's possible to write wonderfully clean, highly abstracted
systems using embedded Perl, and dog-awful, messy, entangled systems
using TT or even HTML::Template (which claims to be so strict that you
can't do this, yeah right :-)
A
