Re: [htmltmpl] TMPL_LOOP limit or count

[<vijay.krishna.ramesh@gm...>]

Just a different way of thinking about it, but you could always output all the rows and use html/css to hide the ones after #15 or whatever. That way you're a bit more in keeping with data/presentation split that HTML::Template enforces...

Vijay Krishna Ramesh
vijay.krishna.ramesh@...

----- Reply message -----
From: "David A. Bandel" <david.bandel@...>
Date: Fri, Apr 29, 2011 17:28
Subject: [htmltmpl] TMPL_LOOP limit or count
To: <html-template-users@...>

Folks,

Been using HTML::Template in a few projects.  Really nice not to have
HTML tangled in the Perl code.

Got a largish hash I am sorting.  Want to output only about 15 lines
of the table.  Is there a way to tell the loop to stop?

Here's what I'm doing:

my @calloutdata;
foreach $callskey ( sort {$callnum{$b} <=> $callnum{$a}} keys %callnum){
    my %outbound;
    $outbound{EXTENNUMCALLED}  = $callskey;
    $outbound{TIMESCALLED}      = $callnum{$callskey};
    push( @calloutdata, \%outbound );
}

        $template->param( OUTBOUNDS => \@calloutdata );

The calloutdata array winds up to be about 200 lines long.  Any way to
have the TMPL_LOOP stop output after 15 or so table lines?

Nothing in the docs suggests a way to do this (or am I missing something?).

TIA,

David A. Bandel
-- 
Focus on the dream, not the competition.
            - Nemesis Air Racing Team motto
Visit my web page at: http://david.bandel.us/

------------------------------------------------------------------------------
WhatsUp Gold - Download Free Network Management Software
The most intuitive, comprehensive, and cost-effective network 
management toolset available today.  Delivers lowest initial 
acquisition cost and overall TCO of any competing solution.
http://p.sf.net/sfu/whatsupgold-sd
_______________________________________________
Html-template-users mailing list
Html-template-users@...
https://lists.sourceforge.net/lists/listinfo/html-template-users

Re: [htmltmpl] TMPL_LOOP limit or count

[Michael Peters <mpeters@pl...>]

On 04/29/2011 05:28 PM, David A. Bandel wrote:

> my @calloutdata;
> foreach $callskey ( sort {$callnum{$b}<=>  $callnum{$a}} keys %callnum){
>      my %outbound;
>      $outbound{EXTENNUMCALLED}  = $callskey;
>      $outbound{TIMESCALLED}      = $callnum{$callskey};
>      push( @calloutdata, \%outbound );
> }
>
>          $template->param( OUTBOUNDS =>  \@calloutdata );
>
> The calloutdata array winds up to be about 200 lines long.  Any way to
> have the TMPL_LOOP stop output after 15 or so table lines?

Well, the first thing I'd do is suggest that if possible you just don't 
put all 200 things into the loop. That would save on your processing if 
you didn't have to create the big loop to begin with.

But if you needed them in the loop in some places but didn't want to 
display them in others, you can use the __counter__ loop context var 
combined with HTML::Template::Expr.

<tmpl_loop outbounds>
   <tmpl_if expr="__counter__ <= 15">
     ...
   </tmpl_if>
</tmpl_loop>

> Nothing in the docs suggests a way to do this (or am I missing something?).

It's not possible with just HTML::Template, but HTML::Template::Expr 
should help you get there.

-- 
Michael Peters
Plus Three, LP

[htmltmpl] TMPL_LOOP limit or count

[David A. Bandel <david.bandel@gm...>]

Folks,

Been using HTML::Template in a few projects.  Really nice not to have
HTML tangled in the Perl code.

Got a largish hash I am sorting.  Want to output only about 15 lines
of the table.  Is there a way to tell the loop to stop?

Here's what I'm doing:

my @calloutdata;
foreach $callskey ( sort {$callnum{$b} <=> $callnum{$a}} keys %callnum){
    my %outbound;
    $outbound{EXTENNUMCALLED}  = $callskey;
    $outbound{TIMESCALLED}      = $callnum{$callskey};
    push( @calloutdata, \%outbound );
}

        $template->param( OUTBOUNDS => \@calloutdata );

The calloutdata array winds up to be about 200 lines long.  Any way to
have the TMPL_LOOP stop output after 15 or so table lines?

Nothing in the docs suggests a way to do this (or am I missing something?).

TIA,

David A. Bandel
-- 
Focus on the dream, not the competition.
            - Nemesis Air Racing Team motto
Visit my web page at: http://david.bandel.us/

Re: [htmltmpl] new work on HTML::Template

[Mathew Robertson <mathew.blair.robertson@gm...>]

Hi H::T users,

Last week there was a discussion regarding enhancements to H::T.
As a result, I have uploaded my enhancements to CPAN:

https://pause.perl.org/pub/PAUSE/authors/id/M/MA/MATHEW/

feel free to criticise... :)

regards,
Mathew Robertson

Re: [htmltmpl] new work on HTML::Template

[Mathew Robertson <mathew.blair.robertson@gm...>]

>
> Another feature request: would it be possible to use a var name in an
> include tag? The goal is to include a template whose name is the value
> of a var. Does someone already do such a thing?
>
> Clément.
>
>
Yes, you can do that now - if you call use the "recursive templates" I
listed above.

Regards,
Mathew Robertson

Re: [htmltmpl] new work on HTML::Template

[Clément OUDOT <clem.oudot@gm...>]

Le 7 avril 2011 15:39, Michael Peters <mpeters@...> a écrit :
> On 04/07/2011 03:42 AM, Clément OUDOT wrote:
>
>> We develop a special filter, called translate_template, that allows to
>> define<lang>  markup in the template with translations. When the
>> filter run, it only keep the translation of the user language. With
>> this, we have internationalized templates.
>
> We actually do something very similar in the Krang project. i18n is
> accomplished with <tmpl_lang> tags like so:
>
>  <tmpl_lang Please press the button>
>
> And the preprocessor will translate that into all of the supported languages
> and then it saves those translated templates to the file system.
>
>> Maybe we can try to include this feature in H::T core module?
>
> Honestly I don't think it's the right place. As you can see from my
> explanation above, there are lots of ways to do i18n. Also, as you can see
> we didn't want to take the hit at runtime so we pre-translate all templates
> at application startup and thus don't have to ever do it again until
> something changes and we then have to restart.
>
> I could see releasing either your filter approach, or the approach by Krang
> as separate modules onto CPAN, but not general enough for H::T
>

A separate module can be fine!

Another feature request: would it be possible to use a var name in an
include tag? The goal is to include a template whose name is the value
of a var. Does someone already do such a thing?

Clément.

Re: [htmltmpl] new work on HTML::Template

[Mathew Robertson <mathew.blair.robertson@gm...>]

Its interesting that thread of discussion has been raised....  I have been
using H::T for years - as a result, I have added most of these features to
my own instance.  Just this week I finished testing a new H::T::Bundle
module which I was going to upload to CPAN,

Features in my instance:
- some bugs fixed
- support for "die_on_unset_params" which causes the output() to die if the
programmer hasn't called param(somevar =>...) when 'somevar' exists in the
template
- big performance enhancement in the output() phase
- recursive templates (at a performance hit)
- output() by reference
- TMPL_ELSIF
- TMPL_REQUIRE - like TMPL_INCLUDE but only once ala Perl 'require'.
- support for simple perl-array based loops
- the ability to sub-class and so hook-in to create new TMPL_xxx semantics
- dynamic loading of ESCAPE modules
- 'includes_debug' which matches the other debug modes.
- profiling support
- preliminary support for objects, aka some_obj.some_attr, without having to
do this yourself
- support for "intrinsic_vars" such as '__type__' and '__filename__'
- '__even__' and '__outer__'  (TMPL_UNLESS __odd__ just seems wrong...)
- updated the docs
- updated some of the test cases.
- utf8 safe

TODO:
- support for automatic length param on loops
- more test cases for objects, as I'm not 100% sure I got everything.
- TMPL_LOOP support for non-hash rows.
- more test cases which covers the use-cases for reftype()

Via the H::T::Bundle sub-class I added:
- TMPL_SET
- support for pre-written filters (about a dozen so far)
- <% somevar %> implemented as a filter
- sane H::T defaults, as I think global_vars and loop_context_vars should be
the default
- Environmental variables in templates



A note regarding the "format" option - this could be implemented in a
sub-class using a new keyword, as in <TMPL_STRING var format=blah">  and/or
<TMPL_PRECISION var precision=blah>.  ie: extending TMPL_VAR is possible,
but given the hug number of possibilities,  it might be easier to do
something similar to <TMPL_CATGETS var> which is a implementation of the
gnus catgets() call, but from within templates (or just use a real
translation engine either via preprocessing or real-time ).


Thoughts?


cheers,
Mathew Robertson

Re: [htmltmpl] new work on HTML::Template

[Michael Peters <mpeters@pl...>]

On 04/07/2011 03:42 AM, Clément OUDOT wrote:

> We develop a special filter, called translate_template, that allows to
> define<lang>  markup in the template with translations. When the
> filter run, it only keep the translation of the user language. With
> this, we have internationalized templates.

We actually do something very similar in the Krang project. i18n is 
accomplished with <tmpl_lang> tags like so:

   <tmpl_lang Please press the button>

And the preprocessor will translate that into all of the supported 
languages and then it saves those translated templates to the file system.

> Maybe we can try to include this feature in H::T core module?

Honestly I don't think it's the right place. As you can see from my 
explanation above, there are lots of ways to do i18n. Also, as you can 
see we didn't want to take the hit at runtime so we pre-translate all 
templates at application startup and thus don't have to ever do it again 
until something changes and we then have to restart.

I could see releasing either your filter approach, or the approach by 
Krang as separate modules onto CPAN, but not general enough for H::T

-- 
Michael Peters
Plus Three, LP

Re: [htmltmpl] new work on HTML::Template

[Clément OUDOT <clem.oudot@gm...>]

2011/4/6 Michael Peters <mpeters@...>:
>
> Any questions? Comments? Verbal Abuse? Any offers of help?
>

Hi,

we use H::T in LemonLDAP::NG, a free Web Single Sign On
(http://lemonldap-ng.org), it is very helpful!

We develop a special filter, called translate_template, that allows to
define <lang> markup in the template with translations. When the
filter run, it only keep the translation of the user language. With
this, we have internationalized templates.

Maybe we can try to include this feature in H::T core module?

Clément.

Re: [htmltmpl] new work on HTML::Template

[Lyle <webmaster@co...>]

On 07/04/2011 01:41, Brad Baxter wrote:
> On Wed, Apr 6, 2011 at 8:28 PM, Lyle<webmaster@...>  wrote:
>> For further clarification, and without looking at the H::T implementation.
>> You are calling it an object because in the sense of the term 'object' the
>> template is an object. But, it's not a Perl object, which is likely where
>> further confusion comes from.
> Yes, it is a Perl object.  A "template" is a bunch of text.

Depends how abstract you want to look at things, many things are an 
object in the right context :)

>    An HTML::Template
> object is a Perl object ...

I see how you are visualising it now. I should probably have a looked at 
the implementation before posting that last message. I've now seen the 
HTML::Template::LOOP class, etc. I think for anyone who's just used the 
module and hasn't gone though it's internal code, it's clearer to talk 
about it in the sense of variable scoping; as the loops are easily 
interpreted as Perl blocks.

Thanks for clearing up the confusion :)


Lyle

Re: [htmltmpl] new work on HTML::Template

[Brad Baxter <bmb@ma...>]

On Wed, Apr 6, 2011 at 8:28 PM, Lyle <webmaster@...> wrote:
> For further clarification, and without looking at the H::T implementation.
> You are calling it an object because in the sense of the term 'object' the
> template is an object. But, it's not a Perl object, which is likely where
> further confusion comes from.

Yes, it is a Perl object.  A "template" is a bunch of text.  An HTML::Template
object is a Perl object ...

new()

Call new() to create a new Template object:

  my $template = HTML::Template->new( filename => 'file.tmpl',
                                      option => 'value'
                                    );
...
output()

output() returns the final result of the template. In most situations
you'll want to print this, like:

   print $template->output();
..
Calling output() is guaranteed not to change the state of the Template
object, in case you were wondering. This property is mostly important
for the internal implementation of loops.

----
http://search.cpan.org/dist/HTML-Template/Template.pm

Re: [htmltmpl] new work on HTML::Template

[Lyle <webmaster@co...>]

On 07/04/2011 00:30, Alex Teslik wrote:
> On Wed, 06 Apr 2011 17:53:01 -0400, Michael Peters wrote
>> Maybe a new "lexical_vars" option that will fall back to a parent-
>> loop or top-level declared var if one doesn't exist in the current
>> loop? That would be similar to the way vars work in Perl loops. Is
>> that what you're asking for?
> "lexical_vars" option would be perfect. If it could also be controlled in-loop
> that would be useful and time saving
>
> __lexical_vars =>  0

That sounds very sensible :)


Lyle

Re: [htmltmpl] new work on HTML::Template

[Lyle <webmaster@co...>]

On 07/04/2011 00:36, Brad Baxter wrote:
> On Wed, Apr 6, 2011 at 6:57 PM, Lyle<webmaster@...>  wrote:
>> I think using the term object here is confusing.
> I use the term "object", because it is in fact an object.

For further clarification, and without looking at the H::T 
implementation. You are calling it an object because in the sense of the 
term 'object' the template is an object. But, it's not a Perl object, 
which is likely where further confusion comes from.

Or are you talking about the implementation within H::T?


Lyle

Re: [htmltmpl] new work on HTML::Template

[Brad Baxter <bmb@ma...>]

On Wed, Apr 6, 2011 at 6:57 PM, Lyle <webmaster@...> wrote:
> On 06/04/2011 23:37, Brad Baxter wrote:
> ...
> So my complaint is that my perl code is setting the
> same values in the $tmpl object, but the module
> does not "honor" the value unless it sees the loop
> in the template a certain way.  My explanation is
> confusing, I know -- the whole situation is confusing
> (to me).  And that's what made me have to say
> enough finally after running into this multiple times.
>
> I think using the term object here is confusing. I gather you are talking
> about the scoping of variables? Such the loop variables should be within the
> scope (probably optionally) of child loops?

Yes, and yes (I think).  :-)

I use the term "object", because it is in fact an object.
And I'm used to setting values in objects and expecting
them to be there when I look back at them.

Typically these values are object attributes.  In H::T these
values are "variables" with "scopes".

An that's where my mental picture of setting values in
objects and H::T's implementation diverge. I want to
set "values" in the template "object" regardless of
what the "template" looks like, but H::T will choose
not to set some values if there isn't a scope for them
defined in the template.  And by default, it will die in
those cases.

Not to belabor the issue, the bottom line (ignoring speed)
comes down to inheritance, which I can't do in H::T as it
stands, because I want to define a parent template object
that contains *only* values (loops and vars) and doesn't
have a template at all.

__
Brad

Re: [htmltmpl] new work on HTML::Template

[Alex Teslik <alex@ac...>]

On Wed, 06 Apr 2011 17:53:01 -0400, Michael Peters wrote
> 
> Maybe a new "lexical_vars" option that will fall back to a parent-
> loop or top-level declared var if one doesn't exist in the current 
> loop? That would be similar to the way vars work in Perl loops. Is 
> that what you're asking for?

"lexical_vars" option would be perfect. If it could also be controlled in-loop
that would be useful and time saving

__lexical_vars => 0

Re: [htmltmpl] new work on HTML::Template

[Lyle <webmaster@co...>]

On 06/04/2011 23:37, Brad Baxter wrote:
> ...
> So my complaint is that my perl code is setting the
> same values in the $tmpl object, but the module
> does not "honor" the value unless it sees the loop
> in the template a certain way.  My explanation is
> confusing, I know -- the whole situation is confusing
> (to me).  And that's what made me have to say
> enough finally after running into this multiple times.

I think using the term object here is confusing. I gather you are 
talking about the scoping of variables? Such the loop variables should 
be within the scope (probably optionally) of child loops?


Lyle

Re: [htmltmpl] new work on HTML::Template

[Lyle <webmaster@co...>]

On 06/04/2011 22:41, Alex Teslik wrote:
> On Wed, 06 Apr 2011 15:21:13 -0400, Michael Peters wrote
>> After talking with Sam, he's given me permission to try to further
>> the development of HTML::Template to give some needed features while
>> maintaining the spirit that it was originally written in. That is,
>> to be a fast, straight forward and easy to learn templating engine.
> As long as the main feature of keeping logic completely separate from
> presentation is left intact, this is great news. The limitations of H::T are
> the exact reason we chose it as our templating system.

Very important. We certainly don't want this heading towards TT in any 
shape or form.

I think it's vital that H:T remain easy to learn and use for 
non-programmers i.e. web designers that only know HTML + CSS.

For me it's very important that my web designer can go in and happily 
change the whole design without my input. You just don't get this with 
TT, as design updates can often become a needlessly long winded and 
painful experience for both the web designer and programmer.


Lyle

Re: [htmltmpl] new work on HTML::Template

[Brad Baxter <bmb@ma...>]

On Wed, Apr 6, 2011 at 5:28 PM, Michael Peters <mpeters@...> wrote:
> On 04/06/2011 05:13 PM, Brad Baxter wrote:
>
>> But finally I decided I needed to abandon it,
>> because mentally I just couldn't handle the fact that setting an
>> attribute in the object was dependent on the attribute existing in
>> the template.
>
> I'm not sure I understand this problem. HTML template doesn't really work
> with objects, just hash references in loops. Are are you saying it was using
> your hash-based objects as if they were just hashes? That itself was
> probably not the best idea.
>
> Also, was this just a matter of turning die_on_bad_params off? I know it's
> the default, but if you don't want everything in your hashes to be in the
> template, then that's the right solution.

At the end of this note is code that produces this output:

0:[
    [] trees
    [rotten] logs
]

1:[
    [maple] trees
    [rotten] logs
]

2:[[maple] trees]

Note that "maple" appears in 1: but not in 0:, even though
the template object in both cases has these values set:

    $tmpl->param( trees  => [{ type => 'maple'  }] );
    $tmpl->param( forest => [{ logs => 'rotten' }] );

This is in fact documented:

NOTE: global_vars is not global_loops (which does not exist). That
means that loops you declare at one scope are not available inside
other loops even when global_vars is on.

So my complaint is that my perl code is setting the
same values in the $tmpl object, but the module
does not "honor" the value unless it sees the loop
in the template a certain way.  My explanation is
confusing, I know -- the whole situation is confusing
(to me).  And that's what made me have to say
enough finally after running into this multiple times.

You could say I want global everything, but what I
really want is for my template object to actually
contain the values that I set in it, so I can pass it
with "associate" to a child object.  I see someone
else is suggesting parent/child relationships be
supported, which is what I essentially was after.

>> __break__
>
> I looked at the docs for HTML::Template::Compiled (which are really sparse
> by the way with lots of circular references) and I'm not quite sure what it
> does.

It lets you output something on every
nth iteration, e.g. (from the docs),

The LOOP, WHILE and EACH tags allow you to define a BREAK attribute:

 <tmpl_loop bingo break="3"> <tmpl_var _ ><if __break__>\n</if></tmpl_loop>

    $htc->param(bingo => [qw(X 0 _ _ X 0 _ _ X)]);

outputs

    X 0 _
    _ X 0
    _ _ X


(Code for above maple trees/rotten logs example:)

#!/usr/local/bin/perl

use strict;
use warnings;
use HTML::Template;

DEMO_A: {
    my $text = <<_end_;
0:[<TMPL_LOOP forest>
    [<TMPL_LOOP trees><TMPL_VAR type></TMPL_LOOP>] trees
    [<TMPL_VAR logs>] logs
</TMPL_LOOP>]
_end_

    my $tmpl = HTML::Template->new(
    scalarref         => \$text,
    global_vars       => 1,
    die_on_bad_params => 0,
    );

    $tmpl->param( trees  => [{ type => 'maple'  }] );
    $tmpl->param( forest => [{ logs => 'rotten' }] );

    print $tmpl->output;
}

DEMO_B: {
    my $text = <<_end_;

1:[<TMPL_LOOP forest>
    [<TMPL_LOOP trees><TMPL_VAR type></TMPL_LOOP>] trees
    [<TMPL_VAR logs>] logs
</TMPL_LOOP>]

2:[<TMPL_LOOP trees>[<TMPL_VAR type>]</TMPL_LOOP> trees]

_end_

    my $tmpl = HTML::Template->new(
    scalarref         => \$text,
    global_vars       => 1,
    die_on_bad_params => 0,
    );

    $tmpl->param( trees  => [{ type => 'maple'  }] );
    $tmpl->param( forest => [{ logs => 'rotten' }] );

    print $tmpl->output;
}

__END__

Re: [htmltmpl] new work on HTML::Template

[Alex Teslik <alex@ac...>]

On Wed, 06 Apr 2011 15:21:13 -0400, Michael Peters wrote
> This email is an announcement of sorts for some work I've got 
> planned for HTML::Template. I'm greatly in debt to Sam Tregar for 
> this module and the use that I've gotten out it over the years.
> 
> After talking with Sam, he's given me permission to try to further 
> the development of HTML::Template to give some needed features while 
> maintaining the spirit that it was originally written in. That is, 
> to be a fast, straight forward and easy to learn templating engine. 


As long as the main feature of keeping logic completely separate from
presentation is left intact, this is great news. The limitations of H::T are
the exact reason we chose it as our templating system.


> To that end, I've got the following goals:
> 
> + Add a <tmpl_elsif> tag

YES, PLEASE!

> + User defined escapes

Also welcome.

> Any questions? Comments? Verbal Abuse? Any offers of help?

If there were a way for child loops to use vars from the parent loop if they
do not exist in the child, it would be great. The global_vars feature puts the
vars into -every- loop, which is overkill and incurs a very hefty speed
penalty. It also clobbers same named vars in the child. As a result we don't
use global_vars at all and manually populate child loops with parent vars
explicitly as needed. This makes the perl get a little ugly but prevents the
speed hit.

All in all, great news. The module still works great, but improvements are
always welcome!

Thanks,
Alex

Re: [htmltmpl] new work on HTML::Template

[Matt Taylor <mtaylor@as...>]

I'm not a very advanced user, but I would like to see one minor change.

I would like to be able to include a closing slash, for example:
<tmpl_var name=foo />

Just because jEdit's html mode gets confused when trying to identify 
beginning and ending tags.

Matt


On 04/06/2011 01:21 PM, Michael Peters wrote:
> This email is an announcement of sorts for some work I've got planned
> for HTML::Template. I'm greatly in debt to Sam Tregar for this module
> and the use that I've gotten out it over the years.
>
> After talking with Sam, he's given me permission to try to further the
> development of HTML::Template to give some needed features while
> maintaining the spirit that it was originally written in. That is, to be
> a fast, straight forward and easy to learn templating engine. To that
> end, I've got the following goals:
>
> + Move HTML::Template development to github. My repo is located at:
>     https://github.com/mpeters/html-template
> + Use default perltidy settings
> + Use Dist::Zilla for release management
> + Go through the current RT queue and do some fixes, updates and triage.
> + Add a<tmpl_elsif>  tag
> + Add a "format" attribute with built-in and user defined formats:
>      <tmpl_var cost>
>      <tmpl_var cost format="currency">
>      <tmpl_var cost format="number">
> + User defined escapes
> + Add an encoding param to more easily handle UTF8/Unicode.
> + Break out parsing of templates into HTML::Template::Parser so that
>     templates can be parsed and manipulated outside of rendering. And use
>     HTML::Template::Parser internally in HTML::Template.
>
> And for HTML::Template::Expr I want to do:
> + Allow boolean "!" in expressions for things like:
>     <tmpl_if expr="foo&&  !bar">...</tmpl_if>
> + Allow "||" to work more like Perl's "||" when used in a<tmpl_var>  :
>     <tmpl_var expr="foo || bar">
>
> Other ideas I'm on the fence about:
> + Like HTML::Template::Plugin::Dot allow methods to be called on
>     objects:
>     <tmpl_var start_date.mdy('-')>
> + Add a<tmpl_set>  tag. Could be useful for template driven behaviors
>     (combined with param() or query()) or when combined with
>     <tmpl_include>:
>
> Any questions? Comments? Verbal Abuse? Any offers of help?
>
> Thanks,

Re: [htmltmpl] new work on HTML::Template

[Michael Peters <mpeters@pl...>]

On 04/06/2011 05:41 PM, Alex Teslik wrote:

> As long as the main feature of keeping logic completely separate from
> presentation is left intact, this is great news. The limitations of H::T are
> the exact reason we chose it as our templating system.

Yes definitely. We use it heavily in places where users aren't that 
sophisticated and even if they are, we want to restrict the damage that 
they could do with just templates.

> If there were a way for child loops to use vars from the parent loop if they
> do not exist in the child, it would be great. The global_vars feature puts the
> vars into -every- loop, which is overkill and incurs a very hefty speed
> penalty. It also clobbers same named vars in the child. As a result we don't
> use global_vars at all and manually populate child loops with parent vars
> explicitly as needed. This makes the perl get a little ugly but prevents the
> speed hit.

Maybe a new "lexical_vars" option that will fall back to a parent-loop 
or top-level declared var if one doesn't exist in the current loop? That 
would be similar to the way vars work in Perl loops. Is that what you're 
asking for?

-- 
Michael Peters
Plus Three, LP

Re: [htmltmpl] new work on HTML::Template

[Michael Peters <mpeters@pl...>]

On 04/06/2011 05:12 PM, Roger Burton West wrote:

> Sure, what do you need? H::T has been good to me.

Right now, I think just being available to test things would be a good 
start. I'm hoping to have an initial release in the not too distant 
future that doesn't do much except fix some small bugs from RT and do 
some code organization changes (Dist::Zilla, perltidy, etc). I'll post 
an announcement when that happens.

-- 
Michael Peters
Plus Three, LP

Re: [htmltmpl] new work on HTML::Template

[Roger Burton West <roger@fi...>]

On Wed, Apr 06, 2011 at 03:21:13PM -0400, Michael Peters wrote:
>+ Add a <tmpl_set> tag. Could be useful for template driven behaviors
>   (combined with param() or query()) or when combined with
>   <tmpl_include>:

I've found this very useful, though:

(a) I'm not sure it needs to live in the base module;

(b) the behaviour within loops would need to be carefully defined.

(My quick hack simply ignores loops.)

>Any questions? Comments? Verbal Abuse? Any offers of help?

Sure, what do you need? H::T has been good to me.

R

Re: [htmltmpl] new work on HTML::Template

[Michael Peters <mpeters@pl...>]

On 04/06/2011 05:13 PM, Brad Baxter wrote:

> But finally I decided I needed to abandon it,
> because mentally I just couldn't handle the fact that setting an
> attribute in the object was dependent on the attribute existing in
> the template.

I'm not sure I understand this problem. HTML template doesn't really 
work with objects, just hash references in loops. Are are you saying it 
was using your hash-based objects as if they were just hashes? That 
itself was probably not the best idea.

Also, was this just a matter of turning die_on_bad_params off? I know 
it's the default, but if you don't want everything in your hashes to be 
in the template, then that's the right solution.

> __index__ (__counter__-1)

I can see adding that one. It can be derived from counter, but making 
you use HTML::Template::Expr to derive it could be a pain.

> __break__

I looked at the docs for HTML::Template::Compiled (which are really 
sparse by the way with lots of circular references) and I'm not quite 
sure what it does. Does it stop the current loop? If so, that seems like 
a really bad idea for just a specially named tmpl_var. Although, I could 
see the use in a <tmpl_break> tag.

Thanks for the feedback.

-- 
Michael Peters
Plus Three, LP

Re: [htmltmpl] new work on HTML::Template

[Brad Baxter <bmb@ma...>]

On Wed, Apr 6, 2011 at 3:21 PM, Michael Peters <mpeters@...> wrote:
> Any questions? Comments? Verbal Abuse? Any offers of help?

I have some comments which are intended to be constructive,
though they may come across as otherwise.  I apologize in
advance.

I used HTML::Template for a few years.  I was happy with the
functionality.  The speed was okay, but I kept looking for ways
to improve it.  But finally I decided I needed to abandon it,
because mentally I just couldn't handle the fact that setting an
attribute in the object was dependent on the attribute existing in
the template.

I ended up writing my own templating system with the functionality
of H::T that was based solely on regular expressions.  This gave me
a 40% speed increase in the context of how I am using templates.

In addition, I can set attribute values in my objects whether or not
those attributes exist in the template, allowing me to build a hierarchy
of template objects (with children inheriting values from their parents).

The cost to the programmer is a bit of verbosity, e.g., instead of
<TMPL_LOOP NAME="LOOP_NAME"> ... </TMPL_LOOP>
one must write
<TMPL_LOOP NAME="LOOP_NAME"> ... </TMPL_LOOP NAME="LOOP_NAME">

But 40% is 40%, plus I got the object behavior that I could live with.

So having said all that, I want to suggest looking at the various
H::T-base modules on CPAN to see what they implement that might
be good for the base H::T code.  I looked at H::T::Compiled (in my
quest for speed) and found the following loop variables that I liked
and adopted in my module:

__index__ (__counter__-1)
__break__

There are others (like TMPL_ELSIF) that might also find a home
in the base module.

Conclusion:

- Take what I say with a grain of salt, since I stopped using H::T  :-)
- Take a look at the other H::T-based modules to see if they give
  some additional ideas.

Regards,

Brad