Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

> I just had a need to conditionally include one of a few templates =
dependnig
> on the value of a TMPL_VAR. One of the includes (which would not have =
been
> loaded) did not exist, but H::T died because it couldn't locate that =
file. I
> realized H::T probably loads everything at compile time and applies =
the
> conditions at the time the output method is called.
>=20
> This makes sense since caching would be screwed up if it had to keep
> reloading conditional includes with every output.
>=20
> However, I still feel like I have a need to conditionally load =
included
> templates and I know which ones they are at compile time. It's not =
going to
> change over repeated outputs called on the same cached template. I'm =
faced
> with either structuring the template includes differently (making it =
uglier
> and some duplicated HTML). Or, let it load all the stuff I know I =
don't need
> at compile time and use a TMPL_VAR (the same value for the life of the
> template) to tell the output method which included fragment to output.
>=20
> Question: Does this lead to the idea that it would be useful to have
> variables used only at compile time? When I tell it to load a =
template, why
> can't I give it variable name=3Dvalue pairs to apply *only* at compile =
time?

Its an interesting idea...

> I know everyone's a fanatic about efficiency. But, couldn't this lead =
to
> more efficent template processing? If you know you have static values =
used
> for the life of the loaded template, wouldn't it be more efficient to =
apply
> them at the time the template is loaded? Instead of every time the =
output
> method is called?

certainly, except that if a template parameter never changes then just =
add it directly to the html.
=20
> Examples of such life-of-the-template variables might be the language =
and
> encoding variables used to specify the language being used within that
> template? Or, a variable used to pick a navigation side-bar based upon
> system-wide parm? (Customized navigation bars for seasonal occasions? =
Where
> the CGI decides at runtime which one it wants loaded based upon the =
time of
> year?)

umm... both of these examples prove that the template variables are =
dynamic - its just that the lifetime is extremely long compared to most =
template variables.  eg: If a webserver runs for 12 months, then you =
would have to use a different value for the seasonal variations.

> In my case, all my pages share a common sidebar layout, but different
> sidebar choices. I want to nest the set of choices within the common =
sidebar
> layout and let each page (different CGI::App modules) specify which =
set of
> choices should be loaded from that common sidebar layout. But, to do =
that,
> it has to load all of them at compile time and then reevaluate the =
decision
> for each output of the template. When, it's not going to change for =
the life
> of that loaded template.

"...nest the set of choices within the common sidebar layout..." =
precludes "it's not going to change for the life of that loaded =
template"

which way is it?  either you are providing choice or you're not.

> It's not the end of the world. But, it seemed like a potential =
opportunity
> to make H::T a little more efficient by allowing some evaluation =
criteria to
> be performed at compile time.
>=20
> Am I totally off base?

although the concept is interesting (eg compile-time evaluation of =
template variables), however it appears that you cant see the difference =
between static information and dynamic information.

Mathew