html-template-users Mailing List for HTML::Template (Page 62)
Brought to you by:
samtregar
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(42) |
Jul
(80) |
Aug
(77) |
Sep
(97) |
Oct
(65) |
Nov
(80) |
Dec
(39) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(63) |
Feb
(47) |
Mar
(45) |
Apr
(63) |
May
(67) |
Jun
(51) |
Jul
(78) |
Aug
(37) |
Sep
(45) |
Oct
(59) |
Nov
(50) |
Dec
(70) |
2004 |
Jan
(23) |
Feb
(90) |
Mar
(37) |
Apr
(53) |
May
(111) |
Jun
(71) |
Jul
(35) |
Aug
(58) |
Sep
(35) |
Oct
(35) |
Nov
(35) |
Dec
(20) |
2005 |
Jan
(51) |
Feb
(19) |
Mar
(20) |
Apr
(8) |
May
(26) |
Jun
(14) |
Jul
(49) |
Aug
(24) |
Sep
(20) |
Oct
(49) |
Nov
(17) |
Dec
(53) |
2006 |
Jan
(12) |
Feb
(26) |
Mar
(45) |
Apr
(19) |
May
(19) |
Jun
(13) |
Jul
(11) |
Aug
(9) |
Sep
(10) |
Oct
(16) |
Nov
(17) |
Dec
(13) |
2007 |
Jan
(9) |
Feb
(12) |
Mar
(28) |
Apr
(33) |
May
(12) |
Jun
(12) |
Jul
(19) |
Aug
(4) |
Sep
(4) |
Oct
(5) |
Nov
(5) |
Dec
(13) |
2008 |
Jan
(6) |
Feb
(7) |
Mar
(14) |
Apr
(16) |
May
(3) |
Jun
(1) |
Jul
(12) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(9) |
2009 |
Jan
(9) |
Feb
|
Mar
(10) |
Apr
(1) |
May
|
Jun
(6) |
Jul
(5) |
Aug
(3) |
Sep
(7) |
Oct
(1) |
Nov
(15) |
Dec
(1) |
2010 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
|
Jun
|
Jul
(5) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
2011 |
Jan
|
Feb
(3) |
Mar
|
Apr
(28) |
May
|
Jun
|
Jul
(3) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
(8) |
Dec
|
2012 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2013 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2015 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
2016 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
From: 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: Mathew R. <mat...@re...> - 2003-12-10 01:19:40
|
> That's why I wrote my TMPL_SET extension, which does essentially the > same thing as TMPL_VALUE. The only reason I can see for incorporating > that functionality into H::T directly is so that other people who=20 > haven't found this list can use it... I'd be entirely happy to see it=20 > remain a separate module. Is this implemented as a filter? In any case, I would be interested in = having a look at how you did this. regards, Mathew |
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: 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: 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: 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: 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 22:30:41
|
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, and I had to do interleaved includes to get the title (among other things) in. Which is no big deal, other than it necessitates putting rather more structure in each content-template than I'd really like to have. If, on t'other hand, you start with a master template and stuff the content in via TMPL_VARs, you can stuff the title just as well as the main content... but then you lose the ability to have TMPL_VARs within the 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)). There are advantages and drawbacks to either approach. -- Karen J. Cravens si...@ph... |
From: Puneet K. <pk...@ei...> - 2003-12-09 21:53:49
|
Karen J. Cravens wrote: > On Tue, 9 Dec 2003, Puneet Kishor wrote: > > PK>I achieve consistent look and feel via css. I achieve consistent layout > PK>via H::T. > > I use CSS as well, but that doesn't change how the title gets handled. > Perhaps if you could give an example of how you build the headers, it > might be clearer to us. > well, now that you put it that way, I feel I might be the one who is not really understanding what you all are saying, and hence, am perhaps barking tangentially ;-). Anyway, here are a couple of examples (there might be typos, but should be sufficient for explanation purpose). Does this make sense? Btw, I prefer Setup 1 over Setup 2 because designer types can actually visualize different pages and the entire site layout -- even more easily if they are using Golive or Dreamweaver or somesuch. ======================================================================== Setup 1. Using separate templates for each page ======================================================================== .. my $act = !defined(param('act')) ? 'welcome' : scalar(param('act')); # Invoke template based on act. There are separate templates for # each page. The templates are stored in a separate directory so # "designer" types can work on them without worrying the scripts. my $template = HTML::Template->new(filename => "$act.tmpl"); $template->param('content'=>&content($act), 'title'=>&title($act)); .. -------------------------------------------------------------------- meantime, in the templates (this one is called "welcome.tmpl") -------------------------------------------------------------------- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <head> <title><tmpl_var title></title> <link rel="stylesheet" type="text/css" href="../myapp.css"> </head> <body> <div class="content"><tmpl_var content></div> </body> </html> ====================================================================== Setup 2. Using one template for all the pages ====================================================================== .. my $act = !defined(param('act')) ? 'welcome' : scalar(param('act')); # Invoke template. A single template for the entire app, but the # header and footer can be changed based on act. The templates are # stored in a separate directory so "designer" types can work on # them without worrying the scripts. my $template = HTML::Template->new(filename => 'index.tmpl'); $template->param('content'=>&content($act), 'title'=>&title($act)); .. -------------------------------------------------------------------- meantime, in the templates -------------------------------------------------------------------- header.tmpl -------------------------------------------------------------------- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <head> <title><tmpl_var title></title> <link rel="stylesheet" type="text/css" href="../myapp.css"> </head> <body> -------------------------------------------------------------------- index.tmpl -------------------------------------------------------------------- <tmpl_include header.tmpl> <div class="content"><tmpl_var content></div> <tmpl_include footer.tmpl> -------------------------------------------------------------------- footer.tmpl -------------------------------------------------------------------- <hr> another app served by the wonders of Perl and HTML::Template </body> </html> |
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: Roger B. W. <ro...@fi...> - 2003-12-09 20:52:35
|
On Tue, Dec 09, 2003 at 01:42:07PM -0600, Puneet Kishor wrote: >I achieve consistent look and feel via css. I achieve consistent layout >via H::T. Call it layout if you prefer. Many of my users don't have CSS available anyway. >If you are loathe to use a database for just the title, well, just use a >text file, or hardcode a list of titles and cherrypick. Why should I have to, though? The page's content is in the page file. Why shouldn't the page's title, which is after all directly related to the content, also be in the page file? Putting it somewhere else means more things to (fail to) keep track of and, to me at least, feels very counterintuitive. That's why I wrote my TMPL_SET extension, which does essentially the same thing as TMPL_VALUE. The only reason I can see for incorporating that functionality into H::T directly is so that other people who haven't found this list can use it... I'd be entirely happy to see it remain a separate module. Roger |
From: Karen J. C. <si...@ph...> - 2003-12-09 20:50:15
|
On Tue, 9 Dec 2003, Puneet Kishor wrote: PK>I achieve consistent look and feel via css. I achieve consistent layout PK>via H::T. I use CSS as well, but that doesn't change how the title gets handled. Perhaps if you could give an example of how you build the headers, it might be clearer to us. |
From: Brett S. <swi...@sw...> - 2003-12-09 20:24:34
|
> The only alternative I can see is to set up a database of some sort > which would contain the title for each page. This seems silly. Actually, that's exactly what I do. The database contains the page title, visibility flags, and parent/child/offlink relationships. Thus my left rail and bread-crumbing is built from the database. The beauty of not having to maintain the left rail is well worth it. I can see how this is too involved for a handful of pages, but I don't see it as "silly" for any site of size. -- SwiftOne / Brett Sanger swi...@sw... |
From: Karen J. C. <si...@ph...> - 2003-12-09 20:16:13
|
On Tue, 9 Dec 2003, Roger Burton West wrote: RBW>The only alternative I can see is to set up a database of some sort RBW>which would contain the title for each page. This seems silly. That's pretty much what I've been doing (the part I snipped, that is), but now that I'm essentially turning the whole site into a Wiki, technically I *am* going to have an auto-generated title. Not in the database, though; it'll more likely be the site + web + Wiki Word (a la "Phoenyx : Members : Karen Cravens"). Which sort of eliminates the problem, for me, I guess, since it'll make the title code-generated. But right now, I'm doing it something like Cees described... each (content) page looks something like this: (include for the header fragment) Title Of The Page (include for another header fragment, up to the BODY tag) Menu Bar Or An Include For A Standard One (include for a formatting fragment) Main Content (include more formatting) Sidebar Or An Include For A Standard One (include for the ending formatting) I suppose some sort of interleaving function would be kind of neat, but I can't think of any elegant way to do it. The Wiki version flips that all around, and just has a main template with a TMPL_VAR for the title, menu bar, content, and sidebar. I may end up using sub-templates to generate some of that (a sort of simulated variable include), but more likely it'll be generic Wiki text files (TWiki, specifically). Though, come to think of it, I don't think H::T's variables/includes would be any harder to use than TWiki's, so I might end up with a hybrid. -- Karen J. Cravens si...@ph... |
From: Puneet K. <pk...@ei...> - 2003-12-09 19:37:12
|
Roger Burton West wrote: > On Tue, Dec 09, 2003 at 01:07:04PM -0600, Puneet Kishor wrote: > >>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. > > > One of the things for which I use H::T is to get a consistent look to a > site. Each page is written as a template with header and footer includes > much as Cees Hek stated. Those titles are fixed per-page, and all the > templates are run through the same script to get the final HTML output; > not only does each page get its title, but the "related pages" links use > the titles of those related pages too. > > The only alternative I can see is to set up a database of some sort > which would contain the title for each page. This seems silly. > interesting. Most everything you say above is what I do as well. Except, I have never run into the above problems (of course, I have run into many other problems, but that is not the purview of H::T). I achieve consistent look and feel via css. I achieve consistent layout via H::T. If you are loathe to use a database for just the title, well, just use a text file, or hardcode a list of titles and cherrypick. I mean, you are willing to use Perl/H::T to achieve a consistency of appearance and don't consider that silly (I am assuming that by your statement above you are _not_ using Perl/H::T to generate the content dynamically), but don't want to use dynamically allocated titles and consider that silly. ;-) I am not saying the above to fight or to be rude... but actually to learn from what and why is that you are working the way you are... hopefully I will learn some tricks. But it seems that the variation that you (and Cees and Karen) have specified has little to do with H::T. I mean, any tool can and will be used in ways other than the designer of that tool meant it for... the key is to balance between the tool's simplicity versus provision for all possible creative uses of that tool. Otoh, the need for TMPL_ELSIF tags... I didn't see any need for it, but when Timm articulated it so well, it seems to me, hey, that would be real nice. Because not having it does H::T wrong... after all, H::T's goal in life is to avoid logic in display as much as possible. And having ELSIF will allow it to do that. In any case, great discussion and input. I guess the final choice will (and should) be Sam's. Just nice to see that H::T has a future at least upto version 2.7. More than that would be like predicting the stock market. H::T is a great program... thanks to everyone who made it (Sam and whoever else), and this is a great community... thanks to all those who have helped me when I was stuck. |
From: Sam T. <sa...@tr...> - 2003-12-09 19:30:48
|
On Tue, 9 Dec 2003, Paulsen, Brian wrote: > > This is trivially done in a filter, so there's no reason to add it to the > core code. > > Agreed, but I think one thing that might be useful is to include a filter > package that has some of the commonly requested filters. Sounds like a good idea. When will you upload it to CPAN? ;) -sam PS: I wonder if you can help me with something. Someone at lehman.com is bouncing mail from this list, but they don't seem to be subscribed. Their address is jn...@ex.... Maybe you can poke around and figure out what's going on at your domain? Thanks! |
From: Paulsen, B. <BPa...@le...> - 2003-12-09 19:27:41
|
> This is trivially done in a filter, so there's no reason to add it to the core code. Agreed, but I think one thing that might be useful is to include a filter package that has some of the commonly requested filters. ------------------------------------------------------------------------------ This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. |
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: Roger B. W. <ro...@fi...> - 2003-12-09 19:16:29
|
On Tue, Dec 09, 2003 at 01:07:04PM -0600, Puneet Kishor wrote: >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. One of the things for which I use H::T is to get a consistent look to a site. Each page is written as a template with header and footer includes much as Cees Hek stated. Those titles are fixed per-page, and all the templates are run through the same script to get the final HTML output; not only does each page get its title, but the "related pages" links use the titles of those related pages too. The only alternative I can see is to set up a database of some sort which would contain the title for each page. This seems silly. Roger |
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: Puneet K. <pk...@ei...> - 2003-12-09 19:02:08
|
Cees Hek wrote: > Sam Tregar wrote: > >> On Tue, 9 Dec 2003, Lance A. Brown wrote: >> >>> # we allow tags like this in our templates that will define values >>> # to be set as parameters >>> # <TMPL_VALUE NAME="name" VALUE="value"> >> >> >> >> My eyes! It burns! Arrrrrrrgh... > > > :) I know it goes against your philosophy of HTML::Template, and that > this can be abused in nasty ways. But there is one situation where I > feel this feature is justified to keep design elements in the templates > and code in the code and it has to do with needing dynamic values in > include files. > > The most obvious example is the <title> tag in a header. I usually > include a header and footer include at the top and bottom of my > templates. The most anoying thing is to fill in that <title> tag in the > header include file. In the past I have resorted to putting this > information in the code, but it doesn't belong there. The programmer > shouldn't care what the title of the page is, that is the domain of the > designer... I know that you don't mean to state that in an absolute sort of way, 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. ;-) 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... |
From: Cees H. <ce...@si...> - 2003-12-09 18:54:10
|
Sam Tregar wrote: > On Tue, 9 Dec 2003, Lance A. Brown wrote: >> # we allow tags like this in our templates that will define values >> # to be set as parameters >> # <TMPL_VALUE NAME="name" VALUE="value"> > > > My eyes! It burns! Arrrrrrrgh... :) I know it goes against your philosophy of HTML::Template, and that this can be abused in nasty ways. But there is one situation where I feel this feature is justified to keep design elements in the templates and code in the code and it has to do with needing dynamic values in include files. The most obvious example is the <title> tag in a header. I usually include a header and footer include at the top and bottom of my templates. The most anoying thing is to fill in that <title> tag in the header include file. In the past I have resorted to putting this information in the code, but it doesn't belong there. The programmer shouldn't care what the title of the page is, that is the domain of the designer... The TMPL_VALUE filter is one way of solving this issue: =========== content.tmpl =========== <TMPL_VALUE NAME="title" VALUE="Title of the page"> <TMPL_INCLUDE NAME="header.tmpl"> Content <TMPL_INCLUDE NAME="footer.tmpl"> =========== content.tmpl =========== =========== header.tmpl =========== <html> <head> <title>Application Name: <TMPL_VAR NAME="title"></title> </head> <body> <h2><TMPL_VAR NAME="title"></h2> =========== header.tmpl =========== There are other ways around this issue by putting part of the header in each of the content templates, but I have never liked that approach: =========== content.tmpl =========== <html> <head> <title>Application Name: Page title</title> <TMPL_INCLUDE NAME="head.tmpl"> </head> <TMPL_INCLUDE NAME="bodyheader.tmpl"> <h2>Page title</h2> Content <TMPL_INCLUDE NAME="bodyfooter.tmpl"> </html> =========== content.tmpl =========== I'll admit that I haven't used this TMPL_VALUE trick in any of my code, but I can see its value -- no pun intended :) Cheers, Cees |
From: Paulsen, B. <BPa...@le...> - 2003-12-09 18:41:31
|
The HTML::Template::Filter::Dreamweaver code does exactly what you are looking for. -----Original Message----- From: Karen J. Cravens [mailto:si...@ph...] Sent: Tuesday, December 09, 2003 1:31 PM To: Lance A. Brown Subject: Re: [htmltmpl] Re: H::T future On Tue, 9 Dec 2003, Lance A. Brown wrote: LAB>Here is the relevant piece of code. Personally, I think this is a LAB>VERY tasty hack. It lets page designers plug parameters back into LAB>the 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... ------------------------------------------------------- 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 ------------------------------------------------------------------------------ This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. |
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: 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... |