I see...  in that case, I guess it would be a suitable thing to do...  
 
regards,
Mathew
 
----- Original Message -----
From: Bob Diss
To: Mathew Robertson
Sent: Thursday, October 07, 2004 11:18 AM
Subject: Re: [htmltmpl] Allow coderef's for LOOP variables

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 <mathew.robertson@redsheriff.com> 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 -----
From: Bob Diss
To: html-template-users@lists.sourceforge.net
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!


Do you Yahoo!?
Yahoo! Mail - You care about security. So do we.