html-template-users — Discussion of HTML::Template and related modules

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

[Yunliang Yu <yu...@ma...>]

Hi Sam,
That's a great idea & I'll get it in soon.
-yu

>
> I think a better implementation of defaulting would put the default onto
> the stack ahead of the variable.  Then output can just look ahead and see
> if the variable is defined to decide whether to output the value.
>

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

[Sam T. <sa...@tr...>]

On Thu, 25 Jul 2002, Brian McCain wrote:

> | On Thu, 25 Jul 2002, Philip S Tellis wrote:
> |
> | > What I would really like to see though is a <tmpl_elseif> and
> | > <tmpl_elseunless>.  That would really clean up some of my templates that
> | > have too many nested ifs.
> |
> | Mmm..  I've considered it at various points.  Each time I decide it would
> | only encourage more complicated logic in the templates.  I'm still leaning
> | in that direction although I will admit it's a close call.
> [snip]
>
> Maybe in HTML::Template::Expr?
> Just a thought.

I think that's unlikely to work out.  Adding <tmpl_elseif> would require
some fairly radical changes to the parser.  HTML::Template::Expr just uses
HTML::Template's parser and isn't really in the right place to implement
something like that.

-sam

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

[Brian M. <bm...@pa...>]

On Thursday, July 25, 2002, Sam Tregar wrote:


| On Thu, 25 Jul 2002, Philip S Tellis wrote:
|
| > What I would really like to see though is a <tmpl_elseif> and
| > <tmpl_elseunless>.  That would really clean up some of my templates that
| > have too many nested ifs.
|
| Mmm..  I've considered it at various points.  Each time I decide it would
| only encourage more complicated logic in the templates.  I'm still leaning
| in that direction although I will admit it's a close call.
[snip]

Maybe in HTML::Template::Expr?
Just a thought.

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

[Sam T. <sa...@tr...>]

On Thu, 25 Jul 2002, Yunliang Yu wrote:

> 	Process with standard HTML::Template     1.52s
> 	Process with my patched version          1.56s
>         Process with HTML::Template::Expr        2.39s
>
>        => patched version has 2.4% overhead, ::Expr 57% overhead

Did you enable any caching?  I would expect HTML::Template::Expr to lose
with caching off since it has to run a rather expensive parse on every
call.

> I didn't test memory usages, but changing "$value" to "->{value}=$value"
> adds a hash with only one element and shouldn't have too much impact.

Hashes automatically make room for multiple elements on the assumption
that they won't be used to store just one.  I think you'll be surprised
how much bigger a one-element hash is!

I think a better implementation of defaulting would put the default onto
the stack ahead of the variable.  Then output can just look ahead and see
if the variable is defined to decide whether to output the value.

> > Why did you force global_vars on for associate?  What does
> > explicit_global_vars do exactly?  It's not documented.
>
> $global_vars and $options->{global_vars} are totally different. Turning on
> $global_vars doesn't turn global_vars on. The main reason that I made the
> changes is to avoid global_vars and have expr support.

I still don't understand.

> 'VALUE=' was chosen so it looks similar to:
>   <INPUT TEXT NAME="Name" VALUE="Department of Mathematics">

Well, sure, but it doesn't do the same thing!  To me <tmpl_var name=foo
value=bar> looks like the variable foo is being assigned a value of "bar".
Assuming that I would be very surprised to find the tag outputting "baz"
because there's a $template->param(foo => 'baz') in a Perl file somewhere!
To me, DEFAULT gets the provisional nature of the assignment across
better.

> In one project, every page is designed by users, the programmer can't tell
> what data the page wants just by looking at the url. TMPL_DEF is the way
> the user passes requests back to the programmer. This way the user can
> create any url with any data, and the programmer only computes what's
> needed from the backend database. TMPL_DEF was introduced since it has
> not output.

$template->query() can be used for this purpose instead.  Just look at the
TMPL_VARs and TMPL_LOOPs that the user is requesting and you'll know what
to provide.

-sam

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

[Yunliang Yu <yu...@ma...>]

Hi Sam, thanks for your quick reply. Here I'll try to answer your
questions and clarify a few things.

> > 1. add extended expression support without impact on speed
>
> How did you test the speed of your changes?  Did you also check the memory
> impact?  Changing VAR objects from scalars to hashes will probably greatly
> expand the memory usage of large templates.
>
> Also, you're using string eval() to execute expressions.  Are you really
> sure that's faster than HTML::Template::Expr?  I wouldn't expect it to be,
> but I could be wrong.  Also, do your changes pass the HTML::Template::Expr
> test suite?
>
> > 		<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 ran a test with a simple template with 2 nested loops last night. For
the first test, the template contains no extended expr, just a few
HTML::Template variables. Here are the results on my test
system (standalone readhat 7.3, timed with 'time wget ....' & averaged,
CGI, results should be similar for mod-perl):

	Process with standard HTML::Template     1.52s
	Process with my patched version          1.56s
        Process with HTML::Template::Expr        2.39s

       => patched version has 2.4% overhead, ::Expr 57% overhead

For the 2nd test, insert <TMPL_VAR EXPR="test ne 'pizza'"> in the inner
loop, btw, the data was pulled from a local mysql server and the loops
returns 432 records.

	Process with my patched version         1.88s
        Process with HTML::Template::Expr       3.07s

      => HTML::Template::Expr is 63% slower than the patched version.

I didn't test memory usages, but changing "$value" to "->{value}=$value"
adds a hash with only one element and shouldn't have too much impact.

And, I may upload an optimized version today when I get some time.

>
> > 2. clean up global_vars implementation
>
> Why did you force global_vars on for associate?  What does
> explicit_global_vars do exactly?  It's not documented.

$global_vars and $options->{global_vars} are totally different. Turning on
$global_vars doesn't turn global_vars on. The main reason that I made the
changes is to avoid global_vars and have expr support.

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

Our HTML designers seem to do fine. I used to use the ::name notation (as
in C++). The designers we have know zero about perl.

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

'VALUE=' was chosen so it looks similar to:
  <INPUT TEXT NAME="Name" VALUE="Department of Mathematics">

>
> > 5. add TMPL_DEF tag for defining new parameters
> >
> >         <TMPL_DEF NAME="NAME" VALUE="value">
>
> I don't like this.  Mixing display logic with setup of variables is a very
> dangerous thing.

In one project, every page is designed by users, the programmer can't tell
what data the page wants just by looking at the url. TMPL_DEF is the way
the user passes requests back to the programmer. This way the user can
create any url with any data, and the programmer only computes what's
needed from the backend database. TMPL_DEF was introduced since it has
not output.

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

Best Regards,
-yu

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

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

[Sam T. <sa...@tr...>]

On Thu, 25 Jul 2002, Philip S Tellis wrote:

> What I would really like to see though is a <tmpl_elseif> and
> <tmpl_elseunless>.  That would really clean up some of my templates that
> have too many nested ifs.

Mmm..  I've considered it at various points.  Each time I decide it would
only encourage more complicated logic in the templates.  I'm still leaning
in that direction although I will admit it's a close call.

> It would specially make sense with multi state scripts that need to show
> a different body after every step of a form processing, but a lot of
> common stuff.

I tend to use <tmpl_incldue> with a header.tmpl and a footer.tmpl to deal
with that kind of a situation.

> (Is this what CGI::Application does?)

CGI::Application is a state-management system for CGI is mostly
CGI::template-system agnostic.  You could use it with
a single template for all run-modes or with a template for each.

-sam

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

[Philip S T. <phi...@gm...>]

On Wed, 24 Jul 2002, Sam Tregar wrote:

> >         <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'd agree with this. the default="" parameter would be quite useful to 
me.

> > 6. add __count__ to loops
> >
> >          <TMPL_VAR NAME="__count__">-th record in the loop.

Count is useful in many cases, but would really only be convenience.  
Not sure if it should be called __COUNT__ or __INDEX__ though.

Then of course, we could have __INDEX__ be the record number, and 
__COUNT__ be the total number of records.  Heh.  Ok, just kidding.

What I would really like to see though is a <tmpl_elseif> and 
<tmpl_elseunless>.  That would really clean up some of my templates that 
have too many nested ifs.

It would specially make sense with multi state scripts that need to show 
a different body after every step of a form processing, but a lot of 
common stuff.  (Is this what CGI::Application does?)

Philip

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

[simran <sim...@le...>]

On Thu, 2002-07-25 at 05:20, Sam Tregar wrote:

> On Wed, 24 Jul 2002, Yunliang Yu wrote:
> 
> > 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?

This one sounds like a brilliant idea. 

Its looks like a short form for:

  <tmpl_unless name="param_name">my_default</tmpl_unless>

  changes to:

  <tmpl_var name="param_name" value="my_default">

It would certainly make some templates a lot cleaner.

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


woohooo :-) 

Here is a patch i submitted a whlie ago that does nothing but a
'__counter__' variable if loop_context_vars is set. 


*** Template.pm.orig  Thu Apr 18 09:25:07 2002
--- Template.pm Thu Apr 18 09:30:56 2002
***************
*** 617,629 ****
  default) four loop context variables are made available inside a loop:
  __FIRST__, __LAST__, __INNER__, __ODD__.  They can be used with
  <TMPL_IF>, <TMPL_UNLESS> and <TMPL_ELSE> to control how a loop is
! output.  Example:

     <TMPL_LOOP NAME="FOO">
        <TMPL_IF NAME="__FIRST__">
          This only outputs on the first pass.
        </TMPL_IF>

        <TMPL_IF NAME="__ODD__">
          This outputs every other pass, on the odd passes.
        </TMPL_IF>
--- 617,636 ----
  default) four loop context variables are made available inside a loop:
  __FIRST__, __LAST__, __INNER__, __ODD__.  They can be used with
  <TMPL_IF>, <TMPL_UNLESS> and <TMPL_ELSE> to control how a loop is
! output.
!
! In addition to the above, a __COUNTER__ VAR is also made available
! when loop context variables are turned on.
!
! Examples:

     <TMPL_LOOP NAME="FOO">
        <TMPL_IF NAME="__FIRST__">
          This only outputs on the first pass.
        </TMPL_IF>

+       <TMPL_VAR NAME="__COUNTER__">
+
        <TMPL_IF NAME="__ODD__">
          This outputs every other pass, on the odd passes.
        </TMPL_IF>
***************
*** 1860,1869 ****
    # die_on_bad_params set output() will might cause errors
    # when it tries to set them.
    if ($options->{loop_context_vars}) {
!     $pmap{__first__} = HTML::Template::VAR->new();
!     $pmap{__inner__} = HTML::Template::VAR->new();
!     $pmap{__last__} = HTML::Template::VAR->new();
!     $pmap{__odd__} = HTML::Template::VAR->new();
    }
        } elsif ($which eq '/TMPL_LOOP') {
--- 1867,1877 ----
    # die_on_bad_params set output() will might cause errors
    # when it tries to set them.
    if ($options->{loop_context_vars}) {
!     $pmap{__first__}   = HTML::Template::VAR->new();
!     $pmap{__inner__}   = HTML::Template::VAR->new();
!     $pmap{__last__}    = HTML::Template::VAR->new();
!     $pmap{__odd__}     = HTML::Template::VAR->new();
!     $pmap{__counter__} = HTML::Template::VAR->new();
    }

        } elsif ($which eq '/TMPL_LOOP') {
***************
*** 2731,2741 ****
          @{$value_set}{qw(__first__ __inner__ __last__)} = (0,1,0);
        }
        $odd = $value_set->{__odd__} = not $odd;
      }
      $template->param($value_set);
      $result .= $template->output;
      $template->clear_params;
!     @{$value_set}{qw(__first__ __last__ __inner__ __odd__)} =
(0,0,0,0)
        if ($loop_context_vars);
      $count++;
    }
--- 2739,2750 ----
          @{$value_set}{qw(__first__ __inner__ __last__)} = (0,1,0);
        }
        $odd = $value_set->{__odd__} = not $odd;
+       $value_set->{__counter__} = $count + 1;
      }
      $template->param($value_set);
      $result .= $template->output;
      $template->clear_params;
!     @{$value_set}{qw(__first__ __last__ __inner__ __odd__
__counter__)} = (0,0,0,0,0)
        if ($loop_context_vars);
      $count++;
    }

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

[Cees H. <ce...@si...>]

Quoting Kenny Smith <ke...@jo...>:

> >> 5. add TMPL_DEF tag for defining new parameters
> >>
> >>         <TMPL_DEF NAME="NAME" VALUE="value">
> 
> >I don't like this.  Mixing display logic with setup of variables is a very
> >dangerous thing.
> 
> I don't even know what this is really useful for? If you are hard coding
> the
> definition of a variable in your template, why can't you just hard code
> that
> variable where you use it?

You can simulate most of this functionality already with the TMPL_INCLUDE
directive. Just create a new file with just the value of your template variable,
and then TMPL_INCLUDE it wherever you want it.  This has the added speed benefit
of being done before Caching takes place.

This would get messy if you have a lot of these constructs though, and they
wouldn't be available for use in TMPL_IF or TMPL_LOOP statements.

On that note, I would not recommend adding this feature in...

Cees

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

[Kenny S. <ke...@jo...>]

Hi Sam,

I don't know if you wanted external feedback on all of the bits, or just the
one you explicitly asked for... but, I generally overshare, so here ya go...

> > <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'd have to agree, there shouldn't be a need to make the name of a variable
into a variable.

>> 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 have to agree with that. Teaching an HTML designer the concept of variable
scope is a dangerous proposition.

> 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 think a DEFAULT="" is a great idea.

>> 5. add TMPL_DEF tag for defining new parameters
>>
>>         <TMPL_DEF NAME="NAME" VALUE="value">

>I don't like this.  Mixing display logic with setup of variables is a very
>dangerous thing.

I don't even know what this is really useful for? If you are hard coding the
definition of a variable in your template, why can't you just hard code that
variable where you use it?

Kenny Smith
JournalScape.com

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

[Sam T. <sa...@tr...>]

On Wed, 24 Jul 2002, Yunliang Yu wrote:

> Thanks for the wonderful HTML::Template module. I made a few changes
> while using it for my projects, hoping these changes will be useful for
> others:

Thanks!  I hope you don't mind, but I have some mixed feedback for you.
Please don't take it the wrong way - your work looks to be of excellent
quality.

> 1. add extended expression support without impact on speed

How did you test the speed of your changes?  Did you also check the memory
impact?  Changing VAR objects from scalars to hashes will probably greatly
expand the memory usage of large templates.

Also, you're using string eval() to execute expressions.  Are you really
sure that's faster than HTML::Template::Expr?  I wouldn't expect it to be,
but I could be wrong.  Also, do your changes pass the HTML::Template::Expr
test suite?

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

> 2. clean up global_vars implementation

Why did you force global_vars on for associate?  What does
explicit_global_vars do exactly?  It's not documented.

I think I'll need to read your patch a couple more times before I
understand exactly how your changes work.  Maybe you could give me a
summary?

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

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

> 5. add TMPL_DEF tag for defining new parameters
>
>         <TMPL_DEF NAME="NAME" VALUE="value">

I don't like this.  Mixing display logic with setup of variables is a very
dangerous thing.

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

Thanks,
-sam

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

[Yunliang Yu <yu...@ma...>]

Hi,

Thanks for the wonderful HTML::Template module. I made a few changes while
using it for my projects, hoping these changes will be useful for others:

1. add extended expression support without impact on speed

		<TMPL_IF NAME="item ne 'pizza' && price != 0.99">
			I got <TMPL_VAR NAME="item"> for
			<TMPL_VAR "price * count + 0.5"> dollars.
		<TMPL_ELSE>
			gee, free pizza!
		</TMPL_IF>

2. clean up global_vars implementation

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>

4. TMPL_VAR can now have a default value

        <TMPL_VAR NAME="PARAMETER_NAME" VALUE="default value">

5. add TMPL_DEF tag for defining new parameters

        <TMPL_DEF NAME="NAME" VALUE="value">

6. add __count__ to loops

         <TMPL_VAR NAME="__count__">-th record in the loop.

The patches are available at http://www.math.duke.edu/~yu/Template/

Thanks.
-yu

[htmltmpl] HTML::template with DBI (dynamic)

[Gerard t. H. <g.t...@pu...>]

Hello HTML::Template users,

I am working with DBI as a connection to a MySQL database and want
query-results to show with a template. However I would like to have one
general template file which can show all my query results. Maybe this is too
much a general Perl question about datastruct, therefore I apologize if this
is not the right place to ask.

So I have created a template (just a section) where I first have a have for
the columsheadings (columsnames) and then two loops nested for the data
(loop for columns and a loop for rows). See the TEMPLATE section below. So
far so good. This works fine. However my Perl code is quite bad (I think)
because I fetch everything from the database and then 're-order' it for the
template. Does anyone have any experience with this and knows how I can
improve my code? I' willing to learn so all suggestions to the code are
welcome !

Thanks in advance and kind regards!

Gerard ter Haar

--- Perl code ---
sub WSI_query_user {

	my $self = shift;
	my $q=$self->query();

	my $dbh=$self->param('mydbh');
 	my %varhash;

	my $query = "select WS, LastScan from recentdata
				where UCase(username) = UCase('$user')";

	my $sth = $dbh->prepare($query);
	$sth->execute(); 

	my $field;
	my @rowarray = ();
	foreach $field (@{$sth->{NAME}}) {
		my $fieldhash={};
		$fieldhash->{'rowval'}=$field;
		push(@rowarray, $fieldhash); 
	}
	$varhash{ 'head_loop' }=\@rowarray;

	my $array_ref;
	my @looparray;
	while ( $array_ref = $sth->fetchrow_arrayref ) {

		my %loophash;
		my @row2array = ();
		foreach $field (@$array_ref) {
			my $fieldhash={};
			$fieldhash->{'rowval'}=$field;
			push(@row2array, $fieldhash); 
		}

		$loophash{ 'viewrow_loop' }=\@row2array;
		push(@looparray, \%loophash);
	}
	$varhash{ 'view_loop' }=\@looparray;

	return &display_template( $self, 'qry_results_std.html', \%varhash
);
}
-- cut ---

--- TEMPLATE ---
<table width="100%" border=0 cellspacing=0 cellpadding=0>
  <tr class=menubody>
    <td width="5%"></td>
    <td width="90%"><br>
	  <p><center>
	    <table width=95% border=1>
		<tr>
		  <!-- TMPL_LOOP NAME="head_loop" -->
		  <th><!-- TMPL_VAR NAME="rowval" --></th>
		  <!-- /TMPL_LOOP -->
        		</tr>
		<!-- TMPL_LOOP NAME="view_loop" -->
		  <tr>
		    <!-- TMPL_LOOP NAME="viewrow_loop" -->
			<td><!-- TMPL_VAR NAME="rowval" --></td>
			<!-- /TMPL_LOOP -->
		  </tr>
		<!-- /TMPL_LOOP -->
		</table>
		<br>
		</center>
	  </p>
    </td>
	<td width="5%"></td>
  </tr>
</table>
--- cut ---

Re: [htmltmpl] Which templates exist in shared memory?

[Sam T. <sa...@tr...>]

On Wed, 17 Jul 2002, Flemming Mahler Larsen wrote:

> We're currently developing a fairly large extranet and using a lot of
> HTML::Template's. Due to this we switched to using the shared_cache, and
> I've gotten curious as to which templates is loaded when.

Frankly, I advise against this.  The shared_cache option performs equally
to the file_cache on a modern machine but is much harder to manage.  The
only thing shared_cache has going for it at this point is sex-appeal...

-sam

[htmltmpl] Which templates exist in shared memory?

[Flemming M. L. <ma...@DK...>]

Hi!

We're currently developing a fairly large extranet and using a lot of 
HTML::Template's. Due to this we switched to using the shared_cache, and 
I've gotten curious as to which templates is loaded when.

I'm sure someone must have a recipe on how to print a neatly formatted 
list of which templates are loaded into shared memory (and preferably a 
timestamp telling when the template was loaded.

Could that someone please post an example to the list?

I did try the following, which do tells me which template are loaded, 
but there must be a smarter way to go about it:
<sample>
#!/usr/local/bin/perl -w
use strict;
use IPC::SharedCache;

my %self;
tie %self, 'IPC::SharedCache',
ipc_key => 'TMPL',
ipc_segment_size => 65536,
load_callback => sub {},
validate_callback => sub {};

print "Content-type: text/plain\n\n";
print "(Shared memory) Cached templates :\n";
for (keys %self) {
print "* $_\n";
my $template = $self{"$_"};
}
</sample>

(( Flemming ))

-- 
Flemming Mahler Larsen, Online Technology @ TDC Internet
http://card.netfactory.dk/ , +45 3552 6452

[htmltmpl] Which templates exist in shared memory?

[Flemming M. L. <ma...@op...>]

Hi!

We're currently developing a fairly large extranet and using a lot of 
HTML::Template's. Due to this we switched to using the shared_cache, and 
I've gotten curious as to which templates is loaded when.

I'm sure someone must have a recipe on how to print a neatly formatted 
list of which templates are loaded into shared memory (and preferably a 
timestamp telling when the template was loaded.

Could that someone please post an example to the list?

I did try the following, which do tells me which template are loaded, 
but there must be a smarter way to go about it:
<sample>
#!/usr/local/bin/perl -w
use strict;
use IPC::SharedCache;

my %self;
tie %self, 'IPC::SharedCache',
ipc_key => 'TMPL',
ipc_segment_size => 65536,
load_callback => sub {},
validate_callback => sub {};

print "Content-type: text/plain\n\n";
print "(Shared memory) Cached templates :\n";
for (keys %self) {
print "* $_\n";
my $template = $self{"$_"};
}
</sample>

(( Flemming ))

-- 
Flemming Mahler Larsen, Online Technology @ TDC Internet
http://card.netfactory.dk/ , +45 3552 6452

Re: [htmltmpl] One-liner to convert array-of-hashes to an array

[Roger B. W. <ro...@fi...>]

On or about Tue, Jul 16, 2002 at 03:16:28PM +0530, Philip S Tellis typed:

>This might work:
>
>my @lov = map {$_->{$key}} @hash_array;

Not quite - this will insert undefs in the list if the key doesn't exist
in all hashes. See my version which checks for this.

Cheers,

Roger

Re: [htmltmpl] One-liner to convert array-of-hashes to an array

[Philip S T. <phi...@gm...>]

On Tue, 16 Jul 2002, Stefan Svensson wrote:

> Sorry for bothering you with a simple, off-topic question to which I can't 
> find any answer elsewhere.
> 
> Can someone provide a simple one-liner to convert a array-of-hashes to an
> array of values for a specified hash key?


Please note the change in list address.

This might work:

my @lov = map {$_->{$key}} @hash_array;

[htmltmpl] [patch] __counter__ variable

[simran <sim...@le...>]

i All, 

I sent the patch below (for a __COUNTER__) variable if loop_context_vars
was on - a while ago, but did not hear anything about it... maybe people
didn't find it that useful (or maybe it didn't make it to the list). 

Anyhow, Sam, what do you think about the patch below? 

It would be useful with pringing lists where you want them numbered, 
and also for things like:

  <tmpl_expr name="__COUNTER__ % 7">
    <tr>
  </tmpl_expr>
  for Table tr's if using a the HTML::Template::Expr template... 

simran.

On Thu, 2002-04-18 at 09:40, simran wrote:
> Hi All, 
> 
> There has recently been brief mention/discussion of the need for a
> 'counter' variable in a loop. 
> 
> Finding such a feature invaluable myself, i have included a patch
which
> makes a '__COUNTER__' variable available if loop_context_vars is
turned
> on (i had version 2.4 of HTML::Template).
> 
> Hope it makes it into the core... sam? 
> 
> kind regards, 
> 
> simran.
> 
> *** Template.pm.orig  Thu Apr 18 09:25:07 2002
> --- Template.pm Thu Apr 18 09:30:56 2002
> ***************
> *** 617,629 ****
>   default) four loop context variables are made available inside a
loop:
>   __FIRST__, __LAST__, __INNER__, __ODD__.  They can be used with
>   <TMPL_IF>, <TMPL_UNLESS> and <TMPL_ELSE> to control how a loop is
> ! output.  Example:
> 
>      <TMPL_LOOP NAME="FOO">
>         <TMPL_IF NAME="__FIRST__">
>           This only outputs on the first pass.
>         </TMPL_IF>
> 
>         <TMPL_IF NAME="__ODD__">
>           This outputs every other pass, on the odd passes.
>         </TMPL_IF>
> --- 617,636 ----
>   default) four loop context variables are made available inside a
loop:
>   __FIRST__, __LAST__, __INNER__, __ODD__.  They can be used with
>   <TMPL_IF>, <TMPL_UNLESS> and <TMPL_ELSE> to control how a loop is
> ! output.
> !
> ! In addition to the above, a __COUNTER__ VAR is also made available
> ! when loop context variables are turned on.
> !
> ! Examples:
> 
>      <TMPL_LOOP NAME="FOO">
>         <TMPL_IF NAME="__FIRST__">
>           This only outputs on the first pass.
>         </TMPL_IF>
> 
> +       <TMPL_VAR NAME="__COUNTER__">
> +
>         <TMPL_IF NAME="__ODD__">
>           This outputs every other pass, on the odd passes.
>         </TMPL_IF>
> ***************
> *** 1860,1869 ****
>     # die_on_bad_params set output() will might cause errors
>     # when it tries to set them.
>     if ($options->{loop_context_vars}) {
> !     $pmap{__first__} = HTML::Template::VAR->new();
> !     $pmap{__inner__} = HTML::Template::VAR->new();
> !     $pmap{__last__} = HTML::Template::VAR->new();
> !     $pmap{__odd__} = HTML::Template::VAR->new();
>     }
>         } elsif ($which eq '/TMPL_LOOP') {
> --- 1867,1877 ----
>     # die_on_bad_params set output() will might cause errors
>     # when it tries to set them.
>     if ($options->{loop_context_vars}) {
> !     $pmap{__first__}   = HTML::Template::VAR->new();
> !     $pmap{__inner__}   = HTML::Template::VAR->new();
> !     $pmap{__last__}    = HTML::Template::VAR->new();
> !     $pmap{__odd__}     = HTML::Template::VAR->new();
> !     $pmap{__counter__} = HTML::Template::VAR->new();
>     }
> 
>         } elsif ($which eq '/TMPL_LOOP') {
> ***************
> *** 2731,2741 ****
>           @{$value_set}{qw(__first__ __inner__ __last__)} = (0,1,0);
>         }
>         $odd = $value_set->{__odd__} = not $odd;
>       }
>       $template->param($value_set);
>       $result .= $template->output;
>       $template->clear_params;
> !     @{$value_set}{qw(__first__ __last__ __inner__ __odd__)} =
> (0,0,0,0)
>         if ($loop_context_vars);
>       $count++;
>     }
> --- 2739,2750 ----
>           @{$value_set}{qw(__first__ __inner__ __last__)} = (0,1,0);
>         }
>         $odd = $value_set->{__odd__} = not $odd;
> +       $value_set->{__counter__} = $count + 1;
>       }
>       $template->param($value_set);
>       $result .= $template->output;
>       $template->clear_params;
> !     @{$value_set}{qw(__first__ __last__ __inner__ __odd__
> __counter__)} = (0,0,0,0,0)
>         if ($loop_context_vars);
>       $count++;
>     }

Re: [htmltmpl] Dynamic Filters for cached templates forced recall ?

[Chris N. <chr...@in...>]

Oops. I've since been running an Apache/mod_perl combo with 
HTML::Template::JIT memory resident and have shifted the data population of 
the template to the mod_perl script using it a request processor as I should 
have realised originally. I'm now thinking of the template engine a bit like 
an SQL skeleton prepare statement. I was putting the data where the ? should 
have been.
Here's some interesting benchmarks for a simplistic template but shows the 
sheer power of the mod_perl/Apache combo:

Benchmark: timing 1000 iterations of cgi-cache, cgi-jit, cgi-nojit, 
modperl-cache, modperl-jit, modperl-nojit...
 cgi-cache: 257 wallclock secs ( 1.46 usr +  0.68 sys =  2.14 CPU) @ 467.29/s 
(n=1000)
   cgi-jit: 256 wallclock secs ( 1.27 usr +  0.54 sys =  1.81 CPU) @ 552.49/s 
(n=1000)
 cgi-nojit: 219 wallclock secs ( 1.15 usr +  0.52 sys =  1.67 CPU) @ 598.80/s 
(n=1000)
modperl-cache:  6 wallclock secs ( 1.39 usr +  0.47 sys =  1.86 CPU) @ 
537.63/s (n=1000)
modperl-jit:  5 wallclock secs ( 1.41 usr +  0.47 sys =  1.88 CPU) @ 531.91/s 
(n=1000)
modperl-nojit:  6 wallclock secs ( 1.45 usr +  0.51 sys =  1.96 CPU) @ 
510.20/s (n=1000)

marvellous.


On Thursday 11 July 2002 12:50, Chris Newman wrote:
> Hi,
> 	I want to be able to run HTML::Template::JIT or standard cached
> HTML::Template with a dynamic filter. I have run a filter which contains a
> call to a subroutine which does a remote data retrieval socket GET but it
> appears that HTML::Template is not dynamically re-calling this routine. I
> have looked at the Inline C for the JIT template and the remote data is
> just embedded as a normal string. Is there anyway to make this subroutine
> call be forced to be called every time (without switching off caching or
> sacrificing the JIT stuff) ?
> 	I have looked at alternatives such as building something into Apache to
> scan the delivered pages and re-parse a tag which I'd flag as dynamic but
> ideally want to be able to use the HTML::Template constructs on the dynamic
> data. Apologies if I'm missing something obvious.
>
> Chris
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> PC Mods, Computing goodies, cases & more
> http://thinkgeek.com/sf
> _______________________________________________
> Html-template-users mailing list
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users

[htmltmpl] Dynamic Filters for cached templates forced recall ?

[Chris N. <chr...@in...>]

Hi,
	I want to be able to run HTML::Template::JIT or standard cached 
HTML::Template with a dynamic filter. I have run a filter which contains a 
call to a subroutine which does a remote data retrieval socket GET but it 
appears that HTML::Template is not dynamically re-calling this routine. I 
have looked at the Inline C for the JIT template and the remote data is just 
embedded as a normal string. Is there anyway to make this subroutine call be 
forced to be called every time (without switching off caching or sacrificing 
the JIT stuff) ?
	I have looked at alternatives such as building something into Apache to scan 
the delivered pages and re-parse a tag which I'd flag as dynamic but ideally 
want to be able to use the HTML::Template constructs on the dynamic data.
	Apologies if I'm missing something obvious.

Chris

[htmltmpl] Translating templates

[Martijn v. d. B. <Mar...@as...>]

Hi,

Some of my HTML files contain both static and dynamic data (for example:
location-dependent URLs (dynamically filled with H::T) and welcome text
(static)).

I found that when an HTML template file is translated from my western
characterset into Japanese (unicode characterset) it can no longer be parsed
correctly by H::T.

Has anyone experienced similar problems? How can I solve this?


TIA,

Martijn

--
+----------------------------------+
        Martijn van den Burg
  ASML, CS PPC Inform@tion Systems
     Voice: +31 (0)40 268 3856
+----------------------------------+

[htmltmpl] global_vars / endless loops / HTML::Template::Expr

[Fran F. <fr...@mo...>]

Hello,

I'd really like to use HTML::Template::Expr, but I currently cannot
because it forces global_vars on, and global_vars causes an infinite
loop with my most complex template.  Is the infinite looping a known
issue?  The template that causes it is 7 or 8 nested TMPL_LOOP's, all
with the same exact name and contents (in order to enable me to display
in a generic fashion a tree hierarchy tool that can have up to 7 or 8
nested levels).

Also, I noticed the perldoc for HTML::Template::Expr mentions that
future versions might not force global_vars on, but I assume this
doesn't exist yet, correct?

I've included the affected template below.  It's ugly, be forewarned. :-)

I'm interested in knowing what in my template causes the endless looping
(which manifests itself as an endless stream of "### HTML::Template
Debug ### In output" lines in the server error log with debug turned on)
and if there's a fix which would allow me to use my template AND
HTML::Template::Expr.

I tried to add some logic to use Expr for all other templates and
vanilla HTML::Template for this one, but it seems to still loop - I
presume the 'use HTML::Template::Expr' is enough to load whatever code
forces global_var on??  Any tips much appreciated.

Thanks,
Fran


<html>
<head>
<title>Tree Test</title>
<script src="/lib/js/chimpkit/tree.js"></script>
<style type="text/css"><!--
@import url(/lib/css/chimpkit/tree.css);
@import url(/lib/css/chimpkit/<tmpl_var style>.css);
-->
</style>
</head>

<body bgcolor=ffffff onLoad="CallJS('ProgressDestroy()');">

<!---progress bar begin--->
<script src="/lib/js/chimpkit/progress.js"></script>
<!--- progress bar end--->

<span id=non_progress class=show>
<form name=form1>
<input type=hidden name=loading_code value=exist>
<tmpl_if regmode>
<input type=hidden name=tree_type value="Registration">
<tmpl_else>
<input type=hidden name=tree_type value="RMS">
</tmpl_if>
<table width=350><TR><TD>

<span id=-1 style="margin-left: 0px;">
<tmpl_loop tree>
   <span class=<tmpl_var type>><tmpl_if havechildren><a
href="javascript:toggleClamShellMenu('<tmpl_var entid>')"><img
name="img_<tmpl_var entid>" src="/images/<tmpl_if
preopen>mns<tmpl_else>pls</tmpl_if>.gif" align=middle
border=0></a><tmpl_else><img src="/images/blankpls.gif"
align=middle></tmpl_if>&nbsp;<img src="/images/<tmpl_var type>.gif"
align=middle>&nbsp;<tmpl_var name></span><br>

   <span id=<tmpl_var entid> class=CHILDREN style="{display:<tmpl_if
preopen>block<tmpl_else>none</tmpl_if>}">
   <tmpl_loop children>
     <span class=<tmpl_var type>><tmpl_if havechildren><a
href="javascript:toggleClamShellMenu('<tmpl_var entid>')"><img
name="img_<tmpl_var entid>" src="/images/<tmpl_if
preopen>mns<tmpl_else>pls</tmpl_if>.gif" align=middle
border=0></a><tmpl_else><img src="/images/blankpls.gif"
align=middle></tmpl_if> <img src="/images/<tmpl_var status>.gif"
align=middle>&nbsp;<img src="/images/<tmpl_var type>.gif"
align=middle>&nbsp; <a href="javascript:getNodeDetails('<tmpl_var
type>','<tmpl_var entid>',<tmpl_var regmode>);" class=<tmpl_var
type>><tmpl_var name></a></span><br>

     <span id=<tmpl_var entid> class=CHILDREN style="{display:<tmpl_if
preopen>block<tmpl_else>none</tmpl_if>}">
     <tmpl_loop children>
       <span class=<tmpl_var type>><tmpl_if havechildren><a
href="javascript:toggleClamShellMenu('<tmpl_var entid>')"><img
name="img_<tmpl_var entid>" src="/images/<tmpl_if
preopen>mns<tmpl_else>pls</tmpl_if>.gif" align=middle
border=0></a><tmpl_else><img src="/images/blankpls.gif"
align=middle></tmpl_if> <img src="/images/<tmpl_var status>.gif"
align=middle>&nbsp;<img src="/images/<tmpl_var type>.gif"
align=middle>&nbsp; <a href="javascript:getNodeDetails('<tmpl_var
type>','<tmpl_var entid>',<tmpl_var regmode>);" class=<tmpl_var
type>><tmpl_var name></a></span><br>

       <span id=<tmpl_var entid> class=CHILDREN style="{display:<tmpl_if
preopen>block<tmpl_else>none</tmpl_if>}">
       <tmpl_loop children>
         <span class=<tmpl_var type>><tmpl_if havechildren><a
href="javascript:toggleClamShellMenu('<tmpl_var entid>')"><img
name="img_<tmpl_var entid>" src="/images/<tmpl_if
preopen>mns<tmpl_else>pls</tmpl_if>.gif" align=middle
border=0></a><tmpl_else><img src="/images/blankpls.gif"
align=middle></tmpl_if> <img src="/images/<tmpl_var status>.gif"
align=middle>&nbsp;<img src="/images/<tmpl_var type>.gif"
align=middle>&nbsp; <a href="javascript:getNodeDetails('<tmpl_var
type>','<tmpl_var entid>',<tmpl_var regmode>);" class=<tmpl_var
type>><tmpl_var name></a></span><br>

         <span id=<tmpl_var entid> class=CHILDREN
style="{display:<tmpl_if preopen>block<tmpl_else>none</tmpl_if>}">
         <tmpl_loop children>
           <span class=<tmpl_var type>><tmpl_if havechildren><a
href="javascript:toggleClamShellMenu('<tmpl_var entid>')"><img
name="img_<tmpl_var entid>" src="/images/<tmpl_if
preopen>mns<tmpl_else>pls</tmpl_if>.gif" align=middle
border=0></a><tmpl_else><img src="/images/blankpls.gif"
align=middle></tmpl_if> <img src="/images/<tmpl_var status>.gif"
align=middle>&nbsp;<img src="/images/<tmpl_var type>.gif"
align=middle>&nbsp; <a href="javascript:getNodeDetails('<tmpl_var
type>','<tmpl_var entid>',<tmpl_var regmode>);" class=<tmpl_var
type>><tmpl_var name></a></span><br>

           <span id=<tmpl_var entid> class=CHILDREN
style="{display:<tmpl_if preopen>block<tmpl_else>none</tmpl_if>}">
           <tmpl_loop children>

             <span class=<tmpl_var type>><tmpl_if havechildren><a
href="javascript:toggleClamShellMenu('<tmpl_var entid>')"><img
name="img_<tmpl_var entid>" src="/images/<tmpl_if
preopen>mns<tmpl_else>pls</tmpl_if>.gif" align=middle
border=0></a><tmpl_else><img src="/images/blankpls.gif"
align=middle></tmpl_if> <img src="/images/<tmpl_var status>.gif"
align=middle>&nbsp;<img src="/images/<tmpl_var type>.gif"
align=middle>&nbsp; <a href="javascript:getNodeDetails('<tmpl_var
type>','<tmpl_var entid>',<tmpl_var regmode>);" class=<tmpl_var
type>><tmpl_var name></a></span><br>

             <span id=<tmpl_var entid> class=<tmpl_var type>
style="{display:<tmpl_if preopen>block<tmpl_else>none</tmpl_if>}">
             </span>

           </tmpl_loop>
           </span>

         </tmpl_loop>
         </span>

       </tmpl_loop>
       </span>

     </tmpl_loop>
     </span>

   </tmpl_loop>
   </span>

</tmpl_loop>
</span>

</TD></TR></TABLE>

</span>
</form>
</body>
</html>

Re: [htmltmpl] escaping quotes [was: (no subject)]

[Roger B. W. <ro...@fi...>]

On Mon, Jul 08, 2002 at 12:39:13AM -0700, Andrew Ho wrote:

>I think adding a generic escape=quote is a bad idea. That doesn't give any
>context, and JavaScript strings quote quotes way differently from (for
>example) HTML or SQL strings.

And SQL quoting is server-specific; and, perhaps more to the point,
there's already a perfectly good quoting method in DBI for SQL strings.

>I like the idea of adding a simple way to add functions to do quoting.

Agreed.

Roger