Re: [htmltmpl] Allow coderef's for LOOP variables

[Mathew R. <mat...@re...>]

I see...  in that case, I guess it would be a suitable thing to do... =20

regards,
Mathew

  ----- Original Message -----=20
  From: Bob Diss=20
  To: Mathew Robertson=20
  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 <mat...@re...> 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 -----=20
      From: Bob Diss=20
      To: htm...@li...=20
      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.