WARNING! LONG ANSWER AHEAD!
Jonas Liljegren wrote:
> How is it possible to set up all data before callign the template?
>
> How can you know what data the template needs?
I think it's pretty typical to know this when writing a
model-view-controller application. If this is a search result page, my
controller processes the input, calls methods on some model objects it
knows are needed, and passes them to a template (view).
A variation on this is the Class::DBI approach mentioned on this list
before, but the only real difference there is that the data is
"lazy-loaded" at display time. The template still can only display the
data objects that were passed into it.
> I am thinking that you would have to have a special function for each
> template with dynamic content.
Exactly.
> And you would have to constantly
> change that function then the template wants to display anything
> diffrently.
Yes, if the requirements change so that the template has to display
different data, you would have to change your function. That's a good
thing, and I'll explain why I think that in a minute. If the template
just wants to show the existing data differently ("make that part
yellow, and put those in a table"), then of course no change in the perl
code is required.
> With callbacks, you can have general functions and can create lots of
> varied templats without any customized code.
That's what I used to think, but I ran into a lot of problems with this
approach. In the Java templating system I mentioned, we designed it
with this in mind: we would have a set of components (like plugins) that
could be called from any template. They would take a few parameters,
and designers could use them to make entirely new pages with no changes
in our code.
It worked, at first. However, pretty soon we discovered that the
designers were often doing things in ways that were very inefficient,
simply because that was the only way to get the specific data they were
after with the components we had given them. A small amount of coding
could have created much more efficient components to do the job, but
they would usually not come to us to ask for this, because we were
always busy working on the endless stream of feature requests from the
business users.
Even worse than the inefficiency was the fact that siginifcant business
logic was now getting stored in the templates themselves. We had
accidentally created a page-centric design, similar to using PHP or
ColdFusion. When control-flow decisions were needed (go here if this
user failed to enter the correct password, or if some data was missing
from the form, etc.) they were coded directly into the pages using the
output of our components. Now we had core business logic written in
this weak scripting language and scattered around among a bunch of
templates.
My more recent design, which used TT, was based on
model-view-controller. We had perl handlers (running in mod_perl) that
would do the work for each request, and the templates were just views to
show the resulting data. This made everything a lot clearer, and was
much easier to deal with. There were clear delineations of work, and we
could do things more efficiently. As an example, we would set an
Expires header from the controller based on the soonest expiration time
of the data objects we were passing in to the template. We couldn't
have done that if we didn't know what data was going to be used before
running the template.
There's still room for improvement. It may be that a mix of these
approaches gives the best result. Some of the lazy-loading stuff should
also be incorporated into this. Overall though, I've come to think this
is a better approach than callbacks.
- Perrin
