I'd also advocate that either of ELSIF and ELSEIF be allowed (since non-Perl programmers may be the HTML editors, and explaining the syntactical issues with "else if" and "elsif" to them would be an unnecessary waste of brain matter).
-Aaron
On Dec 9, 2003, at 2:08 PM, Timm Murray wrote:
At 01:40 PM 12/9/03 -0500, Sam Tregar wrote:On Tue, 9 Dec 2003, Mathew Robertson wrote:
> - TMPL_ELSIF tag, eg <TMPL_ELSIF somevar>
I've certainly had a lot of requests for this feature, but I'm still reluctant to include it. I think it would only enable people to build even more complex logic into their templates, which is not generally a good idea.
Right now, people are attempting to code around the problem like this (somewhat contrived example):
<TMPL_IF foo> <p>foo is true</p> <TMPL_ELSE> <TMPL_IF bar> <p>bar is true</p> <TMPL_ELSE> <TMPL_IF baz> <p>baz is true</p> </TMPL_IF> </TMPL_IF> </TMPL_IF>
Whatever complexity might be added by TMPL_ELSIF, it must be better then this.
> - support for custom tags, eg <TMPL_CATGETS ...>
I'll be interested to see how you coded this. I'm not sure the current code base can support this cleanly... And even though I put it in my HTML::Template v3 design doc I'm still not sure it's a good idea. (Go figure)
> - trailing slash in tags, aka <TMPL... />
This is trivially done in a filter, so there's no reason to add it to the core code.
Filters strike me as being one of those things in Perl that look easy, but often end up having subtle edge cases that will someday cause your computer to create Global Thermonuclear War, or something. Having hooks in the parser (as stated in the v3 design) would be a very Good Thing, IMHO.
> - TVPL_VAR support for HTML=TEXT which allows paragraphs of text to be formatted to respect newlines<snip>
This is easily done with HTML::Template::Expr and is too task-specific to go in the core code. I've done this task a few times and each time I've done it a little differently (<br> <br> vs. <p>, wrapping long lines vs. no wrap, etc.).
> - dot syntax, eg 'user.name'
Allowing dots in variable names seems harmless enough.
The thing is, 'user.name' isn't a variable name in the traditional way. Rather, it's saying 'I want the attribute "name" for the variable "user"', thus providing a more OO approach.
I imagine that this would be implemented by passing an object that provides accessors for the fields that would show up in the template. For the example above:
package My::UserVar; use base 'HTML::Template::Var'; # For example
sub new
{
my $class = shift;
my $in = shift || { };
return unless ref($in) eq 'HASH';
my $self = { map { $_ => $in->{$_} || '' } qw( name addr city state postal )};
bless $self, $class;
}
sub name { $_->{name} }
sub addr { $_->{addr} }
sub city { $_->{city} }
sub state { $_->{state} }
sub postal { $_->{postal} }
package main;
# $tmpl defined elsewhere, holding an HTML::Template object my $user = My::UserVar->new({ name => 'foo', addr => 'bar' }); $tmpl->param( user => $user );
-------------------------------------------------------
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
_______________________________________________
Html-template-users mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/html-template-users
------------------------------------------------------- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click _______________________________________________ Html-template-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/html-template-users
