Thread: Re: [htmltmpl] Re: H::T future (Page 2)
Brought to you by:
samtregar
Menu
▾
▴
html-template-users
|
From: Cees H. <ce...@si...> - 2003-12-09 21:07:44
|
Puneet Kishor wrote: > I know that you don't mean to state that in an absolute sort of way, No, I am just explaining the way things work (or don't work) for me, but TMTOWTDI :) > because I disagree. I also include headers/footers, and code title and > bunch of other things in the headers and footers. Most of the time the > title of the page is dynamic precisely because it describes dynamic > contents of a page. The designer should not worry about what the title > is... the designer should only worry about how the <title> should look. I try to give the template designers the freedom to change as much of the text that is displayed to the user that is possible. Since the template designer is already building the content part of this particular dynamic page, they should realize what would be an appropriate title for the page based on that what they are building. I believe that if a designer has an issue with the way something is worded, then they should not have to ask a programmer to change it. That is why we have templates... I even go to the extent of allowing the designers to choose error messages for the users if they wish. When an error condition occurs (invalid form fields or something like that), I provide descriptive error keys with a default message that the designer can override if they choose: <TMPL_IF errors> <span style="color: red"> <TMPL_IF email_invalid>The email address you provided does not look valid<br /></TMPL_IF> <TMPL_IF address_missing>You are required to fill out the address field<br /></TMPL_IF> </span> </TMPL_IF> I feel this gives more power to the designers without needing to make things any more complex. Another benefit of placing as much text as possible in the templates is localization. Translation can occur at the template level instead of needing to translate the text provided by the code and then also translating the text in the template... > Keep it simple. That is why it is fast. That is why it works. That is > why it is easy to understand. And that is why we like it here over other > blahblah templating systems... Simplicity and speed are the 2 most important strengths of HTML::Template in my opinion, and I wouldn't want to interfere with those goals. But complexity in the templates is added by the programmer, not by the module itself. A new feature in the module does not automatically transfer into a more complex template or more complex code... In many cases a new feature can simplify both code and template (the TMPL_ELSIF is an example where it can simplify the template in certain circumstances)) I admire Sam for his persistence in keeping things simple, and eliminating the feature creep that has damaged many other projects. But, I am often finding myself doing things that I don't like, just to get around some of the constraints of the template language. Anyway, I am nowhere near annoyed enough to ditch HTML::Template. It is still in my top 10 most used modules and it will keep its place for the forseeable future... Cheers, Cees |
|
From: Karen J. C. <si...@ph...> - 2003-12-09 18:31:16
|
On Tue, 9 Dec 2003, Lance A. Brown wrote: LAB>Here is the relevant piece of code. Personally, I think this is a VERY LAB>tasty hack. It lets page designers plug parameters back into the LAB>templating system for use elsewhere. Very cool. Nifty, but not exactly what I was looking for; I was thinking more along the lines of a few lines at the beginning of the file (a la Twiki) with the parameters, and the rest being a standard H::T template. Then you just call the micro-config-reader bit *if* you need it, and when it's done with its bit at the beginning, it calls H::T for the rest. That way, you gain the ability to have parms and template in the same file for convenience' sake, but you don't have to parse every single template in case it has parms (which might even pose a security risk, if you're letting users make skins using H::T). You'd probably want to config bit at the beginning of the file to be enclosed in comment delimiters just in case you wanted to be able to call H::T on the entire file. Of course, that'd leave the params visible in the finished product, which might itself be a security breach, so at a certain point you have to decide to separate the config from the user content. -- Karen J. Cravens si...@ph... |
|
From: Cees H. <ce...@si...> - 2003-12-09 02:04:28
|
Sam Tregar wrote: > I've considered doing an HTML::Template version 3 a few times, but > never found the time to do it. I even went so far as to draft a > design document. Here it is! (Note, I have no plans to actually do > this work anytime soon.) Hi Sam, Something that might be of interest to you that I came across just the other day, is the design documents for the up coming Template Toolkit 3. I have always found that HTML::Template and Template Toolkit complement each other, and each have their own niche. However, if you haven't already done so, I would recommend reading the following document by Andy Wardley where he talks about some of the changes he plans to implement in TT 3. http://www.template-toolkit.org/tt3/design/namespace.html He seems to mirror several of the suggestions that you are making in your notes. The most interesting thing I noticed is that he hopes to include 'Language Packs', where the module can support other templating languages, like HTML::Template and Mason... I would be very interested in seeing a module that was able to gather the best of both modules under one roof (still allowing the strict simplicity of HTML::Template, or if warrented turning on some of the power of TT). One concern I see is that one of the key reasons people use HTML::Template is the blazing speed that it performs at. I fear that too much abstraction and generalization may hamper that (it doesn't have to, but it may). For now I will continue to use HTML::Template and TT2 where I see fit... Cheers, Cees |
|
From: Mathew R. <mat...@re...> - 2003-12-09 04:06:00
|
test - please ignore |
|
From: Mathew R. <mat...@re...> - 2003-12-09 04:22:15
|
> > But, since not being able to visualize the form of H-T's future = might be > > due to my lack of imagination, I am curious -- what are the ways in > > which the developer-kind want to see H-T to be in a few = years/versions > > or so... I have modifie a local copy of H::T which includes some changes which = may or may not be of use to others. The changes include: - TMPL_ELSIF tag, eg <TMPL_ELSIF somevar> - support for custom tags, eg <TMPL_CATGETS ...> - trailing slash in tags, aka <TMPL... /> - TVPL_VAR support for HTML=3DTEXT which allows paragraphs of text to be = formatted to respect newlines - dot syntax, eg 'user.name' - dot syntax with autovivification of leading template variable, eg = 'user.name' results in autovivification of 'user' I have included documentation to support the enhancements. Also, I have bumped the revision number to 2.7 so as to indicate a = non-standard release. I can sen this modified/enhanced version to anyone who is interested. regards, Mathew |
|
From: Sam T. <sa...@tr...> - 2003-12-09 18:39:14
|
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. > - 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. > - TVPL_VAR support for HTML=TEXT which allows paragraphs of text to be formatted to respect newlines 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. > - dot syntax with autovivification of leading template variable, eg 'user.name' results in autovivification of 'user' I know you explained this to me earlier, but I still don't understand the value of this feature. So far HTML::Template hasn't cared what you name your variables and I'm somewhat loathe to start now. This is also something that's easily done with an overridden param() in a sub-class. > I have included documentation to support the enhancements. Also, I > have bumped the revision number to 2.7 so as to indicate a > non-standard release. Someday there will be an HTML::Template 2.7, so this isn't a good fake revision number. Something like 2.6_01 would be better. That's the standard CPAN notation for beta releases. -sam |
|
From: Mathew R. <mat...@re...> - 2003-12-10 01:20:57
|
> > I have included documentation to support the enhancements. Also, I > > have bumped the revision number to 2.7 so as to indicate a > > non-standard release. >=20 > Someday there will be an HTML::Template 2.7, so this isn't a good fake > revision number. Something like 2.6_01 would be better. That's the > standard CPAN notation for beta releases. ok - will do. Mathew |
|
From: Timm M. <tm...@ag...> - 2003-12-09 19:09:05
|
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
>
>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.
<snip>
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 );
|
|
From: Aaron J.M. <am...@vi...> - 2003-12-09 19:18:04
|
If it matters, I second this opinion; it actually gets much worse than
this in real life when the HTML between the conditionals is more than
one line long and itself contains additional "local" conditions.
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
>>
>> 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.
> <snip>
>
>
> 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
> Htm...@li...
> https://lists.sourceforge.net/lists/listinfo/html-template-users
>
|
|
From: Mathew R. <mat...@re...> - 2003-12-10 00:07:28
|
> > > - 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.
>=20
> Right now, people are attempting to code around the problem like this=20
> (somewhat contrived example):
>=20
> <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>
>=20
> Whatever complexity might be added by TMPL_ELSIF, it must be better =
then this.
agreed - using TMPL_ELSIF makes it look much clearer:
<TMPL_IF foo>
<p>foo is true</p>
<TMPL_ELSIF bar>
<p>bar is true</p>
<TMPL_ELSIF baz>
<p>baz is true</p>
</TMPL_IF>
As for performance trade off's... TMPL_ELSIF is implemented by =
expanding the TMPL_ELSIF into TMPL_IF-TMPL_ELSE-/TMPL_IF internally =
within H::T. As such there is no performance difference -> the =
resultant cached template, appears in memory as if the user didn't use =
the TMPL_ELSIF syntax.
> > > - 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)
This was actually relatively easy... once I understood how H::T =
worked... inside out... :-)
> > > - 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.
>=20
> Filters strike me as being one of those things in Perl that look easy, =
but=20
> often end up having subtle edge cases that will someday cause your =
computer=20
> 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.
I have been caught by the 'lets use a filter' solution. I needed the =
equivalent of:
<TMPL_INCLUDE <TMPL_VAR path>/info.tmpl>
ie recursive H::T. This work well, for the first template parse - =
until the file was cached, since the filter is applied before the file =
is cached... :-o
As someone else has mentioned, a filter package may be a good thing. =
Since I am up for coding it, if anyone has any filters that they would =
want to make available.
So far I have two filters:
1. removal of the trailing slash....
2. the filter for <TMPL_VAR NAME=3D"name" VALUE=3D"value">
> > > - TVPL_VAR support for HTML=3DTEXT which allows paragraphs of text =
to be=20
> > formatted to respect newlines
> >
> >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.).
After having another look at the code, I think I could come up with a =
way at supporting ESCAPE=3D"<something>" where 'something' is defined in =
a user created sub-class. Would this be an alternate solution that you =
would consider?
Also, how would you do this with H::T::E? I assume you would register =
a function which formats the blob of text according to your current =
stylesheet?
regards,
Mathew
|
|
From: Mathew R. <mat...@re...> - 2003-12-10 06:56:10
|
> > > - dot syntax, eg 'user.name'
> >
> >Allowing dots in variable names seems harmless enough.
> <snip>
>=20
>=20
> The thing is, 'user.name' isn't a variable name in the traditional=20
> way. Rather, it's saying 'I want the attribute "name" for the =
variable=20
> "user"', thus providing a more OO approach.
>=20
> I imagine that this would be implemented by passing an object that =
provides=20
> accessors for the fields that would show up in the template. For the=20
> example above:
>=20
> package My::UserVar;
> use base 'HTML::Template::Var'; # For example
>=20
> sub new
> {
> my $class =3D shift;
> my $in =3D shift || { };
> return unless ref($in) eq 'HASH';
> my $self =3D { map { $_ =3D> $in->{$_} || '' } qw( name addr city =
state=20
> postal )};
> bless $self, $class;
> }
> sub name { $_->{name} }
> sub addr { $_->{addr} }
> sub city { $_->{city} }
> sub state { $_->{state} }
> sub postal { $_->{postal} }
>=20
>=20
> package main;
>=20
> # $tmpl defined elsewhere, holding an HTML::Template object
> my $user =3D My::UserVar->new({ name =3D> 'foo', addr =3D> 'bar' });
> $tmpl->param( user =3D> $user );
I hadn't considered doing it this way, though the idea of using a OO =
styled notation appeals to me. I was thinking along the lines of:
In a template you may do something like:
<TMPL_IF user>
<TMPL_IF user.name>
<TMPL_VAR user.name.first> <TMPL_VAR user.name.last>
</TMPL_IF>
<TMPL_IF user.address>
<TMPL_VAR user.address.street>
<TMPL_VAR user.address.town>
</TMPL_IF>
</TMPL_IF>
Normally your code would look something like:
if (length $user->name->first or $user->name->last ) {
$tmpl->param ('user' =3D> 1);
$tmpl->param ('user.name' =3D> 1);
$tmpl->param ('user.name.first' =3D> $user->name->first );
$tmpl->param ('user.name.last' =3D> $user->name->last );
}
if (length $user->address->street or $user->address->town) {
$tmpl->param ('user' =3D> 1);
$tmpl->param ('user.address' =3D> 1);
$tmpl->param ('user.address.street' =3D> $user->address->street);
$tmpl->param ('user.address.town' =3D> $user->address->town);
}
With the 'structure_vars' support you can do this:
$tmpl->param( 'user.name.first' =3D $user->name->first );
$tmpl->param( 'user.name.last' =3D $user->name->last );
$tmpl->param( 'user.address.street' =3D $user->address->street );
$tmpl->param( 'user.address.town' =3D $user->address->town );
regards,
Mathew
|
|
From: Timm M. <tm...@ag...> - 2003-12-10 14:50:19
|
At 05:55 PM 12/10/03 +1100, Mathew Robertson wrote:
><>
>In a template you may do something like:
>
><TMPL_IF user>
> <TMPL_IF user.name>
> <TMPL_VAR user.name.first> <TMPL_VAR user.name.last>
> </TMPL_IF>
> <TMPL_IF user.address>
> <TMPL_VAR user.address.street>
> <TMPL_VAR user.address.town>
> </TMPL_IF>
></TMPL_IF>
>
>
>Normally your code would look something like:
>
>if (length $user->name->first or $user->name->last ) {
> $tmpl->param ('user' => 1);
> $tmpl->param ('user.name' => 1);
> $tmpl->param ('user.name.first' => $user->name->first );
> $tmpl->param ('user.name.last' => $user->name->last );
>}
>if (length $user->address->street or $user->address->town) {
> $tmpl->param ('user' => 1);
> $tmpl->param ('user.address' => 1);
> $tmpl->param ('user.address.street' => $user->address->street);
> $tmpl->param ('user.address.town' => $user->address->town);
>}
>
>
>With the 'structure_vars' support you can do this:
>
>$tmpl->param( 'user.name.first' = $user->name->first );
>$tmpl->param( 'user.name.last' = $user->name->last );
>$tmpl->param( 'user.address.street' = $user->address->street );
>$tmpl->param( 'user.address.town' = $user->address->town );
Actually, you'd just do this:
$tmpl->param( user => $user );
And H::T would take care of calling the necessary methods for you.
|
|
From: Joel <htm...@jo...> - 2003-12-10 16:50:13
|
>At 05:55 PM 12/10/03 +1100, Mathew Robertson wrote:
>>
>>In a template you may do something like:
>>
>><TMPL_IF user>
>> <TMPL_IF user.name>
>> <TMPL_VAR user.name.first> <TMPL_VAR user.name.last>
>> </TMPL_IF>
>> <TMPL_IF user.address>
>> <TMPL_VAR user.address.street>
>> <TMPL_VAR user.address.town>
>> </TMPL_IF>
>></TMPL_IF>
>>
>>
>>Normally your code would look something like:
>>
>>if (length $user->name->first or $user->name->last ) {
>> $tmpl->param ('user' => 1);
>> $tmpl->param ('user.name' => 1);
>> $tmpl->param ('user.name.first' => $user->name->first );
>> $tmpl->param ('user.name.last' => $user->name->last );
>>}
>>if (length $user->address->street or $user->address->town) {
>> $tmpl->param ('user' => 1);
>> $tmpl->param ('user.address' => 1);
>> $tmpl->param ('user.address.street' => $user->address->street);
>> $tmpl->param ('user.address.town' => $user->address->town);
>>}
>>
>>
>>With the 'structure_vars' support you can do this:
>>
>>$tmpl->param( 'user.name.first' = $user->name->first );
>>$tmpl->param( 'user.name.last' = $user->name->last );
>>$tmpl->param( 'user.address.street' = $user->address->street );
>>$tmpl->param( 'user.address.town' = $user->address->town );
>
>Actually, you'd just do this:
>
>$tmpl->param( user => $user );
>
>And H::T would take care of calling the necessary methods for you.
This is an easy workaround with a lovely little recursive function to traverse
your hashref structure. (This is a real example, try it for yourself. Although
I admit that one line of it is questionable, but it needs to know if a
reference is a scalar or a hash, otherwise errors abound.)
test.pl -- The code
-------------------
#!/usr/bin/perl -w
use strict;
use HTML::Template;
my $user = {name => {first => 'John',
last => 'Doe'},
address => {street => '123 Main St',
city => 'Washington',
state => 'DC'}};
my $tmpl = HTML::Template->new(filename => 'test.txt', die_on_bad_params => 0);
$tmpl->param(user => 1);
&populate($tmpl, $user, 'user');
print $tmpl->output();
1;
sub populate {
my $tmpl = shift;
my $struct = shift;
my $curr = shift;
foreach (keys %$struct) {
$tmpl->param("$curr.$_" => 1);
if ($struct->{$_} =~ 'HASH') {
&populate($tmpl, $struct->{$_}, "$curr.$_");
} else {
$tmpl->param("$curr.$_" => $struct->{$_});
}
}
}
test.txt -- The Template
------------------------
<TMPL_IF user>
<TMPL_IF user.name>
FName: <TMPL_VAR user.name.first>
Lname: <TMPL_VAR user.name.last>
</TMPL_IF>
<TMPL_IF user.address>
Street: <TMPL_VAR user.address.street>
City: <TMPL_VAR user.address.city>
State: <TMPL_VAR user.address.state>
</TMPL_IF>
</TMPL_IF>
And if I remember correctly, Perl would allow you to "add" your own function to
do this in HTML::Template at runtime. Example:
sub HTML::Template::foo {
return "foobar\n";
}
my $template = HTML::Template->new(filename => 'blah');
print $template->foo;
So technically, you could add a new function HTML::Template::structure_param
that would do all the ugliness when called with: (assuming $user is a hashref)
$tmpl->structure_param(user => $user);
I love Perl.
--Joel
|
|
From: Puneet K. <pk...@ei...> - 2003-12-09 22:38:59
|
Karen J. Cravens wrote: > On Tue, 9 Dec 2003, Puneet Kishor wrote: > > PK>well, now that you put it that way, I feel I might be the one who is not > PK>really understanding what you all are saying, and hence, am perhaps > PK>barking tangentially ;-). > > I think it's just a matter of different approaches. > > The way I've been doing it, as I described earlier, the content was in a > template. It relied on includes to pull the HTML in, wow! cool... instead of putting the dog in the kennel, you are putting the kennel around the dog. That said, H::T (I believe) sets out to solve the problem of putting the dog in the kennel. The criticism is not at all of other approaches... who am I to do that. The question is whether H::T should be changed to accommodate putting the kennel around the dog. I believe that would deviate from its goal, and perhaps complicate it and weigh it down. imho. Anyway, thanks for a great discussion. ;-) |
|
From: Karen J. C. <si...@ph...> - 2003-12-09 23:26:58
|
On Tue, 9 Dec 2003, Puneet Kishor wrote: PK>That said, H::T (I believe) sets out to solve the problem of putting the PK> dog in the kennel. The criticism is not at all of other approaches... PK>who am I to do that. The question is whether H::T should be changed to PK>accommodate putting the kennel around the dog. I believe that would PK>deviate from its goal, and perhaps complicate it and weigh it down. imho. Yes and no. I think which is the dog and which is the kennel is defined by which one needs to have (more) TMPL_VARs embedded in it. Which in turn depends on what one is using the TMPL_VARs for. I mostly started out with TMPL_VARs in the content for stuff that later got moved to the CSS. I was using H::T to apply skins rather than to strictly separate code from HTML (since I'm the author in both cases), but it's evolved into something fairly different. Hence the refactoring. -- Karen J. Cravens si...@ph... |
|
From: Cees H. <ce...@si...> - 2003-12-09 22:51:35
|
Karen J. Cravens wrote:
> content you're stuffing. Unless, as I'll probably end up doing, you're
> processing the content as a nested template, a la:
> $page->param("content", $subpage->output)).
If you end up having to create 2 or more HTML::Template objects to
generate one response page, then you end up loosing a lot of the big
speed benefit that HTML::Template gives over the rest of the
competition, and it can makes your code significantly more complex.
Please note that I have no benchmarks to prove this, it is just a gut
feeling.
Cees
|
|
From: Karen J. C. <si...@ph...> - 2003-12-09 23:26:27
|
On Tue, 9 Dec 2003, Cees Hek wrote: CH>If you end up having to create 2 or more HTML::Template objects to CH>generate one response page, then you end up loosing a lot of the big CH>speed benefit that HTML::Template gives over the rest of the CH>competition, and it can makes your code significantly more complex. No doubt. But since those cases aren't generating things on the fly, I'm not too worried about the one-time performance hit. -- Karen J. Cravens si...@ph... |
|
From: Mathew R. <mat...@re...> - 2003-12-08 23:16:26
Attachments:
HTML_Template-2.7.tar.gz
|
> speaking of which, I have often wondered what could be improved in = H-T,=20 > and have failed to come up with anything. It just seems to be that=20 > perfect program that does perfectly what it said to do. Simple to=20 > install and understand, well-documented, and fast. In fact, imho, it=20 > should be made a core part of Perl as is CGI.pm. >=20 > But, since not being able to visualize the form of H-T's future might = be=20 > due to my lack of imagination, I am curious -- what are the ways in=20 > which the developer-kind want to see H-T to be in a few years/versions = > or so... Attached is my local copy of H::T which includes some changes which may = or may not be of use. The changes include: - TMPL_ELSIF tag, eg <TMPL_ELSIF somevar> - support for custom tags, eg <TMPL_CATGETS ...> - trailing slash in tags, aka <TMPL... /> - TVPL_VAR support for HTML=3DTEXT which allows paragraphs of text to be = formatted to respect newlines - dot syntax, eg 'user.name' - dot syntax with autovivification of leading template variable, eg = 'user.name' results in autovivification of 'user' I have included documentation to support the enhancements. Also, I have bumped the revision number to 2.7 so as to indicate a = non-standard release. Feel free to suggest / flame me. Mathew |
|
From: Puneet K. <pk...@ei...> - 2003-12-08 23:07:37
|
Sam Tregar wrote: > On Mon, 8 Dec 2003, Puneet Kishor wrote: > > >>speaking of which, I have often wondered what could be improved in H-T, >>and have failed to come up with anything. It just seems to be that >>perfect program that does perfectly what it said to do. Simple to >>install and understand, well-documented, and fast. In fact, imho, it >>should be made a core part of Perl as is CGI.pm. > > .. > I've considered doing an HTML::Template version 3 a few times, but > never found the time to do it. I even went so far as to draft a > design document. Here it is! (Note, I have no plans to actually do > this work anytime soon.) thank heavens! (just rename the darn thing version 3.142 since some folks don't like upgrading to whole numbers -- pi in their face). Seriously, both those who create with H-T and those who are current/potential users of H-T-driven applications would benefit the most if H-T were a part of core Perl. None of asking users to install H-T or including it in applications. H-T is so much more useful that CGI.pm (in my opinion), and if anything, CGI.pm is made worthwhile because of H-T. Just making it a part of core Perl would be a serious benefit for the use of Perl for web-apps. Where do I cast my vote? Where do I lobby? |
|
From: Karen J. C. <si...@ph...> - 2003-12-08 23:17:27
|
On Mon, 8 Dec 2003, Puneet Kishor wrote: PK>Just making it a part of core Perl would be a serious benefit for the PK>use of Perl for web-apps. Where do I cast my vote? Where do I lobby? I think first it needs a name change. It should have "Simple" or "Lite" in it somewhere, and "HTML" in it nowhere. Aside from the appearance of the TMPL_ tags, it's not especially HTML-centric, and certainly some of us use it for generic templating. Course, that'd add work for us existing users, so I'm not going to lobby too hard for that change... -- Karen J. Cravens si...@ph... |
|
From: Roger B. W. <ro...@fi...> - 2003-12-08 23:27:41
|
On Mon, Dec 08, 2003 at 05:21:26PM -0600, Karen J. Cravens wrote: >On Mon, 8 Dec 2003, Sam Tregar wrote: >ST>Make global_vars=1 the default mode and build it in right from the >ST>start. It's what everyone expects when they first use the module and >ST>I think it was a mistake to have it default off. In fact, I lean >ST>towards removing the option entirely. >I could go for this. I have not yet used global_vars=1 in 3+ years of using H::T. I am after all a coder, and I _expect_ local variables... I'd certainly like to keep local variables as an option, at least, though most of my templates don't care. >I also almost always have die-on-invalid shut off, because I tend to want >my code to shove as many parameters as possible out for use, but my >templates don't always use them. I may be in the minority there, though. If so, I am too. Highly useful. I sometimes think about a "production mode" H::T module that would strip out all the syntax checking stuff and simply assume that the templates are valid (thereby running even faster). Roger |
|
From: Karen J. C. <si...@ph...> - 2003-12-09 00:02:41
|
On Mon, 8 Dec 2003, Roger Burton West wrote: RBW>I have not yet used global_vars=1 in 3+ years of using H::T. I am after RBW>all a coder, and I _expect_ local variables... I'd certainly like to RBW>keep local variables as an option, at least, though most of my templates RBW>don't care. This may just depend on the sort of things we each typically code for... I end up with quite a lot of nested tables, with repeated information from higher levels inside. I could get by without the globals, but it'd mean building bulkier loop-parameter arrays. Some of that's probably due to my penchant for constructing URLs inside the templates rather than in the code, of course. -- Karen J. Cravens si...@ph... |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X