I guess maybe because I lean more towards letting the template drive the
code, and not the other way around. The code thinks of itself as a
resource provider, and queries the template for resources it needs. It
doesn't know anything about how those resources are going to be used.
It's really up to the template, through it's logic, to make appropriate use of
that stuff.
I know that sounds kind-of ambiguous, so maybe a more concrete example is
appropriate. Let's assume that the task at hand is to fill out some
sort of response form. In addition to processing the form input,
the code can also generate a list of know email addresses, a history of
the user's form items, a list of cities and states, etc. -- all of
which we (assume) are expensive things to do. Now, it's up to the
template to make good use of these resources as it renders a suitable
UI. It may start by offering a simple fill-in the form form screen, with
options to pop-up the email address list, prior form request, the city-state
list. Or it might walk the user through the form items wizard-like,
asking for one bit of information at a time -- you get the idea.
It's up to the template to decide which of these resources it's going to
use. The code really has no idea what things trigger the need for
what resources. If it did, I'd wind up tightly coupling my UI to my code
-- which is the big thing I'm trying to avoid.
So, all the code can do is query the template for the names of the
variables that are referenced, and make them. The problem comes in when
the item is an expensive TMPL_LOOP variable. I'd much rather make that
only when I'm absolutely sure it's going to be used. The query interface
can't tell me that -- it just tells me what's in there. Hence the need
to postpone the actual generation until rendering time.
I hope you follow along with my (admittedly contrived) example. In
my real-life case, I wind up using the same code base for different websites,
each of which implement a given task in a completly different manner.
The only way I can do that is by keeping the UI decisions out of the
code.
- Bob
Mathew Robertson <[EMAIL PROTECTED]>
wrote:
hmm... not sure about that...
If your TMPL_IF takes one branch which doesn't
result in generating output, why didn't the Perl code test the same value
and not generate the unused H::T param data?
Mathew
----- Original Message -----
Sent: Wednesday, October 06, 2004
11:01 PM
Subject: [htmltmpl] Allow coderef's
for LOOP variables
My templates tend to be pretty complicated, and often have different
If/Then/Else paths that they could follow when rendering. I also
have loop objects which are expensive to build (time-wise).
Therefore, I query() the template only build them if the template
references them. However, this didn't give me the best performance
savings, because often the template would still not use the expensive loop
object, because it didn't follow that If/Then/Else path.
To "fix" this I arranged for my expensive loop object to be built as
a call-back, and stored a coderef as the param value. However, I
found that HTML::Template didn't allow code references for loop
variables.
I implemented the work-arounds for this by allowing a loop variable
to be a coderef, and then detecting it later and de-referencing it at
output time.
What are the thoughts on doing this? It does weaken (or at
least postpone) the strong type checking that occurs for a loop value
(must be an arrayref).
-Bob Diss
Do you Yahoo!?
vote.yahoo.com -
Register online to vote today!
