Re: [htmltmpl] enhancements to H::T

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

> > > - 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.
>=20
> Right now, people are attempting to code around the problem like this=20
> (somewhat contrived example):
>=20
> <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>
>=20
> 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.
>=20
> Filters strike me as being one of those things in Perl that look easy, =
but=20
> often end up having subtle edge cases that will someday cause your =
computer=20
> 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=3D"name" VALUE=3D"value">


> > > - TVPL_VAR support for HTML=3DTEXT which allows paragraphs of text =
to be=20
> > 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=3D"<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