Re: enhancements to H::T

> > > - TMPL_ELSIF tag, eg <TMPL_ELSIF somevar>
> >
> >I've certainly had a lot of requests for this feature, but I'm still
> >reluctant to include it.  I think it would only enable people to build
> >even more complex logic into their templates, which is not generally a
> >good idea.
> 
> Right now, people are attempting to code around the problem like this 
> (somewhat contrived example):
> 
> <TMPL_IF foo>
>      <p>foo is true</p>
> <TMPL_ELSE>
>      <TMPL_IF bar>
>          <p>bar is true</p>
>      <TMPL_ELSE>
>          <TMPL_IF baz>
>              <p>baz is true</p>
>          </TMPL_IF>
>      </TMPL_IF>
> </TMPL_IF>
> 
> Whatever complexity might be added by TMPL_ELSIF, it must be better then this.

agreed - using TMPL_ELSIF makes it look much clearer:

<TMPL_IF foo>
    <p>foo is true</p>
<TMPL_ELSIF bar>
    <p>bar is true</p>
<TMPL_ELSIF baz>
    <p>baz is true</p>
</TMPL_IF>

As for performance trade off's...  TMPL_ELSIF is implemented by expanding the 
TMPL_ELSIF into TMPL_IF-TMPL_ELSE-/TMPL_IF internally within H::T.  As such 
there is no performance difference -> the resultant cached template, appears in 
memory as if the user didn't use the TMPL_ELSIF syntax.

> > > - support for custom tags, eg <TMPL_CATGETS ...>
> >
> >I'll be interested to see how you coded this.  I'm not sure the
> >current code base can support this cleanly...  And even though I put
> >it in my HTML::Template v3 design doc I'm still not sure it's a good
> >idea.  (Go figure)

This was actually relatively easy... once I understood how H::T worked... 
inside out... :-)


> > > - trailing slash in tags, aka <TMPL... />
> >
> >This is trivially done in a filter, so there's no reason to add it to
> >the core code.
> 
> Filters strike me as being one of those things in Perl that look easy, but 
> often end up having subtle edge cases that will someday cause your computer 
> to create Global Thermonuclear War, or something.  Having hooks in the 
> parser (as stated in the v3 design) would be a very Good Thing, IMHO.

I have been caught by the 'lets use a filter' solution.  I needed the 
equivalent of:

<TMPL_INCLUDE <TMPL_VAR path>/info.tmpl>

ie recursive H::T.   This work well, for the first template parse - until the 
file was cached, since the filter is applied before the file is cached...   :-o


As someone else has mentioned, a filter package may be a good thing.   Since I 
am up for coding it, if anyone has any filters that they would want to make 
available.

So far I have two filters:
1. removal of the trailing slash....
2. the filter for <TMPL_VAR NAME="name" VALUE="value">


> > > - TVPL_VAR support for HTML=TEXT which allows paragraphs of text to be 
> > formatted to respect newlines
> >
> >This is easily done with HTML::Template::Expr and is too task-specific
> >to go in the core code.  I've done this task a few times and each time
> >I've done it a little differently (<br>&nbsp;<br> vs. <p>, wrapping
> >long lines vs. no wrap, etc.).

After having another look at the code, I think I could come up with a way at 
supporting ESCAPE="<something>" where 'something' is defined in a user created 
sub-class.  Would this be an alternate solution that you would consider?

Also, how would you do this with H::T::E?   I assume you would register a 
function which formats the blob of text according to your current stylesheet?

regards,
Mathew


-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills.  Sign up for IBM's
Free Linux Tutorials.  Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id78&alloc_id371&op=click