Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

hmm... I'm not sure I can answer how you would go about making H::T do a =
compile-time parse, but I can solve your need for <TMPL_INCLUDE =
<TMPL_VAR num>>...

I use a modified version of H::T which does this (and a number of other =
useful things, such as custom TMPL tags).  Go to:

http://members.optusnet.com.au/mathew/

and download the version of H::T from there.  The perldoc explains how =
to enable recursive templates.

Mathew

PS.  I am very familar with Locale::Maketext, and I think it is a great =
step forward in handling language translation capabilities (compared to =
say 'catgets'),  however I found it to be limiting in some specific =
ways, thus I created Locale::MakePhrase which I believe to be much more =
powerful.



----- Original Message -----=20
From: "Mark Fuller" <mar...@ea...>
To: "Mathew Robertson" <mat...@re...>; =
<htm...@li...>
Sent: Wednesday, January 05, 2005 2:03 PM
Subject: Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE


> Here's another example.
>=20
> To accomodate multiple foreign languages I store my loaded templates =
in a
> hash keyed by language code. The loaded template is mostly the same =
template
> files with param information filled in specific to the language. My
> procedure is this: I always check if the template exists in the hash =
for
> each display of the page (using the visitor's language preference). If =
not,
> I go through my load process which involves "tmpl_load" and a series =
of
> Locale::Maketext calls to translate English into whatever language the
> template needs to be in. Generally, this means using the param method =
to set
> the xml:lang, the encoding, the stylesheet (to get the font for =
non-Roman
> languages), and a slew of Maketext calls to translate fill in form =
captions,
> heading values, etc.
>=20
> Not all the page text dynamically translated like this. Some larger
> paragraph text may exist in files included into the template from a
> directory structure representing  the language (like =
/templates/en-US). This
> gets back to the earlier example of how it's difficult to dynamically =
select
> includes. (In this case HTML_TEMPLATE_ROOT would work *if* all my =
templates
> (non-language specific) existed in that directory too.)
>=20
> Anyway, this language processing only needs to be done *at the time =
the
> template is loaded*. I don't need to do it for each output of the =
template.
> I'm keeping my own template objects for each language (in the hash). =
There
> are only a few output-time params that need to be re-evaluated at =
output
> time (status message, select lists because the selection may have =
changed,
> form fields). All the translated text performed when the template was =
first
> tmpl-loaded doesn't need to be re-evaluated.
>=20
> This case is a little different than the previous example. In the =
previous
> example, I needed substitution to occur at compile time. In this case, =
I
> need to specify that the evaluation of the param is *permanent*. If
> compile-time substitution were available I could setup all my =
name=3Dvalue
> pairs prior to the tmpl-load. But, in my mind I'd rather do the =
tmpl-load
> (specifying anything that needs to be done at compile time, like the
> conditional include mentioned previously) and then have a method to =
perform
> one-time, permanent substitution to the loaded template. This way I =
could
> issue my numerous Maketext calls after the template is loaded and let =
the
> results be stored in the template rather than creating my own =
temporary
> holder just to so the values are available at compile time (assuming =
there
> could be a feature to perform compile-time evaluation).
>=20
> Does that make sense? Am I completely missing something?
>=20
> Thanks,
> Mark
>=20
>