Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE

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

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