HTML::Template

On Mon, 2 Aug 2004, Carl Franks wrote:

> To figure out if any other module is pure perl, search for it on
> search.cpan.org Then follow the link with the module version number
> (e.g.  HTML-Template-2.7).  Then click on the [Browse] link to view
> the modules' files.  If there are no *.xs *.c or *.h files and no
> 'b' folder, then the module is probably pure perl.

Good advice, but there's one possibility you missed.  If a module uses
Inline::C then it won't be pure Perl, even if it has no C source
files.

-sam

Yeah, that's why I said "probably": I knew there'd be something I'd
missed or didn't know about.

"There's More Than One Way To Do It"

Cheers,
Carl

>>> Sam Tregar <sam@...> 03/08/2004 04:25:45 >>>
On Mon, 2 Aug 2004, Carl Franks wrote:

> To figure out if any other module is pure perl, search for it on
> search.cpan.org Then follow the link with the module version number
> (e.g.  HTML-Template-2.7).  Then click on the [Browse] link to view
> the modules' files.  If there are no *.xs *.c or *.h files and no
> 'b' folder, then the module is probably pure perl.

Good advice, but there's one possibility you missed.  If a module uses
Inline::C then it won't be pure Perl, even if it has no C source
files.

-sam


-------------------------------------------------------
This SF.Net email is sponsored by OSTG. Have you noticed the changes
on
Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now,
one more big change to announce. We are now OSTG- Open Source
Technology
Group. Come see the changes on the new OSTG site. http://www.ostg.com 
_______________________________________________
Html-template-users mailing list
Html-template-users@... 
https://lists.sourceforge.net/lists/listinfo/html-template-users

Sam Tregar wrote:
> On Mon, 2 Aug 2004, Carl Franks wrote:
>>To figure out if any other module is pure perl, search for it on
>>search.cpan.org Then follow the link with the module version number
>>(e.g.  HTML-Template-2.7).  Then click on the [Browse] link to view
>>the modules' files.  If there are no *.xs *.c or *.h files and no
>>'b' folder, then the module is probably pure perl.
> 
> Good advice, but there's one possibility you missed.  If a module uses
> Inline::C then it won't be pure Perl, even if it has no C source
> files.

Another thing to check for is the dependancies of a module.  The module 
itself may be pure perl, but it may depend on a module that is not.

As far as I can remember, HTML::Template only depends on modules that 
are included in a standard perl installation, so it does not require the 
installation of any extra modules (that excludes the caching modules 
like, IPC::SharedCache[1], but they are all optional).

Cheers,

Cees

[1] IPC::SharedCache depends on IPC::ShareLite which is an XS module

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.

This makes sense since caching would be screwed up if it had to keep
reloading conditional includes with every output.

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.

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=value pairs to apply *only* at compile time?

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?

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?)

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.

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.

Am I totally off base?

Thanks,
Mark

> 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

From: "Mathew Robertson" <mathew.robertson@...>
>
>which way is it?  either you are providing choice or you're not.

I'm sorry. I probably didn't explain the example very well.

This example is somewhat a problem of nesting, and somewhat a problem of
semi-static values.

Let's say I have 20 different top-level pages (represented by 20 CGI::App
modules). Each has its own set of sub-areas (pages produced by the module).
The side-bar navigation lists the sub-areas a visitor can go to from one
top-level page. Therefore, there is one side-bar structure which can have 20
different sets of values (depending on which module is using it).

I'd like have a top-level page include the side-bar structure which (here's
the important part) contains an include where the filename is partially
constructed by a TMPL_VAR. This way, the side-bar structure can be reused
across the 20 top-level templates, and each top-level template can specify
which list of values should be included in the structure by using a
TMPL_VAR.

      <TMPL_INCLUDE NAME="includes/navigation/area<TMPL_VAR
NAME=AREA_NUM>.html">

I can't do that because H::T (for good reason) loads all the includes at
compile time and performs variable substition at output time. This is a case
where it's not so static that the value can be hard-coded in the included
component. But, not so dynamic that all *20* list values need to be hauled
into the template and re-evaluated at output time using a gigantic <TMPL_IF>
construction. :)

I hope that's a clearer explanation.

I know I could do one of two things to get around this.

1. I could create 20 side-bar includes and simply include the correct one
for the top-level template.

The problem (possibly slight) is that I'll duplicate quite a bit of HTML to
surround the values with the entire construct. All 20 use the same general
construct, it's just the 5-10 list values comprising the actual links that
change.

2. I could organize it differently and include a side-bar_top, the specific
values, and a side-bar_bottom.

That's not the end of the world. But, it starts getting a little ugly when
what we're really talking about is nesting and semi-persistent values.

3. I could use a TMPL_LOOP and replace the values from within my CGI::App
module.

Again, not the end of the world. But, I don't need to re-evaluate with every
output of the template.

It's semi-persistant data. I can't hard code it. And, it doesn't change
after compile time.

I have another example (not involving nesting) regarding language support.
Let me think that one through and I'll write another email.

Thanks for considering this topic,

Mark

Here's another example.

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.

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.)

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.

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=value
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).

Does that make sense? Am I completely missing something?

Thanks,
Mark

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" <mark.fuller@...>
To: "Mathew Robertson" <mathew.robertson@...>; =
<html-template-users@...>
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
>

On Wed, 2005-01-05 at 01:58, Mathew Robertson wrote:
> 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/
> 

Your version has some nice features that I could use, especially the recursive HTML::Template invocation.  Is there a reason why Sam has not included your mods into the CPAN version?
I'd like to stay consistent and use versions from CPAN for our production servers.

Keith

From: "Keith Jackson" <kjackson@...>
> On Wed, 2005-01-05 at 01:58, Mathew Robertson wrote:
> > http://members.optusnet.com.au/mathew/
>
> Your version has some nice features that I could use, especially the
recursive HTML::Template invocation.  Is there a reason why Sam has not
included your mods into the CPAN version?
> I'd like to stay consistent and use versions from CPAN for our production
servers.

I agree. Matt's feature to do

       <TMPL_INCLUDE <TMPL_VAR NAME="VARIABLE_INCLUDE_FILE">>

would make H::T easier to use (in the example where I have a side navigation
bar used in 20 pages and the only thing different is the list element of
links).

I'd like to hear what Sam thinks of this.

I'd also like to hear what he or others think of my suggestion to be able to
perform "permanent" evaluation on a template. I really think this would be
useful such as the example where I language translate a template and all
that evaluation of the template is permanent for the life of the loaded
template.

I suppose the one complication is that a cached template is not gauranteed
to be present? Doesn't it discard cached templates after a certain cache
size is reached? I guess there would need to be a way to test if the
template is in cache and, if not, I'd have to re-execute my tmpl_load and
all the one-time evaluation. Or, the ability to mark a tmpl_load'ed template
as not discardable?

Mark

On Tue, 4 Jan 2005, Mark Fuller wrote:

> 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.

And just to explain why this was done in the first place,
HTML::Template allows includes to be syntactically invalid.  For
example, this is valid:

  <tmpl_loop foo>
     <tmpl_var bar>
  <tmpl_include foo_end.tmpl>

And foo_end.tmpl:

  </tmpl_loop>

Obviously there's no way to parse this without doing the include at
compile-time.

Now, maybe this was a mistake.  I've considered breaking this support
in my fantasy version 3 rewrite.  But at least for v2 it has to stay.

> 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.

I've thought about allowing something like:

  $t = HTML::Template->new(filename => 'foo.tmpl',
                           includes => { bar => 'bar.tmpl' });

And in foo.tmpl:

  <tmpl_include name="bar">

This would have to be factored into the cache-signature, but since
that's now centralized in a single place in the code that should be
easy enough.

Actually, it occurs to me that this would be pretty easy to do with
filter in a sub-class.  So you don't even have to wait for me!

> 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=value pairs to apply
> *only* at compile time?

Aside from doing variable includes, is there any other reason to want
this?  I doubt it would be much more efficient in the general case
for just a few variables.  Compared to the difficulty of coding it in
the current code-base it doesn't seem worthwhile.

-sam

On Wed, 5 Jan 2005, Keith Jackson wrote:

> Your version has some nice features that I could use, especially the
> recursive HTML::Template invocation.  Is there a reason why Sam has
> not included your mods into the CPAN version?

The discussion of these changes is available in the mailing-list
archive.  If memory serves I didn't think that most of them required
changes to HTML::Template itself.  My feeling is that if
HTML::Template::Expr could be done without changes to HTML::Template
then there's really no limit on the changes that can be accomplished
by a sub-class using filter.

Put simply, HTML::Template has suffered from feature-creap through its
life and it's nearly at the breaking point now.  The current code-base
won't remain maintainable with many more features added without a
major rearchitecture.  Someday maybe I'll do that and then all kinds
of extension will be easier...

-sam

OK, I understand. So I guess my question is redirected to Mathew, could
you subclass H::T and put your version on CPAN?

Thanks!

PS.  IMHO It doesn't get said enough, H::T is a GREAT module and all the
people involved deserve tons of credit!  Thanks and have a great New
Year.

Keith
On Wed, 2005-01-05 at 13:07, Sam Tregar wrote:
> On Wed, 5 Jan 2005, Keith Jackson wrote:
> 
> > Your version has some nice features that I could use, especially the
> > recursive HTML::Template invocation.  Is there a reason why Sam has
> > not included your mods into the CPAN version?
> 
> The discussion of these changes is available in the mailing-list
> archive.  If memory serves I didn't think that most of them required
> changes to HTML::Template itself.  My feeling is that if
> HTML::Template::Expr could be done without changes to HTML::Template
> then there's really no limit on the changes that can be accomplished
> by a sub-class using filter.
> 
> Put simply, HTML::Template has suffered from feature-creap through its
> life and it's nearly at the breaking point now.  The current code-base
> won't remain maintainable with many more features added without a
> major rearchitecture.  Someday maybe I'll do that and then all kinds
> of extension will be easier...
> 
> -sam
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Html-template-users mailing list
> Html-template-users@...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
-- 
Keith Jackson <kjackson@...>

Matthew,

I second Keith's request. Your feature to <tmpl_incl> a variable-substituted
filename would be valuable to me. But, I'm not comfortable departing from
H::T.

Sam,

I'm not a big object guy. Subclassing H::T is probably beyond my capability.
However, if you think it would be useful to have a "persistent evaluation"
of the *cached* template (so that the partially-evaluated template is
returned with each subsequent "new" method calls), I hope you'll keep it in
mind if/when H::T is enhanced. The only complication I can think of is that
the "new" method would have to provide some kind of result indicating that
it read the template from disk, not cache (so the caller can reinitialize
the cached copy).

I can get around this by by caching my own template object. Instead of
calling "new" with each display of the page (and relying upon any of H::T's
caching mechanisms), I can store the template in
$my_template_hash{$visitor_language} (once, when it is found to be undef),
perform my one-time language-specific evaluation upon that template, and
then use that template for each redisplay of the page.

The only problem here is that I have to be aware of anything that might be
optionally evaluated. Things that default to a certain display. I have to
always evaluate them to be sure they don't have a non-default value when
they should be default (that sounds confusing!).

Sorry if this is a dumb question, but is there an easy way I could clone the
template object in $my_template_hash{$visitor_language}, perform my single
display-specific evaluations upon it (without disturbing the original
object), and then reclone it for the next display (discarding the earlier
clone)? If there is a way, in your opinion would this be more or less
efficient than me performing my own re-evaluation of things that otherwise
would be default values (i.e., the problem mentioned in the previous
paragraph)?

Thanks!
Mark


----- Original Message ----- 
From: "Keith Jackson" <kjackson@...>
To: "Sam Tregar" <sam@...>
Cc: "Mathew Robertson" <mathew.robertson@...>; "Mark Fuller"
<mark.fuller@...>; "HTML::Template users"
<html-template-users@...>
Sent: Wednesday, January 05, 2005 11:40 AM
Subject: Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE


> OK, I understand. So I guess my question is redirected to Mathew, could
> you subclass H::T and put your version on CPAN?
>
> Thanks!
>
> PS.  IMHO It doesn't get said enough, H::T is a GREAT module and all the
> people involved deserve tons of credit!  Thanks and have a great New
> Year.
>
> Keith
> On Wed, 2005-01-05 at 13:07, Sam Tregar wrote:
> > On Wed, 5 Jan 2005, Keith Jackson wrote:
> >
> > > Your version has some nice features that I could use, especially the
> > > recursive HTML::Template invocation.  Is there a reason why Sam has
> > > not included your mods into the CPAN version?
> >
> > The discussion of these changes is available in the mailing-list
> > archive.  If memory serves I didn't think that most of them required
> > changes to HTML::Template itself.  My feeling is that if
> > HTML::Template::Expr could be done without changes to HTML::Template
> > then there's really no limit on the changes that can be accomplished
> > by a sub-class using filter.
> >
> > Put simply, HTML::Template has suffered from feature-creap through its
> > life and it's nearly at the breaking point now.  The current code-base
> > won't remain maintainable with many more features added without a
> > major rearchitecture.  Someday maybe I'll do that and then all kinds
> > of extension will be easier...
> >
> > -sam
> >
> >
> > -------------------------------------------------------
> > The SF.Net email is sponsored by: Beat the post-holiday blues
> > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> > _______________________________________________
> > Html-template-users mailing list
> > Html-template-users@...
> > https://lists.sourceforge.net/lists/listinfo/html-template-users
> -- 
> Keith Jackson <kjackson@...>
>
>
>
> -------------------------------------------------------
> The SF.Net email is sponsored by: Beat the post-holiday blues
> Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek.
> It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt
> _______________________________________________
> Html-template-users mailing list
> Html-template-users@...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

On Fri, 7 Jan 2005, Mark Fuller wrote:

> I'm not a big object guy. Subclassing H::T is probably beyond my capability.

I doubt that.  Give it a try.  If you have trouble, post here and I'll
be happy to give you a hand.  If you have no idea where to start I'd
suggest picking up Damian Conway's "Object Oriented Perl".  It's a
great book.

> However, if you think it would be useful to have a "persistent evaluation"
> of the *cached* template (so that the partially-evaluated template is
> returned with each subsequent "new" method calls), I hope you'll keep it in
> mind if/when H::T is enhanced.

Why?  I still haven't heard a compelling use-case aside from dynamic
includes which I think can be handled in better ways.

> Sorry if this is a dumb question, but is there an easy way I could clone the
> template object in $my_template_hash{$visitor_language}, perform my single
> display-specific evaluations upon it (without disturbing the original
> object), and then reclone it for the next display (discarding the earlier
> clone)? If there is a way, in your opinion would this be more or less
> efficient than me performing my own re-evaluation of things that otherwise
> would be default values (i.e., the problem mentioned in the previous
> paragraph)?

Easy?  No, I doubt it.  I can think of some hard ways...

-sam

From: "Sam Tregar" <sam@...>

> On Fri, 7 Jan 2005, Mark Fuller wrote:
> > However, if you think it would be useful to have a "persistent
evaluation"
> > of the *cached* template (so that the partially-evaluated template is
> > returned with each subsequent "new" method calls), I hope you'll keep it
in
> > mind if/when H::T is enhanced.
>
> Why?  I still haven't heard a compelling use-case aside from dynamic
> includes which I think can be handled in better ways.

Ooops. We're talking about two different things. What I said above concerns
evaluation of a template which needs to be performed *only once*.

For example: let's say a template's title, headings, field captions, etc.,
are generated using Locale::Maketext (to get a foreign language). The
template is evaluated to get this language-specific text into the template.
It wouldn't make sense to have to re-evaluate all this stuff for each
re-display of the page (in this language).

That's why I said that I "new" the same template (as needed for a language)
into a hash keyed by language. This way I have one template for each
language. The problem is: each time I "new" it (for each redisplay) I loose
all the one-time evaluation performed upon the template. I need these
one-time evaluations cached. I can perform my own caching, but then I have
to take steps concerning the state of non-one time evaluations and make sure
I don't take anything for granted. I can't get a fresh copy of the template
as it existed at the time I performed my one-time evaluations. I also have
to perform my own test of whether the template changed so I can discard my
cached copy.

Does that sound like a reasonable usage?

Thanks!
Mark

On Fri, 7 Jan 2005, Mark Fuller wrote:

> > Why?  I still haven't heard a compelling use-case aside from dynamic
> > includes which I think can be handled in better ways.
> 
> Ooops. We're talking about two different things. What I said above concerns
> evaluation of a template which needs to be performed *only once*.

Are you sure it needs to happen "only once"?  Your example doesn't
support that meaning.  In your example the language-specific stuff
needs to change when the language changes.  It's not as often as the
rest of the variables (presumably) but it's surely not just once.

For transformations that really need to happen only once I suggest you
make them with a text editor!

> Does that sound like a reasonable usage?

Maybe, but I still don't see why you'd want to do it.  HTML::Template
is fast enough that it doesn't seem like a worthwhile optimization
versus the work it would take to implement.

-sam

From: "Sam Tregar" <sam@...>
> Are you sure it needs to happen "only once"?  Your example doesn't
> support that meaning.  In your example the language-specific stuff
> needs to change when the language changes.

Sam. First, thank you for your consideration.

I only load a template for a language once. When I load it I perform all the
one-time language-specific value replacements. Otherwise I'd have to keep a
language-specific copy of the template in directory structures and "new" the
template from the correct structure. I used to do this. But now I prefer
keeping all the language specifics in Locale::Maketext and do a one-time
replacement of template values which heretofore had been kept in
language-specific templates.

The psuedo-code looks like this:

==============
if (!exists($template_hash{$visitor_language})) {
  template->new(template-path/name)
  $maketext_languageHandle_hash{$visitor_language} =
Locale::Maketext->get_handle($visitor_language);
  initialize_language_specific($template-hash{$visitor_language},
$maketext_language_handle_hash{$visitor_language});
}
===============

Inside "initialze_language_specific" I do *not* evaluate *everything* in the
template. There are some things that are specific to each display of the
page. So, that's done with each re-display.

Two problems with this mechanism are:

1. I'm effectively caching my own template so I can keep the one-time
evaluations across multiple displays.
   - Now I have to add my own test of whether a template has changed. An
unwelcome movement of functionality in H::T into my domain. :)
   - If I had concerns about how much memory I was consuming and/or how long
I keep a little-used template in memory, I have to build this into my logic.

2. My self-cached template's state is exactly as last output'ed. I can't
take for granted that default (think TMPL_ELSE) evaluations have their
default values. I always have to perform all evaluations (other than the
ones I did in the initialize).

To me this seems like something that could be useful to all H::T users. It
seems like it wouldn't burden H::T to have the option to specify that
evaluation be performed on the cached copy of the template?

Thanks!
Mark

I respect Sam's opinion on what should and shouldn't go into H::T, =
although I wouldn't consider some of the enhancements "feature creep" =
(ie I think not having TMPL_ELSIF would mean that a feature is missing) =
-> I thank him for producing a very use piece of code. =20

And these enhancements show that H::T can undergo more enhancements =
without 'breaking'... some of the features added to this version, are =
based on ideas from the people on this list -> they were added without a =
major re-architecture, more like a code evolution.

That said, the reason that I put together the functionality in my =
version of the H::T bundle was that I very-much needed certain =
functionality, such as:

- TMPL_ELSIF make my templates a lot clearer to read (under some =
circumstances)
- I absolutely need support for custom TMPL_xxx constructs
- I absolutely needed some bug fixes which Sam hasn't fixed


As to putting it up on CPAN... what would I call it ?    =
HTML::TemplateEnhanced ?

(note that most of these changes / enhancements cant be made by =
subclassing H::T...)

Mathew



> OK, I understand. So I guess my question is redirected to Mathew, =
could
> you subclass H::T and put your version on CPAN?
>=20
> > > Your version has some nice features that I could use, especially =
the
> > > recursive HTML::Template invocation.  Is there a reason why Sam =
has
> > > not included your mods into the CPAN version?
> >=20
> > The discussion of these changes is available in the mailing-list
> > archive.  If memory serves I didn't think that most of them required
> > changes to HTML::Template itself.  My feeling is that if
> > HTML::Template::Expr could be done without changes to HTML::Template
> > then there's really no limit on the changes that can be accomplished
> > by a sub-class using filter.
> >=20
> > Put simply, HTML::Template has suffered from feature-creap through =
its
> > life and it's nearly at the breaking point now.  The current =
code-base
> > won't remain maintainable with many more features added without a
> > major rearchitecture.  Someday maybe I'll do that and then all kinds
> > of extension will be easier...

On Tue, 11 Jan 2005, Mathew Robertson wrote:

> I respect Sam's opinion on what should and shouldn't go into H::T,
> although I wouldn't consider some of the enhancements "feature
> creep" (ie I think not having TMPL_ELSIF would mean that a feature
> is missing) -> I thank him for producing a very use piece of code.

Thanks, I appreciate that.  I'm certainly not above changing my mind
if enough people see a need for a particular feature.  I'm definitely
thinking about doing something about variable TMPL_INCLUDEs, for
example.

> And these enhancements show that H::T can undergo more enhancements
> without 'breaking'... some of the features added to this version,
> are based on ideas from the people on this list -> they were added
> without a major re-architecture, more like a code evolution.

When I think about the dangers of feature creep I think about
global_vars.  It's a great feature which I've come to think of as the
way HTML::Template should have worked from the beginning.  It's also a
terrible hack which still doesn't work quite right and clutters the
code in a number of places.

> - I absolutely needed some bug fixes which Sam hasn't fixed

Can you refresh my memory about these?

> (note that most of these changes / enhancements cant be made by
> subclassing H::T...)

Which ones would you consider impossible?  I'm sure I could implement
TMPL_xxx extensions and TMPL_ELSIF in a sub-class.

-sam

> > although I wouldn't consider some of the enhancements "feature
> > creep" (ie I think not having TMPL_ELSIF would mean that a feature
> > is missing) -> I thank him for producing a very use piece of code.
>=20
> Thanks, I appreciate that.  I'm certainly not above changing my mind
> if enough people see a need for a particular feature.  I'm definitely
> thinking about doing something about variable TMPL_INCLUDEs, for
> example.

ok - thats good to hear...
=20
> > And these enhancements show that H::T can undergo more enhancements
> > without 'breaking'... some of the features added to this version,
> > are based on ideas from the people on this list -> they were added
> > without a major re-architecture, more like a code evolution.
>=20
> When I think about the dangers of feature creep I think about
> global_vars.  It's a great feature which I've come to think of as the
> way HTML::Template should have worked from the beginning.  It's also a
> terrible hack which still doesn't work quite right and clutters the
> code in a number of places.

fair enough - the way I look at it is:

   if it works, then it will always be a better design that something =
which doesn't yet exist...

H::T may contain some hacks, but most of the cool stuff in this world, =
is a result of good hacks...  I consider H::T to be a good hack... :-)


> > - I absolutely needed some bug fixes which Sam hasn't fixed
>=20
> Can you refresh my memory about these?

The main one that needed fixing was that the wrong *fname *fcounter and =
*fmax where populated when reaching the end of more than one =
TMPL_INCLUDEd file.  Starting at line 2300, it reads:

    # count newlines in chunk and advance line count
    $fcounter +=3D scalar(@{[$chunk =3D~ m/(\n)/g]});
    # if we just crossed the end of an included file
    # pop off the record and re-alias to the enclosing file's info
    pop(@fstack), (*fname, *fcounter, *fmax) =3D \ ( =
@{$fstack[$#fstack]} )
      if ($fcounter > $fmax);


where as it should read:

    # count newlines in chunk and advance line count
    $fcounter +=3D scalar(@{[$chunk =3D~ m/(\n)/g]});
    # if we just crossed the end of an included file
    # pop off the record and re-alias to the enclosing file's info
    while ($fcounter > $fmax) {
      my $counter_offset =3D $fcounter - $fmax;
      pop(@fstack), (*fname, *fcounter, *fmax) =3D \ ( =
@{$fstack[$#fstack]} );
      $fcounter +=3D $counter_offset;
    }

Notice here that we pop() the current frame off multiple times, =
depending on how many TMPL_INCLUDEs deep were at.
I cant remember _why_ I needed it fixed, but I remember being bitten a =
few times when I forgot to apply the patch...


Another...

sub _normalise_options {...}  (line 1582) is used to push options into =
LOOPs, but doesn't work 100% of the time when used with H::T::E, as the:

   $template->{options}{expr}
   $template->{options}{expr_func}

values are not pushed into the LOOP.  Again I cant remeber why I fixed =
it, but it needed doing...  Note that this fix implies also pushing =
'expr ' and 'expr_func' onto the _new_from_loop(%hash) (ie where it is =
used in the '/TMPL_LOOP' test, line 2067)


And for the purests...  H::T::E should read (line 236):

  $self =3D $self->SUPER::output(...);

rather than :

  my $result =3D HTML::Template::output($self, ...);

just in case someone is overloading $self->output().


> > (note that most of these changes / enhancements cant be made by
> > subclassing H::T...)
>=20
> Which ones would you consider impossible?  I'm sure I could implement
> TMPL_xxx extensions and TMPL_ELSIF in a sub-class.

granted, if you can sub-class to create TMPL_xxx, you can quite easily =
create TMPL_ELSIF...  but TMPL_ELSIF is such a nice thing to have as =
part of the standard H::T....


As for custom TMPL_xxx, I dont see how you can simply subclass '_parse' =
to detect your custom tag, without impacting quite a large performance =
hit.   The simplest solution is to have H::T's big honking regex, =
capture TMPL_xxx directly; then if the user has the 'use_custom_tag' =
enabled in the options, call into the sub-class via a virtual function.


cheers,
Mathew

PS:  As for custom TMPL_VAR ESCAPE support (which I didn't mention =
before), I simply moved the package definitions into their own files so =
that H::T can dynamically load them.  This allows me to have as many =
useful/useless ESCAPE types that I care for, just by sub-classing from =
H::T::ESCAPE, ie, I can do the following:

   some html...<TMPL_VAR NAME=3D"data" ESCAPE=3D"MyCustomEscapeRoutine">

Where "MyCustomEscapeRoutine" gets auto-loaded by H::T...

Sam, earlier I said it would be useful if I could apply some evaluation
once. Then operate upon that partially evaluated template. I didn't realize
H::T applies everything at output(?).

If H::T applies everything at output, wouldn't it be relatively easy to
accomplish this if there was a way to tell H::T to perform an "output" *but
don't eliminate any H::T tags that are unevaluated*?

If I could do this, I could set all my one-time page evaluation and do a
"new_scalar_ref->" (using the output from my first "new->" from a file). If
there were a way to tell H::T to reload it internally there may be a way to
utilize H::T's caching mechanism (instead of me keeping my H::T object in
%hash_of_templates{language}). Doing a "new->" would have to tell me it
reloaded the template so that I could do the one-time processing again (and
output_internal-> to put it back into the state where it's mostely prepared
for repeated processing).

What do you think? Would it be easy to do by sub-classing?

Did you eventually agree there is a legitimate case for one-time page
evaluation? (One-time language replacement of title, headings, navigation,
etc.) I'd like to apply some heavy replacement and do it only once. Keep the
resulting text containing only the tags that are evaluated on a
display-by-display basis (messages, etc.).

This might have some application for select/option lists too. I won't
confuse the issue with that yet. My main concern is just to avoid repetitive
numerous replacement of text which is constant for a page.

Thanks!
Mark