Re: [htmltmpl] Re: Patches for HTML-Template-2.5.tar.gz

[David K. <da...@po...>]

"Sam Tregar" <sa...@tr...> wrote:
>
> > <TMPL_IF NAME="item ne 'pizza' && price != 0.99">
>
> I really don't like putting expressions into the NAME attribute.  I think
> EXPR, as used in HTML::Template::Expr, is a better choice.

i don't like having a complex expression in the value of an attribute called
"name", either.  if the patch really improves expression evaluation speed,
maybe it should be resubmitted as a patch for HTML::Template::Expr?  since
we who don't use template expressions now can continue to simply not use
HTML::Template::Expr, and get the best performance of all :-)

> > 3. add a new way to access outside variables without global_vars
> >
> > This is a normal variable: <TMPL_VAR NORMAL>.<P>
> > <TMPL_LOOP NAME=FROOT_LOOP>
> >    Use it inside the loop: <TMPL_VAR __NORMAL><P>
> > </TMPL_LOOP>
>
> I really don't like this.  How is an HTML designer supposed to understand
> this bizarre syntax?

i can understand the need for a scoping syntax, but i don't like that one.
a naming convention is just not a syntax.  it is a name restriction!

> > 4. TMPL_VAR can now have a default value
> >
> >         <TMPL_VAR NAME="PARAMETER_NAME" VALUE="default value">
>
> Some people will like this, I imagine.  Maybe call it "DEFAULT"?  I think
> I might take this as a separate patch.  What do others think?

i like this.  i wouldnt use the attribute VALUE, though.  value implies
you're *assigning* a value, and you're not, necessarily.  you're assigning a
value if and only if none is set by perl.  i think <TMPL_VAR
NAME="PARAMETER_NAME" DEFAULT="default value"> would be more accurate and
cause less user confusion.


> > 5. add TMPL_DEF tag for defining new parameters
> >
> >         <TMPL_DEF NAME="NAME" VALUE="value">
>
> I don't like this.

i like it.  i've always wanted this.

> ...Mixing display logic with setup of variables is a very
> dangerous thing.

dangerous!, Sam? :-)  might it melt the browser or burn the users' fingers?
heheh.  seriously, though.  systems evolve, and programs change.  if an html
editor who maintains templates can "hard-code" or "override" a variable
value in a template in 30 seconds, to alter it in a way that would normally
require calling in the original programmer to change perl code, the only
"danger" i see is the danger that, by giving the "users" of a system more
control over (and therefore more responsibility for) the system, the
programmers (us!) might be given LESS control, responsibility, and thus, pay
:-)

then again, you're right.  this is much too dangerous for mere mortals.
dev/null the patch :-)

> > 6. add __count__ to loops
> >
> >          <TMPL_VAR NAME="__count__">-th record in the loop.
>
> Well, this something people are perpetually asking for, so I suppose I
> should add it at some point.  It's just so easy to do when you need it
> that I never considered it a priority.  Can you send me this one as a
> separate patch too?

you meant to say that conveniences like this are just so easy FOR A
PROGRAMMER to do in perl, when the *programmer* needs it, that we
programmers never consider giving lowly users this feature to be a priority.
the fact is IMHO features such as this ARE trivial to add when the templates
and program are being developed.  but those of who define our users (and in
many cases our customers) as HTML designers, giving non-programmers the
flexibility and power to maintain templates is a large value-add.  in many
cases we programmers sell a system by saying that "any HTML designer can
redesign the look and feel of the program output" by using our "powerful
templates".  by adding __count__ (and <tmpl default> and <tmpl_def>), i
think we work toward making good on those claims, empowering HTML designers
to do as much as possible without needing to re-hire us to alter the code.

-dave

(formerly <dkaufman at vm.com>)