html-template-users Mailing List for HTML::Template (Page 2)
Brought to you by:
samtregar
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(42) |
Jul
(80) |
Aug
(77) |
Sep
(97) |
Oct
(65) |
Nov
(80) |
Dec
(39) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(63) |
Feb
(47) |
Mar
(45) |
Apr
(63) |
May
(67) |
Jun
(51) |
Jul
(78) |
Aug
(37) |
Sep
(45) |
Oct
(59) |
Nov
(50) |
Dec
(70) |
2004 |
Jan
(23) |
Feb
(90) |
Mar
(37) |
Apr
(53) |
May
(111) |
Jun
(71) |
Jul
(35) |
Aug
(58) |
Sep
(35) |
Oct
(35) |
Nov
(35) |
Dec
(20) |
2005 |
Jan
(51) |
Feb
(19) |
Mar
(20) |
Apr
(8) |
May
(26) |
Jun
(14) |
Jul
(49) |
Aug
(24) |
Sep
(20) |
Oct
(49) |
Nov
(17) |
Dec
(53) |
2006 |
Jan
(12) |
Feb
(26) |
Mar
(45) |
Apr
(19) |
May
(19) |
Jun
(13) |
Jul
(11) |
Aug
(9) |
Sep
(10) |
Oct
(16) |
Nov
(17) |
Dec
(13) |
2007 |
Jan
(9) |
Feb
(12) |
Mar
(28) |
Apr
(33) |
May
(12) |
Jun
(12) |
Jul
(19) |
Aug
(4) |
Sep
(4) |
Oct
(5) |
Nov
(5) |
Dec
(13) |
2008 |
Jan
(6) |
Feb
(7) |
Mar
(14) |
Apr
(16) |
May
(3) |
Jun
(1) |
Jul
(12) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(9) |
2009 |
Jan
(9) |
Feb
|
Mar
(10) |
Apr
(1) |
May
|
Jun
(6) |
Jul
(5) |
Aug
(3) |
Sep
(7) |
Oct
(1) |
Nov
(15) |
Dec
(1) |
2010 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
(3) |
Mar
|
Apr
(28) |
May
|
Jun
|
Jul
(3) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
(8) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: <vij...@gm...> - 2011-04-29 21:45:19
|
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 vij...@gm... ----- Reply message ----- From: "David A. Bandel" <dav...@gm...> Date: Fri, Apr 29, 2011 17:28 Subject: [htmltmpl] TMPL_LOOP limit or count To: <htm...@li...> 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 Htm...@li... https://lists.sourceforge.net/lists/listinfo/html-template-users |
From: Michael P. <mp...@pl...> - 2011-04-29 21:36:41
|
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 |
From: David A. B. <dav...@gm...> - 2011-04-29 21:28:08
|
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/ |
From: Mathew R. <mat...@gm...> - 2011-04-13 05:21:49
|
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 |
From: Mathew R. <mat...@gm...> - 2011-04-12 00:41:25
|
> > 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 |
From: Clément O. <cle...@gm...> - 2011-04-08 08:44:36
|
Le 7 avril 2011 15:39, Michael Peters <mp...@pl...> 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. |
From: Mathew R. <mat...@gm...> - 2011-04-07 17:29:44
|
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 |
From: Michael P. <mp...@pl...> - 2011-04-07 13:38:43
|
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 |
From: Clément O. <cle...@gm...> - 2011-04-07 07:42:54
|
2011/4/6 Michael Peters <mp...@pl...>: > > 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. |
From: Lyle <web...@co...> - 2011-04-07 01:03:54
|
On 07/04/2011 01:41, Brad Baxter wrote: > On Wed, Apr 6, 2011 at 8:28 PM, Lyle<web...@co...> 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 |
From: Brad B. <bm...@ma...> - 2011-04-07 00:41:15
|
On Wed, Apr 6, 2011 at 8:28 PM, Lyle <web...@co...> 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 |
From: Lyle <web...@co...> - 2011-04-07 00:29:20
|
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 |
From: Lyle <web...@co...> - 2011-04-07 00:28:17
|
On 07/04/2011 00:36, Brad Baxter wrote: > On Wed, Apr 6, 2011 at 6:57 PM, Lyle<web...@co...> 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 |
From: Brad B. <bm...@ma...> - 2011-04-06 23:36:16
|
On Wed, Apr 6, 2011 at 6:57 PM, Lyle <web...@co...> 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 |
From: Alex T. <al...@ac...> - 2011-04-06 23:30:59
|
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 |
From: Lyle <web...@co...> - 2011-04-06 22:58:05
|
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 |
From: Lyle <web...@co...> - 2011-04-06 22:39:47
|
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 |
From: Brad B. <bm...@ma...> - 2011-04-06 22:37:23
|
On Wed, Apr 6, 2011 at 5:28 PM, Michael Peters <mp...@pl...> 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__ |
From: Alex T. <al...@ac...> - 2011-04-06 22:17:04
|
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 |
From: Matt T. <mt...@as...> - 2011-04-06 22:13:40
|
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, |
From: Michael P. <mp...@pl...> - 2011-04-06 21:52:40
|
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 |
From: Michael P. <mp...@pl...> - 2011-04-06 21:48:54
|
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 |
From: Roger B. W. <ro...@fi...> - 2011-04-06 21:32:43
|
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 |
From: Michael P. <mp...@pl...> - 2011-04-06 21:27:49
|
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 |
From: Brad B. <bm...@ma...> - 2011-04-06 21:13:21
|
On Wed, Apr 6, 2011 at 3:21 PM, Michael Peters <mp...@pl...> 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 |