Thread: [htmltmpl] Re: HTML::Template bug report: Problems using cache
Brought to you by:
samtregar
From: Sam T. <sa...@tr...> - 2005-11-30 00:01:17
|
On Tue, 29 Nov 2005, Jozef Kosoru wrote: > Since there wasn't any new release for more than one year I would also like > to ask you whether this package is still maintanted. It's still maintained, although I'm too busy to spend a lot of time on it right now. Maybe next year... > Regarding this bug. Could you help me somehow, please? I've tried to fix > it myself, but the code is a bit too complex. Thank you. Hmmm, alright, let's see. > my $rTmpl1 = HTML::Template->new(filename => $htmlTemplate, cache => 1); > my $rTmpl2 = HTML::Template->new(filename => $htmlTemplate, cache => 1); Ok, that won't work. The cache is going to hand you back two references to the same object. Try this instead: use Storable qw(dclone); my $rTmpl1 = HTML::Template->new(filename => $htmlTemplate, cache => 1); my $rTmpl2 = dclone($rTmpl2); Or, possibly faster: use Clone qw(clone); my $rTmpl1 = HTML::Template->new(filename => $htmlTemplate, cache => 1); my $rTmpl2 = clone($rTmpl2); -sam |
From: Mathew R. <mat...@ne...> - 2005-12-01 21:55:11
|
>>>Since there wasn't any new release for more than one year I would also like >>>to ask you whether this package is still maintanted. >>> >>> >>It's still maintained, although I'm too busy to spend a lot of time on >>it right now. Maybe next year... >> >> > >But it would still be nice if there would be a new release. With some >bugfixes for example. It does not need to have all new features. And >it would show that this module is still maintained. > That is a bit harsh... And if Sam was to put out a release with bugfixes, what would it contain? You have the source code to H::T, you could always do produce a release yourself - Sam may even take the to code to make it official... Also, there are a few of us here that maintain modified versions of H::T, each of which enhance H::T in some way - you could always choose to use those instead. Mathew |
From: Mitar <mm...@gm...> - 2005-12-03 01:27:25
|
Hi! On 12/1/05, Mathew Robertson <mat...@ne...> wrote: > That is a bit harsh... And if Sam was to put out a release with bugfixes, > what would it contain? I hope it was not. At least it was not meant to be. And I was thinking about those bugs: http://rt.cpan.org/NoAuth/Bugs.html?Dist=3DHTML-Template I think that making an official bugfix release would be nice. And that it would also show that the module is still alive (as we all know it is). And Sam asked me to keep nagging him about that. But it is normal and understandable if he does not have the time or anything for that. Mitar |
From: Jozef K. <zy...@ui...> - 2005-11-30 21:25:40
|
Hello, thanks for the answer. On Tue, Nov 29, 2005 at 19:01:12 -0500, Sam Tregar wrote: > > my $rTmpl1 = HTML::Template->new(filename => $htmlTemplate, cache => 1); > > my $rTmpl2 = HTML::Template->new(filename => $htmlTemplate, cache => 1); > > Ok, that won't work. The cache is going to hand you back two > references to the same object. Try this instead: > > use Storable qw(dclone); > my $rTmpl1 = HTML::Template->new(filename => $htmlTemplate, cache => 1); > my $rTmpl2 = dclone($rTmpl2); > > Or, possibly faster: > > use Clone qw(clone); > my $rTmpl1 = HTML::Template->new(filename => $htmlTemplate, cache => 1); > my $rTmpl2 = clone($rTmpl2); Yes, great! That works. But this was simple and rather contrived example. In practice it's impossible (or at least impractical) to make as many clones of the same template object as needed before thay are used. I would therefore like to introduce a new cache option "cloned_cache" which will use cached data only as a template for making clones. I'll try to implement it myself but as I've looked to sources - it won't be that easy :) But I think this strategy must already be used for the "shared_cache", isn't it? Because in that case many processes may use the cached data in the same time. Regards, Jozef -- jozef kosoru http://zyzstar.kosoru.com |
From: Mitar <mm...@gm...> - 2005-12-01 09:22:17
|
Hi! On 11/30/05, Sam Tregar <sa...@tr...> wrote: > On Tue, 29 Nov 2005, Jozef Kosoru wrote: > > Since there wasn't any new release for more than one year I would also = like > > to ask you whether this package is still maintanted. > > It's still maintained, although I'm too busy to spend a lot of time on > it right now. Maybe next year... But it would still be nice if there would be a new release. With some bugfixes for example. It does not need to have all new features. And it would show that this module is still maintained. Mitar |
From: Boon C. <was...@ya...> - 2005-12-01 19:41:38
|
I can't find a way in the doc to loop through hash without knowing the keys in the hash. If this feature is not available, I think the fact that the template has to always such intimiate knowledge of what's being passed to it is not always a good thing, it also makes it impossible to just dump out all the data on the HTML end with a simple statement. e.g. <tmpl_loop students> <tmpl_var name> </tmpl_loop> --------------------------------- Yahoo! Music Unlimited - Access over 1 million songs. Try it free. |
From: Carl F. <fir...@gm...> - 2005-12-01 20:03:10
|
> e.g. > <tmpl_loop students> > <tmpl_var name> > </tmpl_loop> a TMPL_LOOP doesn't take a hash, it takes an array-ref of hash-refs that would be my @loop =3D ( {name =3D> 'a'}, {name =3D> 'b'}, ); $tmpl->param( students =3D> \@loop ); If you knew that already, give an example of what sort of data you want to put in, and what you want the HTML to look like. Cheers, Carl |
From: Boon C. <was...@ya...> - 2005-12-01 20:16:03
|
Ya sorry, that's what I meant. Right now I am working on some site code, and the designer sometimes have to come to me for stuff because he doesn't always know what hash keys I am passing to him (say sometimes I might add a new one, sometimes he mistype one, etc.). The whole point of doing this template separation is to decouple things, but if the designer can only figure out what's being passed into the template by looking at the module code, it kinda defeats the whole purpose. It would be such great convenience to be able to dump the whole thing on the HTML with a call like this: <tmpl_var story_loop> or <tmpl_loop story_loop> <column_var> <-- outputs all keys here </tmpl_loop> Carl Franks <fir...@gm...> wrote: > e.g. > > > a TMPL_LOOP doesn't take a hash, it takes an array-ref of hash-refs that would be my @loop = ( {name => 'a'}, {name => 'b'}, ); $tmpl->param( students => \@loop ); If you knew that already, give an example of what sort of data you want to put in, and what you want the HTML to look like. Cheers, Carl ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Html-template-users mailing list Htm...@li... https://lists.sourceforge.net/lists/listinfo/html-template-users --------------------------------- Yahoo! Personals Single? There's someone we'd like you to meet. Lots of someones, actually. Yahoo! Personals |
From: Mathew R. <mat...@ne...> - 2005-12-01 21:59:16
|
It sounds like you need a tool which simply dumps the template variable=20 names (ie: using the $ht->params() function), rather than some special=20 mode to H::T Mathew Boon Chew wrote: > Ya sorry, that's what I meant. > > Right now I am working on some site code, and the designer sometimes=20 > have to come to me for stuff because he doesn't always know what hash=20 > keys I am passing to him (say sometimes I might add a new one,=20 > sometimes he mistype one, etc.). The whole point of doing this=20 > template separation is to decouple things, but if the designer can=20 > only figure out what's being passed into the template by looking at=20 > the module code, it kinda defeats the whole purpose. > > It would be such great convenience to be able to dump the whole thing=20 > on the HTML with a call like this: > > <tmpl_var story_loop> > > or > > <tmpl_loop story_loop> > <column_var> <-- outputs all keys here > </tmpl_loop> > > */Carl Franks <fir...@gm...>/* wrote: > > > e.g. > > > > > > > > a TMPL_LOOP doesn't take a hash, it takes an array-ref of hash-refs= > that would be > > my @loop =3D ( > {name =3D> 'a'}, > {name =3D> 'b'}, > ); > > $tmpl->param( students =3D> \@loop ); > > If you knew that already, give an example of what sort of data you > want to put in, and what you want the HTML to look like. > > Cheers, > Carl > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through > log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUN= K! > http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick > _______________________________________________ > Html-template-users mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/html-template-users > > > -----------------------------------------------------------------------= - > *Yahoo! Personals* > Single? There's someone we'd like you to meet. > Lots of someones, actually. Yahoo! Personals=20 > <http://us.rd.yahoo.com/evt=3D36108/*http://personals.yahoo.com%20>=20 |
From: Boon C. <was...@ya...> - 2005-12-01 22:10:38
|
I want a way to quickly display all the info in a var - a Dumper output if you will. But more than that, like in some other server-side language, you can query the column lists (or hash keys) and loop through those and use a piece of generic code when all you intend to do is to display everything in the var. Imagine yourself wanting to output all the info in a reference to an array of hashes (which essentially mimics a database table), the HTML code can really be made the same if a construct is available to loop through things. The tight coupling of knowledge between what's being sent from the perl code and the HTML can be avoided, that's the whole point of the design of the template module (vs Mason where you mingle Perl code with display code) right? It just seems ugly when I have to tell a designer to go look at the perl file to see what he is getting in the var. He should be able to find that out from some sensible constructs. - boon Mathew Robertson <mat...@ne...> wrote: It sounds like you need a tool which simply dumps the template variable names (ie: using the $ht->params() function), rather than some special mode to H::T Mathew Boon Chew wrote: Ya sorry, that's what I meant. Right now I am working on some site code, and the designer sometimes have to come to me for stuff because he doesn't always know what hash keys I am passing to him (say sometimes I might add a new one, sometimes he mistype one, etc.). The whole point of doing this template separation is to decouple things, but if the designer can only figure out what's being passed into the template by looking at the module code, it kinda defeats the whole purpose. It would be such great convenience to be able to dump the whole thing on the HTML with a call like this: <tmpl_var story_loop> or <tmpl_loop story_loop> <column_var> <-- outputs all keys here </tmpl_loop> Carl Franks <fir...@gm...> wrote: > e.g. > > > a TMPL_LOOP doesn't take a hash, it takes an array-ref of hash-refs that would be my @loop = ( {name => 'a'}, {name => 'b'}, ); $tmpl->param( students => \@loop ); If you knew that already, give an example of what sort of data you want to put in, and what you want the HTML to look like. Cheers, Carl ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Html-template-users mailing list Htm...@li... https://lists.sourceforge.net/lists/listinfo/html-template-users --------------------------------- Yahoo! Personals Single? There's someone we'd like you to meet. Lots of someones, actually. Yahoo! Personals --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less |
From: Mathew R. <mat...@ne...> - 2005-12-01 22:44:07
|
The coupling of a template to the template-params is something that cant = really be avoided - at some point the template designer has to have some = understanding of what template-variables are being generated. Since you = are the developer creating the code that generates the=20 template-variables, it is your responsibility to "publish" the variable=20 names and their meaning, it is not up to the template designer to=20 "figure out" what they are and what they represent. That said, there is a justified argument for wanting something like a=20 <TMPL_DUMP some_var> which writes a dumped-block into the target page. Mathew PS. I maintain a version of H::T which supports sub-classing so that you = can create your own TMPL tags, see: http://members.optusnet.com.au/~mathe= w Boon Chew wrote: > I want a way to quickly display all the info in a var - a Dumper=20 > output if you will. But more than that, like in some other=20 > server-side language, you can query the column lists (or hash keys)=20 > and loop through those and use a piece of generic code when all you=20 > intend to do is to display everything in the var. > > Imagine yourself wanting to output all the info in a reference to an=20 > array of hashes (which essentially mimics a database table), the HTML=20 > code can really be made the same if a construct is available to loop=20 > through things. > > The tight coupling of knowledge between what's being sent from the=20 > perl code and the HTML can be avoided, that's the whole point of the=20 > design of the template module (vs Mason where you mingle Perl code=20 > with display code) right? It just seems ugly when I have to tell a=20 > designer to go look at the perl file to see what he is getting in the=20 > var. He should be able to find that out from some sensible constructs.= > > - boon > > */Mathew Robertson <mat...@ne...>/* wrote: > > It sounds like you need a tool which simply dumps the template > variable names (ie: using the $ht->params() function), rather than > some special mode to H::T > > Mathew > > Boon Chew wrote: > >> Ya sorry, that's what I meant. >> >> Right now I am working on some site code, and the designer >> sometimes have to come to me for stuff because he doesn't always >> know what hash keys I am passing to him (say sometimes I might >> add a new one, sometimes he mistype one, etc.). The whole point >> of doing this template separation is to decouple things, but if >> the designer can only figure out what's being passed into the >> template by looking at the module code, it kinda defeats the >> whole purpose. >> >> It would be such great convenience to be able to dump the whole >> thing on the HTML with a call like this: >> >> <tmpl_var story_loop> >> >> or >> >> <tmpl_loop story_loop> >> <column_var> <-- outputs all keys here >> </tmpl_loop> >> >> */Carl Franks <fir...@gm...>/* wrote: >> >> > e.g. >> > >> > >> > >> >> a TMPL_LOOP doesn't take a hash, it takes an array-ref of >> hash-refs >> that would be >> >> my @loop =3D ( >> {name =3D> 'a'}, >> {name =3D> 'b'}, >> ); >> >> $tmpl->param( students =3D> \@loop ); >> >> If you knew that already, give an example of what sort of >> data you >> want to put in, and what you want the HTML to look like. >> >> Cheers, >> Carl >> >> >> ------------------------------------------------------- >> This SF.net email is sponsored by: Splunk Inc. Do you grep >> through log files >> for problems? Stop! Download the new AJAX search engine that >> makes >> searching your log files as easy as surfing the web. DOWNLOAD >> SPLUNK! >> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick >> _______________________________________________ >> Html-template-users mailing list >> Htm...@li... >> https://lists.sourceforge.net/lists/listinfo/html-template-use= rs >> >> >> ------------------------------------------------------------------= ------ >> *Yahoo! Personals* >> Single? There's someone we'd like you to meet. >> Lots of someones, actually. Yahoo! Personals >> <http://us.rd.yahoo.com/evt=3D36108/*http://personals.yahoo.com%20= >=20 > > > -----------------------------------------------------------------------= - > Yahoo! DSL=20 > <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=3D37474/*http://promo.= yahoo.com/broadband/%20>=20 > Something to write home about. Just $16.99/mo. or less=20 |
From: Boon C. <was...@ya...> - 2005-12-01 23:04:59
|
I agree with you that the coupling cannot be totally avoided, but being able to deal with template var generically in the presentation layer is very useful in avoiding having to create duplicate html code that are doing exactly the same thing. - boon Mathew Robertson <mat...@ne...> wrote: The coupling of a template to the template-params is something that cant really be avoided - at some point the template designer has to have some understanding of what template-variables are being generated. Since you are the developer creating the code that generates the template-variables, it is your responsibility to "publish" the variable names and their meaning, it is not up to the template designer to "figure out" what they are and what they represent. That said, there is a justified argument for wanting something like a <TMPL_DUMP some_var> which writes a dumped-block into the target page. Mathew PS. I maintain a version of H::T which supports sub-classing so that you can create your own TMPL tags, see: http://members.optusnet.com.au/~mathew Boon Chew wrote: I want a way to quickly display all the info in a var - a Dumper output if you will. But more than that, like in some other server-side language, you can query the column lists (or hash keys) and loop through those and use a piece of generic code when all you intend to do is to display everything in the var. Imagine yourself wanting to output all the info in a reference to an array of hashes (which essentially mimics a database table), the HTML code can really be made the same if a construct is available to loop through things. The tight coupling of knowledge between what's being sent from the perl code and the HTML can be avoided, that's the whole point of the design of the template module (vs Mason where you mingle Perl code with display code) right? It just seems ugly when I have to tell a designer to go look at the perl file to see what he is getting in the var. He should be able to find that out from some sensible constructs. - boon Mathew Robertson <mat...@ne...> wrote: It sounds like you need a tool which simply dumps the template variable names (ie: using the $ht->params() function), rather than some special mode to H::T Mathew Boon Chew wrote: Ya sorry, that's what I meant. Right now I am working on some site code, and the designer sometimes have to come to me for stuff because he doesn't always know what hash keys I am passing to him (say sometimes I might add a new one, sometimes he mistype one, etc.). The whole point of doing this template separation is to decouple things, but if the designer can only figure out what's being passed into the template by looking at the module code, it kinda defeats the whole purpose. It would be such great convenience to be able to dump the whole thing on the HTML with a call like this: <tmpl_var story_loop> or <tmpl_loop story_loop> <column_var> <-- outputs all keys here </tmpl_loop> Carl Franks <fir...@gm...> wrote: > e.g. > > > a TMPL_LOOP doesn't take a hash, it takes an array-ref of hash-refs that would be my @loop = ( {name => 'a'}, {name => 'b'}, ); $tmpl->param( students => \@loop ); If you knew that already, give an example of what sort of data you want to put in, and what you want the HTML to look like. Cheers, Carl ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Html-template-users mailing list Htm...@li... https://lists.sourceforge.net/lists/listinfo/html-template-users --------------------------------- Yahoo! Personals Single? There's someone we'd like you to meet. Lots of someones, actually. Yahoo! Personals --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less |
From: Mathew R. <mat...@ne...> - 2005-12-02 00:06:05
|
I agree too - what I was trying to say was that, I dont think it is even = technically possible to do it generically. Can you think of an example of how to do it generically? If you can, I=20 could quite easily modify my H::T version to support this functionality. Mat Boon Chew wrote: > > I agree with you that the coupling cannot be totally avoided, but=20 > being able to deal with template var generically in the presentation=20 > layer is very useful in avoiding having to create duplicate html code=20 > that are doing exactly the same thing.=20 > > - boon > > */Mathew Robertson <mat...@ne...>/* wrote: > > The coupling of a template to the template-params is something > that cant really be avoided - at some point the template designer > has to have some understanding of what template-variables are > being generated. Since you are the developer creating the code > that generates the template-variables, it is your responsibility > to "publish" the variable names and their meaning, it is not up to > the template designer to "figure out" what they are and what they > represent. > > That said, there is a justified argument for wanting something > like a <TMPL_DUMP some_var> which writes a dumped-block into the > target page. > > Mathew > > PS. I maintain a version of H::T which supports sub-classing so > that you can create your own TMPL tags, see: > http://members.optusnet.com.au/~mathew > > > Boon Chew wrote: > >> I want a way to quickly display all the info in a var - a Dumper >> output if you will. But more than that, like in some other >> server-side language, you can query the column lists (or hash >> keys) and loop through those and use a piece of generic code when >> all you intend to do is to display everything in the var. >> >> Imagine yourself wanting to output all the info in a reference to >> an array of hashes (which essentially mimics a database table), >> the HTML code can really be made the same if a construct is >> available to loop through things. >> >> The tight coupling of knowledge between what's being sent from >> the perl code and the HTML can be avoided, that's the whole point >> of the design of the template module (vs Mason where you mingle >> Perl code with display code) right? It just seems ugly when I >> have to tell a designer to go look at the perl file to see what >> he is getting in the var. He should be able to find that out >> from some sensible constructs. >> >> - boon >> >> */Mathew Robertson <mat...@ne...>/* wrote: >> >> It sounds like you need a tool which simply dumps the >> template variable names (ie: using the $ht->params() >> function), rather than some special mode to H::T >> >> Mathew >> >> Boon Chew wrote: >> >>> Ya sorry, that's what I meant. >>> >>> Right now I am working on some site code, and the designer >>> sometimes have to come to me for stuff because he doesn't >>> always know what hash keys I am passing to him (say >>> sometimes I might add a new one, sometimes he mistype one, >>> etc.). The whole point of doing this template separation is >>> to decouple things, but if the designer can only figure out >>> what's being passed into the template by looking at the >>> module code, it kinda defeats the whole purpose. >>> >>> It would be such great convenience to be able to dump the >>> whole thing on the HTML with a call like this: >>> >>> <tmpl_var story_loop> >>> >>> or >>> >>> <tmpl_loop story_loop> >>> <column_var> <-- outputs all keys here >>> </tmpl_loop> >>> >>> */Carl Franks <fir...@gm...>/* wrote: >>> >>> > e.g. >>> > >>> > >>> > >>> >>> a TMPL_LOOP doesn't take a hash, it takes an array-ref >>> of hash-refs >>> that would be >>> >>> my @loop =3D ( >>> {name =3D> 'a'}, >>> {name =3D> 'b'}, >>> ); >>> >>> $tmpl->param( students =3D> \@loop ); >>> >>> If you knew that already, give an example of what sort >>> of data you >>> want to put in, and what you want the HTML to look like. >>> >>> Cheers, >>> Carl >>> >>> >>> ------------------------------------------------------- >>> This SF.net email is sponsored by: Splunk Inc. Do you >>> grep through log files >>> for problems? Stop! Download the new AJAX search engine >>> that makes >>> searching your log files as easy as surfing the web. >>> DOWNLOAD SPLUNK! >>> http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick >>> _______________________________________________ >>> Html-template-users mailing list >>> Htm...@li... >>> https://lists.sourceforge.net/lists/listinfo/html-templat= e-users >>> >>> >>> -------------------------------------------------------------= ----------- >>> *Yahoo! Personals* >>> Single? There's someone we'd like you to meet. >>> Lots of someones, actually. Yahoo! Personals >>> <http://us.rd.yahoo.com/evt=3D36108/*http://personals.yahoo.c= om%20> >> >> >> >> ------------------------------------------------------------------= ------ >> Yahoo! DSL >> <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=3D37474/*http://p= romo.yahoo.com/broadband/%20> >> Something to write home about. Just $16.99/mo. or less=20 > > > -----------------------------------------------------------------------= - > Yahoo! DSL=20 > <http://pa.yahoo.com/*http://us.rd.yahoo.com/evt=3D37474/*http://promo.= yahoo.com/broadband/%20>=20 > Something to write home about. Just $16.99/mo. or less=20 |
From: Boon C. <was...@ya...> - 2005-12-02 00:26:41
|
It might be difficult to do for multilevel nested data structure, but I think having support for one of the most common data structure, array of hash, is a good start, because array of hash mirrors the structure of a resultset coming back from a DB query. Currently we can use tmpl_loop to loop through the array elements (or thinking in terms of DB, the rows), so that's taken care of. What's missing is a way to get the hash keys, so maybe there can be a contextual var that gives you the hash keys (from the DB perspective, the columns or fields), as in __ColumnList__ or something that you can loop through with. Sorry I am just thinking out loud here, as I don't know enough about HTML::Template internals enough to know that's possible or makes sense. - boon Mathew Robertson <mat...@ne...> wrote: I agree too - what I was trying to say was that, I dont think it is even technically possible to do it generically. Can you think of an example of how to do it generically? If you can, I could quite easily modify my H::T version to support this functionality. Mat Boon Chew wrote: I agree with you that the coupling cannot be totally avoided, but being able to deal with template var generically in the presentation layer is very useful in avoiding having to create duplicate html code that are doing exactly the same thing. - boon Mathew Robertson <mat...@ne...> wrote: The coupling of a template to the template-params is something that cant really be avoided - at some point the template designer has to have some understanding of what template-variables are being generated. Since you are the developer creating the code that generates the template-variables, it is your responsibility to "publish" the variable names and their meaning, it is not up to the template designer to "figure out" what they are and what they represent. That said, there is a justified argument for wanting something like a <TMPL_DUMP some_var> which writes a dumped-block into the target page. Mathew PS. I maintain a version of H::T which supports sub-classing so that you can create your own TMPL tags, see: http://members.optusnet.com.au/~mathew Boon Chew wrote: I want a way to quickly display all the info in a var - a Dumper output if you will. But more than that, like in some other server-side language, you can query the column lists (or hash keys) and loop through those and use a piece of generic code when all you intend to do is to display everything in the var. Imagine yourself wanting to output all the info in a reference to an array of hashes (which essentially mimics a database table), the HTML code can really be made the same if a construct is available to loop through things. The tight coupling of knowledge between what's being sent from the perl code and the HTML can be avoided, that's the whole point of the design of the template module (vs Mason where you mingle Perl code with display code) right? It just seems ugly when I have to tell a designer to go look at the perl file to see what he is getting in the var. He should be able to find that out from some sensible constructs. - boon Mathew Robertson <mat...@ne...> wrote: It sounds like you need a tool which simply dumps the template variable names (ie: using the $ht->params() function), rather than some special mode to H::T Mathew Boon Chew wrote: Ya sorry, that's what I meant. Right now I am working on some site code, and the designer sometimes have to come to me for stuff because he doesn't always know what hash keys I am passing to him (say sometimes I might add a new one, sometimes he mistype one, etc.). The whole point of doing this template separation is to decouple things, but if the designer can only figure out what's being passed into the template by looking at the module code, it kinda defeats the whole purpose. It would be such great convenience to be able to dump the whole thing on the HTML with a call like this: <tmpl_var story_loop> or <tmpl_loop story_loop> <column_var> <-- outputs all keys here </tmpl_loop> Carl Franks <fir...@gm...> wrote: > e.g. > > > a TMPL_LOOP doesn't take a hash, it takes an array-ref of hash-refs that would be my @loop = ( {name => 'a'}, {name => 'b'}, ); $tmpl->param( students => \@loop ); If you knew that already, give an example of what sort of data you want to put in, and what you want the HTML to look like. Cheers, Carl ------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://ads.osdn.com/?ad_idv37&alloc_id865&op=click _______________________________________________ Html-template-users mailing list Htm...@li... https://lists.sourceforge.net/lists/listinfo/html-template-users --------------------------------- Yahoo! Personals Single? There's someone we'd like you to meet. Lots of someones, actually. Yahoo! Personals --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less --------------------------------- Yahoo! DSL Something to write home about. Just $16.99/mo. or less --------------------------------- Yahoo! Personals Let fate take it's course directly to your email. See who's waiting for you Yahoo! Personals |
From: Jonathan L. <dat...@gm...> - 2005-12-02 03:40:17
|
Boon Chew wrote: > It might be difficult to do for multilevel nested data structure, but I > think having support for one of the most common data structure, array of > hash, is a good start, because array of hash mirrors the structure of a > resultset coming back from a DB query. You're reading my mind. First off, multilevel nested data structures are quite doable. I just posted an idea for getting H::T to handle normal lists, lists of lists, lists of lists of lists, etc. As I mentioned, I also have some ideas for handling hashes, at which point you can handle lists of hashes, hashes of lists, hashes of hashes of lists of lists of hashes, or whatever other insane combination you might choose. Admittedly, I see few uses for anything beyond ordinary lists, lists of lists, and lists of hashes; but that's (literally) another topic. But lists of hashes do hold a special status, due to their similarity to database tables: I wouldn't be averse to an extension to H::T that lets you use SQL SELECT queries as substitutes for loop control variables, letting the template writer merge tables, sort their contents to his liking, filter out unwanted records, or create new, calculated fields from existing ones. There is value to the notion of viewing lists of hashes as tables. > Currently we can use tmpl_loop to loop through the array elements (or > thinking in terms of DB, the rows), so that's taken care of. What's miss= ing > is a way to get the hash keys, so maybe there can be a contextual var tha= t > gives you the hash keys (from the DB perspective, the columns or fields),= as > in __ColumnList__ or something that you can loop through with. Sorry I a= m > just thinking out loud here, as I don't know enough about HTML::Template > internals enough to know that's possible or makes sense. This capability seems a bit excessive to me; the template designer should rarely (if ever) have to write a template that needs to find out for itself about the structure of the data that's being provided to it. When dealing with DB applications, it's rare that the application needs to look up the column names; usually, it is told by the programmer what column names to expect and works with that. And with H::T, if the template in question really needs to know the names of the keys of a particular hash, the script writer can explicitly load them into the template. Part of the H::T design philosophy is that the template does little more than to look up pre-processed data and to decide how to dress it up; even the SQL SELECT suggestion that I made above puts more work into the hands of the template writer than the basic design philosophy would recommend (heck, doing simple comparison tests such as "name > 5" is verboten in the standard form of the application). -- Jonathan "Dataweaver" Lang |
From: Jonathan L. <dat...@gm...> - 2005-12-01 23:24:57
|
> PS. I maintain a version of H::T which supports sub-classing so that you > can create your own TMPL tags, see: > http://members.optusnet.com.au/~mathew Nice, except that I can't extract it from the computer that I'm at (grumble, WinXP, grumble, public library computer, grumble). Could someone provide Mathew's version, uncompressed, so that I can look it over? -- Jonathan "Dataweaver" Lang |
From: Mathew R. <mat...@ne...> - 2005-12-02 08:20:51
|
Replied unzipped-content, off-list Jonathan Lang wrote: >> PS. I maintain a version of H::T which supports sub-classing so that y= ou >>can create your own TMPL tags, see: >>http://members.optusnet.com.au/~mathew >> =20 >> > >Nice, except that I can't extract it from the computer that I'm at >(grumble, WinXP, grumble, public library computer, grumble). Could >someone provide Mathew's version, uncompressed, so that I can look it >over? > >-- >Jonathan "Dataweaver" Lang > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log f= iles >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_idv37&alloc_id=16865&op=3Dclick >_______________________________________________ >Html-template-users mailing list >Htm...@li... >https://lists.sourceforge.net/lists/listinfo/html-template-users > =20 > |
From: Webmaster Techcode.N. <web...@te...> - 2005-12-02 14:40:17
|
DQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tIA0KRnJvbTogQm9vbiBDaGV3IA0KDQpJIHdh bnQgYSB3YXkgdG8gcXVpY2tseSBkaXNwbGF5IGFsbCB0aGUgaW5mbyBpbiBhIHZhciAtIGEgRHVt cGVyIG91dHB1dCBpZiB5b3Ugd2lsbC4gIEJ1dCBtb3JlIHRoYW4gdGhhdCwgbGlrZSBpbiBzb21l IG90aGVyIHNlcnZlci1zaWRlIGxhbmd1YWdlLCB5b3UgY2FuIHF1ZXJ5IHRoZSBjb2x1bW4gbGlz dHMgKG9yIGhhc2gga2V5cykgYW5kIGxvb3AgdGhyb3VnaCB0aG9zZSBhbmQgdXNlIGEgcGllY2Ug b2YgZ2VuZXJpYyBjb2RlIHdoZW4gYWxsIHlvdSBpbnRlbmQgdG8gZG8gaXMgdG8gZGlzcGxheSBl dmVyeXRoaW5nIGluIHRoZSB2YXIuDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0gDQoN CkkgYWdyZWUgLSBzb21ldGhpbmcgbGlrZSBEYXRhOjpEdW1wZXIgaW4gSFRNTDo6VGVtcGxhdGUg Y29udGV4dCB3b3VsZCBiZSBncmVhdC4NCg0KQW5kIHlvdSBjYW4gYWxzbyAieW91IGNhbiBxdWVy eSB0aGUgY29sdW1uIGxpc3RzIChvciBoYXNoIGtleXMpIGFuZCBsb29wIHRocm91Z2ggdGhvc2Ui IGluIFBlcmwganVzdCBsaWtlIGluIGFueSBvdGhlciBzZXJ2ZXItc2lkZSBsYW5ndWFnZSAuLi4N Cg0KZm9yZWFjaChAYXJyYXkpew0KICAgIHByaW50ICRfLCJcbjxicj4iOw0KfQ0KDQoNCg0KLS0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tLSANClRoZSB0aWdodCBjb3VwbGluZyBvZiBrbm93bGVk Z2UgYmV0d2VlbiB3aGF0J3MgYmVpbmcgc2VudCBmcm9tIHRoZSBwZXJsIGNvZGUgYW5kIHRoZSBI VE1MIGNhbiBiZSBhdm9pZGVkLCB0aGF0J3MgdGhlIHdob2xlIHBvaW50IG9mIHRoZSBkZXNpZ24g b2YgdGhlIHRlbXBsYXRlIG1vZHVsZSAodnMgTWFzb24gd2hlcmUgeW91IG1pbmdsZSBQZXJsIGNv ZGUgd2l0aCBkaXNwbGF5IGNvZGUpIHJpZ2h0PyAgSXQganVzdCBzZWVtcyB1Z2x5IHdoZW4gSSBo YXZlIHRvIHRlbGwgYSBkZXNpZ25lciB0byBnbyBsb29rIGF0IHRoZSBwZXJsIGZpbGUgdG8gc2Vl IHdoYXQgaGUgaXMgZ2V0dGluZyBpbiB0aGUgdmFyLiAgSGUgc2hvdWxkIGJlIGFibGUgdG8gZmlu ZCB0aGF0IG91dCBmcm8gbSBzb21lIHNlbnNpYmxlIGNvbnN0cnVjdHMuDQotLS0tLSBPcmlnaW5h bCBNZXNzYWdlIC0tLS0tIA0KDQpZb3UgbWlzc2VkIHRoZSBwb2ludCAuLi4NCg0KSSBtZWFuIC0g ZGVzaWduZXIgc2hvdWxkbid0IG5lZWQgdG8gdGFrZSBhIGxvb2sgYXQgUGVybCBjb2RlIHRvIGZp Z3VyZSBvdXQgd2hhdCB5b3UgYXJlIG91dHB1dGluZyAuLi4gQW5kICJzb21lIHNlbnNpYmxlIGNv bnN0cnVjdHMiIGFyZSBkb2N1bWVudHMgdGhhdCBmb2xvdyBldmVyeSBwcm9qZWN0LiBIYXZlIHlv dSBldmVyIGhlYXJlZCBvZiB0ZXJtcyBsaWtlIEFQSSBvciBJbnRlcmZhY2U/IFlvdSBhbmQgeW91 IGRlc2lnbmVyIG5lZWQgdG8gYWdyZWUgb24gIkludGVyZmFjZSIgLSBpbiB5b3VyIGNhc2UgdGhl IGRhdGEgaGUgY2FuIHVzZSBpbiB0aGUgdGVtcGxhdGUgLi4uDQoNCkFueXdheSAtIHRoZSBxdWlj ayBhbmQgc2ltcGxlIHNvbHV0aW9uIHRoYXQganVzdCBjcm9zc2VkIG15IG1pbmQgOykNCg0KTWFr ZSBzb21ldGhpbmcgYSBydWxlIC0gZm9yIGVhY2ggdGVtcGxhdGUgLSB5b3UgY291bGQgY3JlYXRl IGEgc3BlY2lhbCB2YXJpYWJsZS4gU2F5IHlvdSBjYW4gbmFtZSBpdCA6ICJ0aGVfZHVtcCIgb3Ig d2hhdGV2ZXIuDQpBbmQgc2ltcGx5IGR1bXAgdmlhIERhdGE6OkR1bXBlciBhbGwgdmFyaWFibGVz IHRoYXQgeW91IChwbGFuKSBwb3B1bGF0ZSB0aGUgdGVtcGxhdGUgd2l0aCAtIG9yIHNlbmQgdG8g dGVtcGxhdGUuDQoNCkFjdHVhbHkgLSB0aGlzIGNvdWxkIGJlIG1hZGUgYXMgcGFydCBvZiBIVE1M LVRlbXBsYXRlIC4uLg0KDQpBbnl3YXkgLSB0aGVuIHlvdXIgZGVzaWduZXIgY291bGQganVzdCBh ZGQgPHRtcGxfdmFyIG5hbWU9InRoZV9kdW1wIj4gYXQgdGhlIGVuZCBvZiB0aGUgdGVtcGxhdGUg aWYgaGUgaXMgbm90IHN1cmUgd2hhdCBkYXRhIGhlIGNhbiBhY2Nlc3MuDQoNCk9mIGNvdXJzZSAt IG5leHQgdGhpbmcgaGUgd2lsbCBjb21wbGFpbiBpcyB3aHkgaW4gdGhlIGhlbGwgaGUgY2FuJ3Qg ZG8gYSBwcmV2aWV3IGluIERyZWFtd2VhdmVyIHdpdGggdGVzdCBkYXRhIGFscmVhZHkgcG9wdWxh dGVkIC4uLg0KDQpDaGVlcnMsDQpBbGV4Lg0K |
From: Boon C. <was...@ya...> - 2005-12-02 22:26:35
|
Well, I guess I should have explained the need of this with a more solid real world use case. Recently I am involved in a project using Krang, a CMS system written in Perl that utilizes HTML::Template. Now here is the thing, we are fairly new to the code base, but in a few days of going through the code and poking around the code, we were able to implement quite a few new features for the client. But our understanding of the system is still immature and incomplete, and there are times the template var is being set somewhere in the inheritance chain, and we know a template can access a specific variable (through incomplete doc and tmpl_if test), but there is no way to know how to access the variable without going through the code tracing out where and what is sent to the template. And what if the documentation misses talking about a var that is sent to the template? No one you can find out unless you poke around the code, but the process can be time consuming as not all the templates are being set in one file (due to OO). I find it surprising that people expect problems can be solved with documentation, or communication with the frontend folks. In the real world, documentation is never as complete as should, I mean, it's hard enough to get some to comment their code! And in the real world, you don't always start a project with code that you have written as well. The need to be able to introspect and access what is sent to the template without having the perl code is a useful and justifiable feature of any server-side scripting framework. - boon --- "Webmaster Techcode.NET" <web...@te...> wrote: > > ----- Original Message ----- > From: Boon Chew > > I want a way to quickly display all the info in a > var - a Dumper output if you will. But more than > that, like in some other server-side language, you > can query the column lists (or hash keys) and loop > through those and use a piece of generic code when > all you intend to do is to display everything in the > var. > > ----- Original Message ----- > > I agree - something like Data::Dumper in > HTML::Template context would be great. > > And you can also "you can query the column lists (or > hash keys) and loop through those" in Perl just like > in any other server-side language ... > > foreach(@array){ > print $_,"\n<br>"; > } > > > > ----- Original Message ----- > The tight coupling of knowledge between what's being > sent from the perl code and the HTML can be avoided, > that's the whole point of the design of the template > module (vs Mason where you mingle Perl code with > display code) right? It just seems ugly when I have > to tell a designer to go look at the perl file to > see what he is getting in the var. He should be > able to find that out fro m some sensible > constructs. > ----- Original Message ----- > > You missed the point ... > > I mean - designer shouldn't need to take a look at > Perl code to figure out what you are outputing ... > And "some sensible constructs" are documents that > folow every project. Have you ever heared of terms > like API or Interface? You and you designer need to > agree on "Interface" - in your case the data he can > use in the template ... > > Anyway - the quick and simple solution that just > crossed my mind ;) > > Make something a rule - for each template - you > could create a special variable. Say you can name it > : "the_dump" or whatever. > And simply dump via Data::Dumper all variables that > you (plan) populate the template with - or send to > template. > > Actualy - this could be made as part of > HTML-Template ... > > Anyway - then your designer could just add <tmpl_var > name="the_dump"> at the end of the template if he is > not sure what data he can access. > > Of course - next thing he will complain is why in > the hell he can't do a preview in Dreamweaver with > test data already populated ... > > Cheers, > Alex. > N¬HYÞµéX¬²'²Þu¼¦[§?ܨº > Þ¦Øk¢è!W¬~é®åzk¶C£ 塧m éÞÀ@^ÇÈ^§zØZ¶f¤zËj·!x2¢êå¢âë±æ¬É«,º·âa{å?,àHòÔ4¨m¶ÿiÛ(±ÙÜ¢oÚv'ïûjYhr'ׯ:ærX?{fצ¦Vzë®ÉX§X¬´{fצ¦Vzë®Éb²Û,¢êÜyú+?éÞ¶m¦Ïÿ+-²Ê.Ç¢¸?ë+-³ùb²Ø§~?á¶imzjej×®±êì __________________________________________ Yahoo! DSL Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com |
From: Carl F. <fir...@gm...> - 2005-12-03 10:42:23
|
SWYgeW91IG1ha2Ugc3VyZQpkaWVfb25fYmFkX3BhcmFtcyA9PiAxCmlzIHNldCBpbiB5b3VyIEhU TUw6OlRlbXBsYXRlIGNvbnN0cnVjdG9yLCB0aGVuIGFueSB2YXJpYWJsZSB3aGljaAppc24ndCBz ZXQgaW4gdGhlIHRlbXBsYXRlLCBvciBpcyBtaXNzcGVsdCB3aWxsIGNhdXNlIHRoZSBwYWdlIHRv IGRpZSAtCnRoZSBkZXNpZ25lciBjYW4gdGhlbiB0ZWxsIHdoYXQncyB3cm9uZyBieSBzaW1wbHkg bG9va2luZyBhdCB0aGUgZXJyb3IKbWVzc2FnZS4KCkNhcmwKCgpPbiAwMi8xMi8wNSwgQm9vbiBD aGV3IDx3YXNwZmlzaEB5YWhvby5jb20+IHdyb3RlOgo+Cj4gV2VsbCwgSSBndWVzcyBJIHNob3Vs ZCBoYXZlIGV4cGxhaW5lZCB0aGUgbmVlZCBvZiB0aGlzCj4gd2l0aCBhIG1vcmUgc29saWQgcmVh bCB3b3JsZCB1c2UgY2FzZS4KPiBSZWNlbnRseSBJIGFtIGludm9sdmVkIGluIGEgcHJvamVjdCB1 c2luZyBLcmFuZywgYSBDTVMKPiBzeXN0ZW0gd3JpdHRlbiBpbiBQZXJsIHRoYXQgdXRpbGl6ZXMg SFRNTDo6VGVtcGxhdGUuCj4gTm93IGhlcmUgaXMgdGhlIHRoaW5nLCB3ZSBhcmUgZmFpcmx5IG5l dyB0byB0aGUgY29kZQo+IGJhc2UsIGJ1dCBpbiBhIGZldyBkYXlzIG9mIGdvaW5nIHRocm91Z2gg dGhlIGNvZGUgYW5kCj4gcG9raW5nIGFyb3VuZCB0aGUgY29kZSwgd2Ugd2VyZSBhYmxlIHRvIGlt cGxlbWVudAo+IHF1aXRlIGEgZmV3IG5ldyBmZWF0dXJlcyBmb3IgdGhlIGNsaWVudC4KPgo+IEJ1 dCBvdXIgdW5kZXJzdGFuZGluZyBvZiB0aGUgc3lzdGVtIGlzIHN0aWxsIGltbWF0dXJlCj4gYW5k IGluY29tcGxldGUsIGFuZCB0aGVyZSBhcmUgdGltZXMgdGhlIHRlbXBsYXRlIHZhcgo+IGlzIGJl aW5nIHNldCBzb21ld2hlcmUgaW4gdGhlIGluaGVyaXRhbmNlIGNoYWluLCBhbmQKPiB3ZSBrbm93 IGEgdGVtcGxhdGUgY2FuIGFjY2VzcyBhIHNwZWNpZmljIHZhcmlhYmxlCj4gKHRocm91Z2ggaW5j b21wbGV0ZSBkb2MgYW5kIHRtcGxfaWYgdGVzdCksIGJ1dCB0aGVyZQo+IGlzIG5vIHdheSB0byBr bm93IGhvdyB0byBhY2Nlc3MgdGhlIHZhcmlhYmxlIHdpdGhvdXQKPiBnb2luZyB0aHJvdWdoIHRo ZSBjb2RlIHRyYWNpbmcgb3V0IHdoZXJlIGFuZCB3aGF0IGlzCj4gc2VudCB0byB0aGUgdGVtcGxh dGUuICBBbmQgd2hhdCBpZiB0aGUgZG9jdW1lbnRhdGlvbgo+IG1pc3NlcyB0YWxraW5nIGFib3V0 IGEgdmFyIHRoYXQgaXMgc2VudCB0byB0aGUKPiB0ZW1wbGF0ZT8gIE5vIG9uZSB5b3UgY2FuIGZp bmQgb3V0IHVubGVzcyB5b3UgcG9rZQo+IGFyb3VuZCB0aGUgY29kZSwgYnV0IHRoZSBwcm9jZXNz IGNhbiBiZSB0aW1lIGNvbnN1bWluZwo+IGFzIG5vdCBhbGwgdGhlIHRlbXBsYXRlcyBhcmUgYmVp bmcgc2V0IGluIG9uZSBmaWxlCj4gKGR1ZSB0byBPTykuCj4KPiBJIGZpbmQgaXQgc3VycHJpc2lu ZyB0aGF0IHBlb3BsZSBleHBlY3QgcHJvYmxlbXMgY2FuCj4gYmUgc29sdmVkIHdpdGggZG9jdW1l bnRhdGlvbiwgb3IgY29tbXVuaWNhdGlvbiB3aXRoCj4gdGhlIGZyb250ZW5kIGZvbGtzLiAgSW4g dGhlIHJlYWwgd29ybGQsIGRvY3VtZW50YXRpb24KPiBpcyBuZXZlciBhcyBjb21wbGV0ZSBhcyBz aG91bGQsIEkgbWVhbiwgaXQncyBoYXJkCj4gZW5vdWdoIHRvIGdldCBzb21lIHRvIGNvbW1lbnQg dGhlaXIgY29kZSEgIEFuZCBpbiB0aGUKPiByZWFsIHdvcmxkLCB5b3UgZG9uJ3QgYWx3YXlzIHN0 YXJ0IGEgcHJvamVjdCB3aXRoIGNvZGUKPiB0aGF0IHlvdSBoYXZlIHdyaXR0ZW4gYXMgd2VsbC4g IFRoZSBuZWVkIHRvIGJlIGFibGUgdG8KPiBpbnRyb3NwZWN0IGFuZCBhY2Nlc3Mgd2hhdCBpcyBz ZW50IHRvIHRoZSB0ZW1wbGF0ZQo+IHdpdGhvdXQgaGF2aW5nIHRoZSBwZXJsIGNvZGUgaXMgYSB1 c2VmdWwgYW5kCj4ganVzdGlmaWFibGUgZmVhdHVyZSBvZiBhbnkgc2VydmVyLXNpZGUgc2NyaXB0 aW5nCj4gZnJhbWV3b3JrLgo+Cj4KPiAtIGJvb24KPgo+IC0tLSAiV2VibWFzdGVyIFRlY2hjb2Rl Lk5FVCIgPHdlYm1hc3RlckB0ZWNoY29kZS5uZXQ+Cj4gd3JvdGU6Cj4KPiA+Cj4gPiAtLS0tLSBP cmlnaW5hbCBNZXNzYWdlIC0tLS0tCj4gPiBGcm9tOiBCb29uIENoZXcKPiA+Cj4gPiBJIHdhbnQg YSB3YXkgdG8gcXVpY2tseSBkaXNwbGF5IGFsbCB0aGUgaW5mbyBpbiBhCj4gPiB2YXIgLSBhIER1 bXBlciBvdXRwdXQgaWYgeW91IHdpbGwuICBCdXQgbW9yZSB0aGFuCj4gPiB0aGF0LCBsaWtlIGlu IHNvbWUgb3RoZXIgc2VydmVyLXNpZGUgbGFuZ3VhZ2UsIHlvdQo+ID4gY2FuIHF1ZXJ5IHRoZSBj b2x1bW4gbGlzdHMgKG9yIGhhc2gga2V5cykgYW5kIGxvb3AKPiA+IHRocm91Z2ggdGhvc2UgYW5k IHVzZSBhIHBpZWNlIG9mIGdlbmVyaWMgY29kZSB3aGVuCj4gPiBhbGwgeW91IGludGVuZCB0byBk byBpcyB0byBkaXNwbGF5IGV2ZXJ5dGhpbmcgaW4gdGhlCj4gPiB2YXIuCj4gPgo+ID4gLS0tLS0g T3JpZ2luYWwgTWVzc2FnZSAtLS0tLQo+ID4KPiA+IEkgYWdyZWUgLSBzb21ldGhpbmcgbGlrZSBE YXRhOjpEdW1wZXIgaW4KPiA+IEhUTUw6OlRlbXBsYXRlIGNvbnRleHQgd291bGQgYmUgZ3JlYXQu Cj4gPgo+ID4gQW5kIHlvdSBjYW4gYWxzbyAieW91IGNhbiBxdWVyeSB0aGUgY29sdW1uIGxpc3Rz IChvcgo+ID4gaGFzaCBrZXlzKSBhbmQgbG9vcCB0aHJvdWdoIHRob3NlIiBpbiBQZXJsIGp1c3Qg bGlrZQo+ID4gaW4gYW55IG90aGVyIHNlcnZlci1zaWRlIGxhbmd1YWdlIC4uLgo+ID4KPiA+IGZv cmVhY2goQGFycmF5KXsKPiA+ICAgICBwcmludCAkXywiXG48YnI+IjsKPiA+IH0KPiA+Cj4gPgo+ ID4KPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0KPiA+IFRoZSB0aWdodCBjb3VwbGlu ZyBvZiBrbm93bGVkZ2UgYmV0d2VlbiB3aGF0J3MgYmVpbmcKPiA+IHNlbnQgZnJvbSB0aGUgcGVy bCBjb2RlIGFuZCB0aGUgSFRNTCBjYW4gYmUgYXZvaWRlZCwKPiA+IHRoYXQncyB0aGUgd2hvbGUg cG9pbnQgb2YgdGhlIGRlc2lnbiBvZiB0aGUgdGVtcGxhdGUKPiA+IG1vZHVsZSAodnMgTWFzb24g d2hlcmUgeW91IG1pbmdsZSBQZXJsIGNvZGUgd2l0aAo+ID4gZGlzcGxheSBjb2RlKSByaWdodD8g IEl0IGp1c3Qgc2VlbXMgdWdseSB3aGVuIEkgaGF2ZQo+ID4gdG8gdGVsbCBhIGRlc2lnbmVyIHRv IGdvIGxvb2sgYXQgdGhlIHBlcmwgZmlsZSB0bwo+ID4gc2VlIHdoYXQgaGUgaXMgZ2V0dGluZyBp biB0aGUgdmFyLiAgSGUgc2hvdWxkIGJlCj4gPiBhYmxlIHRvIGZpbmQgdGhhdCBvdXQgZnJvIG0g c29tZSBzZW5zaWJsZQo+ID4gY29uc3RydWN0cy4KPiA+IC0tLS0tIE9yaWdpbmFsIE1lc3NhZ2Ug LS0tLS0KPiA+Cj4gPiBZb3UgbWlzc2VkIHRoZSBwb2ludCAuLi4KPiA+Cj4gPiBJIG1lYW4gLSBk ZXNpZ25lciBzaG91bGRuJ3QgbmVlZCB0byB0YWtlIGEgbG9vayBhdAo+ID4gUGVybCBjb2RlIHRv IGZpZ3VyZSBvdXQgd2hhdCB5b3UgYXJlIG91dHB1dGluZyAuLi4KPiA+IEFuZCAic29tZSBzZW5z aWJsZSBjb25zdHJ1Y3RzIiBhcmUgZG9jdW1lbnRzIHRoYXQKPiA+IGZvbG93IGV2ZXJ5IHByb2pl Y3QuIEhhdmUgeW91IGV2ZXIgaGVhcmVkIG9mIHRlcm1zCj4gPiBsaWtlIEFQSSBvciBJbnRlcmZh Y2U/IFlvdSBhbmQgeW91IGRlc2lnbmVyIG5lZWQgdG8KPiA+IGFncmVlIG9uICJJbnRlcmZhY2Ui IC0gaW4geW91ciBjYXNlIHRoZSBkYXRhIGhlIGNhbgo+ID4gdXNlIGluIHRoZSB0ZW1wbGF0ZSAu Li4KPiA+Cj4gPiBBbnl3YXkgLSB0aGUgcXVpY2sgYW5kIHNpbXBsZSBzb2x1dGlvbiB0aGF0IGp1 c3QKPiA+IGNyb3NzZWQgbXkgbWluZCA7KQo+ID4KPiA+IE1ha2Ugc29tZXRoaW5nIGEgcnVsZSAt IGZvciBlYWNoIHRlbXBsYXRlIC0geW91Cj4gPiBjb3VsZCBjcmVhdGUgYSBzcGVjaWFsIHZhcmlh YmxlLiBTYXkgeW91IGNhbiBuYW1lIGl0Cj4gPiA6ICJ0aGVfZHVtcCIgb3Igd2hhdGV2ZXIuCj4g PiBBbmQgc2ltcGx5IGR1bXAgdmlhIERhdGE6OkR1bXBlciBhbGwgdmFyaWFibGVzIHRoYXQKPiA+ IHlvdSAocGxhbikgcG9wdWxhdGUgdGhlIHRlbXBsYXRlIHdpdGggLSBvciBzZW5kIHRvCj4gPiB0 ZW1wbGF0ZS4KPiA+Cj4gPiBBY3R1YWx5IC0gdGhpcyBjb3VsZCBiZSBtYWRlIGFzIHBhcnQgb2YK PiA+IEhUTUwtVGVtcGxhdGUgLi4uCj4gPgo+ID4gQW55d2F5IC0gdGhlbiB5b3VyIGRlc2lnbmVy IGNvdWxkIGp1c3QgYWRkIDx0bXBsX3Zhcgo+ID4gbmFtZT0idGhlX2R1bXAiPiBhdCB0aGUgZW5k IG9mIHRoZSB0ZW1wbGF0ZSBpZiBoZSBpcwo+ID4gbm90IHN1cmUgd2hhdCBkYXRhIGhlIGNhbiBh Y2Nlc3MuCj4gPgo+ID4gT2YgY291cnNlIC0gbmV4dCB0aGluZyBoZSB3aWxsIGNvbXBsYWluIGlz IHdoeSBpbgo+ID4gdGhlIGhlbGwgaGUgY2FuJ3QgZG8gYSBwcmV2aWV3IGluIERyZWFtd2VhdmVy IHdpdGgKPiA+IHRlc3QgZGF0YSBhbHJlYWR5IHBvcHVsYXRlZCAuLi4KPiA+Cj4gPiBDaGVlcnMs Cj4gPiBBbGV4Lgo+ID4gThisSFnetemailissponsoredbwnplunP4ncDoyougo+ID4g3qbYa6Lo IZaIH4pXrH6K6ShyKYblemsStopDowo+IOWhp22F6d7AAkBex5qtyF6eCKd62Fq2ZqR6yx5qtyGK eDKi6uWiB+KV6xqx5qzJqyy6t+KeC2F7B5sM5T8s4ANI8tQ0qG22n/9p2yix2dyib9p2J++t+2pZ aHIn16865opyWJw/e2aW16amVq166x4ocinJmopYp4JYrLR7ZpbXpqZWrXrrHihyKclistssourc eforP+nethttps//listssourceforgeP+t/lists/listinfj/htmltemplatcocimx6uwKPgo+ Cj4KPgo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXwo+IFlhaG9v ISBEU0wgliBTb21ldGhpbmcgdG8gd3JpdGUgaG9tZSBhYm91dC4KPiBKdXN0ICQxNi45OS9tby4g b3IgbGVzcy4KPiBkc2wueWFob28uY29tCj4KPgo+Cj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQo+IFRoaXMgU0YubmV0IGVtYWlsIGlzIHNw b25zb3JlZCBieTogU3BsdW5rIEluYy4gRG8geW91IGdyZXAgdGhyb3VnaCBsb2cgZmlsZXMKPiBm b3IgcHJvYmxlbXM/ICBTdG9wISAgRG93bmxvYWQgdGhlIG5ldyBBSkFYIHNlYXJjaCBlbmdpbmUg dGhhdCBtYWtlcwo+IHNlYXJjaGluZyB5b3VyIGxvZyBmaWxlcyBhcyBlYXN5IGFzIHN1cmZpbmcg dGhlICB3ZWIuICBET1dOTE9BRCBTUExVTkshCj4gaHR0cDovL2Fkcy5vc2RuLmNvbS8/YWRfaWQ9 NzYzNyZhbGxvY19pZD0xNjg2NSZvcD1jbGljawo+IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fCj4gSHRtbC10ZW1wbGF0ZS11c2VycyBtYWlsaW5nIGxpc3QK PiBIdG1sLXRlbXBsYXRlLXVzZXJzQGxpc3RzLnNvdXJjZWZvcmdlLm5ldAo+IGh0dHBzOi8vbGlz dHMuc291cmNlZm9yZ2UubmV0L2xpc3RzL2xpc3RpbmZvL2h0bWwtdGVtcGxhdGUtdXNlcnMKPgo= |
From: Octavian R. <ora...@fc...> - 2005-12-03 12:43:19
|
From: "Carl Franks" <fir...@gm...> > If you make sure > die_on_bad_params => 1 > is set in your HTML::Template constructor, then any variable which > isn't set in the template, or is misspelt will cause the page to die - > the designer can then tell what's wrong by simply looking at the error > message. > > Carl > This is not always simple. Sometimes the error says only something like... that the variable "id" is not present in the template file. But if I take a look in the main program, I see that there is no "id" defined with: $ht->param(id => $id); Usually the key "id" is included in another variable but this is not very easy to find, because that variable might be returned by a separate module, and I don't even know in which variable is defined that "id" key. Maybe more variables which are returned by the modules contain an "id" field but I don't know which of them is wrong. It would be more helpful if H::T would also say (in that error) the name of the loop that created the error. In that case it would be more simple to find the variable which has some bad keys in it. But if die_on_bad_params => 0, will this make T::H work slower? I have some modules that return more variables than I need in a certain template because I need them in other templates or programs, and I don't want to create more if() statements or more variables in order to send just the needed vars, so I usually prefer sending more variables than the template files need. Thanks. Teddy |
From: Boon C. <was...@ya...> - 2005-12-03 20:37:29
|
Thanks Carl, useful tip. Taking your idea one step further, I think having an option such as show_all_params => 1 that shows all the params passed to the template in a Dumper fashion will be quite useful. - boon --- Carl Franks <fir...@gm...> wrote: > If you make sure > die_on_bad_params => 1 > is set in your HTML::Template constructor, then any > variable which > isn't set in the template, or is misspelt will cause > the page to die - > the designer can then tell what's wrong by simply > looking at the error > message. > > Carl > > > On 02/12/05, Boon Chew <was...@ya...> wrote: > > > > Well, I guess I should have explained the need of > this > > with a more solid real world use case. > > Recently I am involved in a project using Krang, a > CMS > > system written in Perl that utilizes > HTML::Template. > > Now here is the thing, we are fairly new to the > code > > base, but in a few days of going through the code > and > > poking around the code, we were able to implement > > quite a few new features for the client. > > > > But our understanding of the system is still > immature > > and incomplete, and there are times the template > var > > is being set somewhere in the inheritance chain, > and > > we know a template can access a specific variable > > (through incomplete doc and tmpl_if test), but > there > > is no way to know how to access the variable > without > > going through the code tracing out where and what > is > > sent to the template. And what if the > documentation > > misses talking about a var that is sent to the > > template? No one you can find out unless you poke > > around the code, but the process can be time > consuming > > as not all the templates are being set in one file > > (due to OO). > > > > I find it surprising that people expect problems > can > > be solved with documentation, or communication > with > > the frontend folks. In the real world, > documentation > > is never as complete as should, I mean, it's hard > > enough to get some to comment their code! And in > the > > real world, you don't always start a project with > code > > that you have written as well. The need to be > able to > > introspect and access what is sent to the template > > without having the perl code is a useful and > > justifiable feature of any server-side scripting > > framework. > > > > > > - boon > > > > --- "Webmaster Techcode.NET" > <web...@te...> > > wrote: > > > > > > > > ----- Original Message ----- > > > From: Boon Chew > > > > > > I want a way to quickly display all the info in > a > > > var - a Dumper output if you will. But more > than > > > that, like in some other server-side language, > you > > > can query the column lists (or hash keys) and > loop > > > through those and use a piece of generic code > when > > > all you intend to do is to display everything in > the > > > var. > > > > > > ----- Original Message ----- > > > > > > I agree - something like Data::Dumper in > > > HTML::Template context would be great. > > > > > > And you can also "you can query the column lists > (or > > > hash keys) and loop through those" in Perl just > like > > > in any other server-side language ... > > > > > > foreach(@array){ > > > print $_,"\n<br>"; > > > } > > > > > > > > > > > > ----- Original Message ----- > > > The tight coupling of knowledge between what's > being > > > sent from the perl code and the HTML can be > avoided, > > > that's the whole point of the design of the > template > > > module (vs Mason where you mingle Perl code with > > > display code) right? It just seems ugly when I > have > > > to tell a designer to go look at the perl file > to > > > see what he is getting in the var. He should be > > > able to find that out fro m some sensible > > > constructs. > > > ----- Original Message ----- > > > > > > You missed the point ... > > > > > > I mean - designer shouldn't need to take a look > at > > > Perl code to figure out what you are outputing > ... > > > And "some sensible constructs" are documents > that > > > folow every project. Have you ever heared of > terms > > > like API or Interface? You and you designer need > to > > > agree on "Interface" - in your case the data he > can > > > use in the template ... > > > > > > Anyway - the quick and simple solution that just > > > crossed my mind ;) > > > > > > Make something a rule - for each template - you > > > could create a special variable. Say you can > name it > > > : "the_dump" or whatever. > > > And simply dump via Data::Dumper all variables > that > > > you (plan) populate the template with - or send > to > > > template. > > > > > > Actualy - this could be made as part of > > > HTML-Template ... > > > > > > Anyway - then your designer could just add > <tmpl_var > > > name="the_dump"> at the end of the template if > he is > > > not sure what data he can access. > > > > > > Of course - next thing he will complain is why > in > > > the hell he can't do a preview in Dreamweaver > with > > > test data already populated ... > > > > > > Cheers, > > > Alex. > > > N¬HYÞµéX¬²'²Þu¼'¦[§?ܨº > > > Þ¦Øk¢è!W¬~é(r)åzk¶C£ > > > 塧m éÞÀ@^ÇÈ^§zØZ¶f¤zËj·!x2¢êå¢âë±æ¬É«,º·âa{å?,àHòÔ4¨m¶ÿiÛ(±ÙÜ¢oÚv'ïûjYhr'ׯ:ærX?{fצ¦Vzë(r)ÉX§X¬´{fצ¦Vzë(r)Éb²Û,¢êÜyú+?éÞ¶m¦Ïÿ+-²Ê.Ç¢¸?ë+-³ùb²Ø§~?á¶imzjej×(r)±êì > > > > > > > > > > __________________________________________ > > Yahoo! DSL Something to write home about. > > Just $16.99/mo. or less. > > dsl.yahoo.com > > > > > > > > > ------------------------------------------------------- > > This SF.net email is sponsored by: Splunk Inc. Do > you grep through log files > > for problems? Stop! Download the new AJAX search > engine that makes > > searching your log files as easy as surfing the > web. DOWNLOAD SPLUNK! > > > http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click > > _______________________________________________ > > Html-template-users mailing list > === message truncated === __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs |
From: Mathew R. <mat...@ne...> - 2005-12-08 02:08:20
|
As a thought, you could try something like this: print Dumper($ht->{param_map}); I haven't tested it, but it may work... Mathew Boon Chew wrote: >Thanks Carl, useful tip. Taking your idea one step >further, I think having an option such as > >show_all_params =3D> 1 that shows all the params passed >to the template in a Dumper fashion will be quite >useful. > > >- boon > >--- Carl Franks <fir...@gm...> wrote: > > =20 > >>If you make sure >>die_on_bad_params =3D> 1 >>is set in your HTML::Template constructor, then any >>variable which >>isn't set in the template, or is misspelt will cause >>the page to die - >>the designer can then tell what's wrong by simply >>looking at the error >>message. >> >>Carl >> >> >>On 02/12/05, Boon Chew <was...@ya...> wrote: >> =20 >> >>>Well, I guess I should have explained the need of >>> =20 >>> >>this >> =20 >> >>>with a more solid real world use case. >>>Recently I am involved in a project using Krang, a >>> =20 >>> >>CMS >> =20 >> >>>system written in Perl that utilizes >>> =20 >>> >>HTML::Template. >> =20 >> >>>Now here is the thing, we are fairly new to the >>> =20 >>> >>code >> =20 >> >>>base, but in a few days of going through the code >>> =20 >>> >>and >> =20 >> >>>poking around the code, we were able to implement >>>quite a few new features for the client. >>> >>>But our understanding of the system is still >>> =20 >>> >>immature >> =20 >> >>>and incomplete, and there are times the template >>> =20 >>> >>var >> =20 >> >>>is being set somewhere in the inheritance chain, >>> =20 >>> >>and >> =20 >> >>>we know a template can access a specific variable >>>(through incomplete doc and tmpl_if test), but >>> =20 >>> >>there >> =20 >> >>>is no way to know how to access the variable >>> =20 >>> >>without >> =20 >> >>>going through the code tracing out where and what >>> =20 >>> >>is >> =20 >> >>>sent to the template. And what if the >>> =20 >>> >>documentation >> =20 >> >>>misses talking about a var that is sent to the >>>template? No one you can find out unless you poke >>>around the code, but the process can be time >>> =20 >>> >>consuming >> =20 >> >>>as not all the templates are being set in one file >>>(due to OO). >>> >>>I find it surprising that people expect problems >>> =20 >>> >>can >> =20 >> >>>be solved with documentation, or communication >>> =20 >>> >>with >> =20 >> >>>the frontend folks. In the real world, >>> =20 >>> >>documentation >> =20 >> >>>is never as complete as should, I mean, it's hard >>>enough to get some to comment their code! And in >>> =20 >>> >>the >> =20 >> >>>real world, you don't always start a project with >>> =20 >>> >>code >> =20 >> >>>that you have written as well. The need to be >>> =20 >>> >>able to >> =20 >> >>>introspect and access what is sent to the template >>>without having the perl code is a useful and >>>justifiable feature of any server-side scripting >>>framework. >>> >>> >>>- boon >>> >>>--- "Webmaster Techcode.NET" >>> =20 >>> >><web...@te...> >> =20 >> >>>wrote: >>> >>> =20 >>> >>>>----- Original Message ----- >>>>From: Boon Chew >>>> >>>>I want a way to quickly display all the info in >>>> =20 >>>> >>a >> =20 >> >>>>var - a Dumper output if you will. But more >>>> =20 >>>> >>than >> =20 >> >>>>that, like in some other server-side language, >>>> =20 >>>> >>you >> =20 >> >>>>can query the column lists (or hash keys) and >>>> =20 >>>> >>loop >> =20 >> >>>>through those and use a piece of generic code >>>> =20 >>>> >>when >> =20 >> >>>>all you intend to do is to display everything in >>>> =20 >>>> >>the >> =20 >> >>>>var. >>>> >>>>----- Original Message ----- >>>> >>>>I agree - something like Data::Dumper in >>>>HTML::Template context would be great. >>>> >>>>And you can also "you can query the column lists >>>> =20 >>>> >>(or >> =20 >> >>>>hash keys) and loop through those" in Perl just >>>> =20 >>>> >>like >> =20 >> >>>>in any other server-side language ... >>>> >>>>foreach(@array){ >>>> print $_,"\n<br>"; >>>>} >>>> >>>> >>>> >>>>----- Original Message ----- >>>>The tight coupling of knowledge between what's >>>> =20 >>>> >>being >> =20 >> >>>>sent from the perl code and the HTML can be >>>> =20 >>>> >>avoided, >> =20 >> >>>>that's the whole point of the design of the >>>> =20 >>>> >>template >> =20 >> >>>>module (vs Mason where you mingle Perl code with >>>>display code) right? It just seems ugly when I >>>> =20 >>>> >>have >> =20 >> >>>>to tell a designer to go look at the perl file >>>> =20 >>>> >>to >> =20 >> >>>>see what he is getting in the var. He should be >>>>able to find that out fro m some sensible >>>>constructs. >>>>----- Original Message ----- >>>> >>>>You missed the point ... >>>> >>>>I mean - designer shouldn't need to take a look >>>> =20 >>>> >>at >> =20 >> >>>>Perl code to figure out what you are outputing >>>> =20 >>>> >>... >> =20 >> >>>>And "some sensible constructs" are documents >>>> =20 >>>> >>that >> =20 >> >>>>folow every project. Have you ever heared of >>>> =20 >>>> >>terms >> =20 >> >>>>like API or Interface? You and you designer need >>>> =20 >>>> >>to >> =20 >> >>>>agree on "Interface" - in your case the data he >>>> =20 >>>> >>can >> =20 >> >>>>use in the template ... >>>> >>>>Anyway - the quick and simple solution that just >>>>crossed my mind ;) >>>> >>>>Make something a rule - for each template - you >>>>could create a special variable. Say you can >>>> =20 >>>> >>name it >> =20 >> >>>>: "the_dump" or whatever. >>>>And simply dump via Data::Dumper all variables >>>> =20 >>>> >>that >> =20 >> >>>>you (plan) populate the template with - or send >>>> =20 >>>> >>to >> =20 >> >>>>template. >>>> >>>>Actualy - this could be made as part of >>>>HTML-Template ... >>>> >>>>Anyway - then your designer could just add >>>> =20 >>>> >><tmpl_var >> =20 >> >>>>name=3D"the_dump"> at the end of the template if >>>> =20 >>>> >>he is >> =20 >> >>>>not sure what data he can access. >>>> >>>>Of course - next thing he will complain is why >>>> =20 >>>> >>in >> =20 >> >>>>the hell he can't do a preview in Dreamweaver >>>> =20 >>>> >>with >> =20 >> >>>>test data already populated ... >>>> >>>>Cheers, >>>>Alex. >>>>N=18=ACHY=DE=B5=E9s(S(X=AC=B2s('=B2S(=DEu=BC'=A6[=A7?0/00=DC=0EOE=A8=BA= >>>>=DE=A6=D8k=A2=E8!-^=1FS(W=AC~S(=E9(r)+=E5zk=12=B6S(C=A3 >>>> =20 >>>> >=E5=A1=A7m...=E9=DE=C0=02@^=C7s(=AD=C8^z(=08=A7z=D8Z=B6f=A4z=CB=1Ej=B7!S= (x2=A2=EA=E5=A2=07=E2.=EB=1A=B1=E6=AC=C9=AB,=BA=B7=E2z(=0Ba{=07>=0C=E5?,=E0= =03H=F2=D44=A8m=B6Y"=FFi=DB(=B1=D9=DC=A2o=DAv'=EF=AD=FBjYhr'=D7=AF:=E6S(r= Xoe?{f-=D7=A6=A6V=ADz=EB=1E(r)=C9s(S(X=A7,X=AC=B4{f-=D7=A6=A6V=ADz=EB=1E(= r)=C9b=B2=DB,=A2=EA=DCy=FA+?=E9=DE=B6=1Bm=A6=CF=FF-+-=B2=CA.=AD=C7Y"=A2=B8= =1E?=EB?-+-=B3=F9b=B2=D8=A7~?=E1=B6imzjej=D7(r)=B1=EA=EC > =20 > >>> >>> >>>__________________________________________ >>>Yahoo! DSL - Something to write home about. >>>Just $16.99/mo. or less. >>>dsl.yahoo.com >>> >>> >>> >>> >>> =20 >>> >------------------------------------------------------- > =20 > >>>This SF.net email is sponsored by: Splunk Inc. Do >>> =20 >>> >>you grep through log files >> =20 >> >>>for problems? Stop! Download the new AJAX search >>> =20 >>> >>engine that makes >> =20 >> >>>searching your log files as easy as surfing the=20 >>> =20 >>> >>web. DOWNLOAD SPLUNK! >> =20 >> >http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick > =20 > >>>_______________________________________________ >>>Html-template-users mailing list >>> =20 >>> >=3D=3D=3D message truncated =3D=3D=3D > > > > =09 >__________________________________=20 >Start your day with Yahoo! - Make it your home page!=20 >http://www.yahoo.com/r/hs > > >------------------------------------------------------- >This SF.net email is sponsored by: Splunk Inc. Do you grep through log f= iles >for problems? Stop! Download the new AJAX search engine that makes >searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! >http://ads.osdn.com/?ad_id=3D7637&alloc_id=3D16865&op=3Dclick >_______________________________________________ >Html-template-users mailing list >Htm...@li... >https://lists.sourceforge.net/lists/listinfo/html-template-users > =20 > |