Thread: RE: [htmltmpl] xml complant tags
Brought to you by:
samtregar
From: Paulsen, B. <BPa...@le...> - 2003-12-08 22:32:09
|
Alternatively, it wouldn't be too difficult to write a filter function that would transform a template with a trailing slash to one that H::T would understand. And, given how frequent H::T gets updated, it would be a MUCH quicker solution. Brian -----Original Message----- From: Mathew Robertson [mailto:mat...@re...] Sent: Monday, December 08, 2003 5:21 PM To: htm...@li... Subject: Re: [htmltmpl] xml complant tags In any case, it wouldn't be too hard to change H::T to optionally support the trailing slash. regards, Mathew ------------------------------------------------------- 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_id78&alloc_id371&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: Puneet K. <pk...@ei...> - 2003-12-08 22:43:39
|
Paulsen, Brian wrote: .. > And, given how frequent H::T gets updated, it would be a MUCH quicker > solution. > .. speaking of which, I have often wondered what could be improved in H-T, and have failed to come up with anything. It just seems to be that perfect program that does perfectly what it said to do. Simple to install and understand, well-documented, and fast. In fact, imho, it should be made a core part of Perl as is CGI.pm. But, since not being able to visualize the form of H-T's future might be due to my lack of imagination, I am curious -- what are the ways in which the developer-kind want to see H-T to be in a few years/versions or so... |
From: Karen J. C. <si...@ph...> - 2003-12-08 22:54:00
|
On Mon, 8 Dec 2003, Puneet Kishor wrote: PK>But, since not being able to visualize the form of H-T's future might be PK>due to my lack of imagination, I am curious -- what are the ways in PK>which the developer-kind want to see H-T to be in a few years/versions PK>or so... Aside from the bugfix in nested loops, I can't think of anything in particular I'd like to change. *Maybe* something formal to "comment" the fields in the template without having anything show in the final output, but right now I can do that with a filter and judiciously formatted HTML comments, so I don't know that it'd be worth adding code to the module for. I like minimalistic modules. -- Karen J. Cravens si...@ph... |
From: Sam T. <sa...@tr...> - 2003-12-08 22:56:31
|
On Mon, 8 Dec 2003, Puneet Kishor wrote: > speaking of which, I have often wondered what could be improved in H-T, > and have failed to come up with anything. It just seems to be that > perfect program that does perfectly what it said to do. Simple to > install and understand, well-documented, and fast. In fact, imho, it > should be made a core part of Perl as is CGI.pm. Thanks! > But, since not being able to visualize the form of H-T's future might be > due to my lack of imagination, I am curious -- what are the ways in > which the developer-kind want to see H-T to be in a few years/versions > or so... I've considered doing an HTML::Template version 3 a few times, but never found the time to do it. I even went so far as to draft a design document. Here it is! (Note, I have no plans to actually do this work anytime soon.) =head1 HTML Template Version 3 HTML::Template needs work. The module is being put to uses today that are far outside the scope of the original design. Adventures in syntax enhancement (tmpl_if, HTML::Template::Expr, filter), performance enhancement (HTML::Template::JIT) and CGI frameworks (CGI::Application, HTML::Pager) have pushed HTML::Template's code to the limit. Options have been added incrementally, and the complexity of the code has grown exponentially with each addition (global_vars, case_insensitive, cache). However, I have no plans to throw the baby out with the bath-water. I think HTML::Template has a lot going for it. First, it's fast and that won't change. Second, the default template syntax is, in my never humble opinion, basically perfect. Finally, the API is pretty good. In particular, the simplicity of new(), param() and output() is not something I want to mess with. So, what am I going to change? Here's an unordered list of possibilities. Take a look through and tell me what you think. Am I out of my mind? Did I leave out the feature you've always wanted? =over 4 =item * Pluggable interface for parsers, file loaders, parameter collectors, cachers, compilers and executors. I want to break up HTML::Template's implementation into a handful of well-defined modules. Each of these modules will have an interface which may be implemented independently. This will make building stuff like HTML::Template::Expr and HTML::Template::JIT much easier, as well as opening up the field for simpler, faster implementations of the standard components. =item * Make the parser module accessible outside of HTML::Template. This will make building tools that work with HTML::Template format templates much simpler. =item * Pluggable interface for custom tags and attributes. You'd think after writing HTML::Template::Expr I'd realize that this was a necessity, but it still feels like treason. However, I think I'm just going to have to accept that people are going to want to invent their own tags. Making them use a filter is just not convenient enough. This should also address the recurring ESCAPE=foo requests. =item * Make global_vars=1 the default mode and build it in right from the start. It's what everyone expects when they first use the module and I think it was a mistake to have it default off. In fact, I lean towards removing the option entirely. =item * Parse and cache <tmpl_include>s separately. This will break some things that currently work, like putting the top of a <tmpl_loop> in one include and the </tmpl_loop> in another. However, for the vast majority of uses this should provide a nice decrease in memory usage and increase in performance. =item * Work out a mechanism for variable includes. With include files being parsed and cache separately this is will probably be easier. =item * Better user-error detection. Many common cases could be caught automatically and reported to the user. For example, assigning a loop row the same hash-ref multiple times should trigger an error. =back -sam |
From: Karen J. C. <si...@ph...> - 2003-12-08 23:21:30
|
On Mon, 8 Dec 2003, Sam Tregar wrote: ST>Make global_vars=1 the default mode and build it in right from the ST>start. It's what everyone expects when they first use the module and ST>I think it was a mistake to have it default off. In fact, I lean ST>towards removing the option entirely. I could go for this. I also almost always have die-on-invalid shut off, because I tend to want my code to shove as many parameters as possible out for use, but my templates don't always use them. I may be in the minority there, though. (If I was doing thorough debugging, I suppose I'd have it turned on at first, and have test templates that accept all of them and make sure they're showing properly, and then turn it off for production use.) -- Karen J. Cravens si...@ph... |
From: Wayne W. <ww...@by...> - 2003-12-09 00:13:43
|
I would actually like a function to tell me what variables and or loops in the template were NOT populated. That way I can email or log the fact. This often happens when a web designer includes a component the developer doesn't know about so it is not getting populated. On Mon, Dec 08, 2003 at 05:21:26PM -0600, Karen J. Cravens wrote: > On Mon, 8 Dec 2003, Sam Tregar wrote: > > ST>Make global_vars=1 the default mode and build it in right from the > ST>start. It's what everyone expects when they first use the module and > ST>I think it was a mistake to have it default off. In fact, I lean > ST>towards removing the option entirely. > > I could go for this. > > I also almost always have die-on-invalid shut off, because I tend to want > my code to shove as many parameters as possible out for use, but my > templates don't always use them. I may be in the minority there, though. > (If I was doing thorough debugging, I suppose I'd have it turned on at > first, and have test templates that accept all of them and make sure > they're showing properly, and then turn it off for production use.) > > -- > 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 -- Wayne Walker ww...@by... Do you use Linux?! http://www.bybent.com Get Counted! http://counter.li.org/ Perl - http://www.perl.org/ Perl User Groups - http://www.pm.org/ Jabber IM: ww...@ja... AIM: lwwalkerbybent |
From: Karen J. C. <si...@ph...> - 2003-12-09 00:25:19
|
On Mon, 8 Dec 2003, Wayne Walker wrote: WW>I would actually like a function to tell me what variables and or loops WW>in the template were NOT populated. That way I can email or log the WW>fact. This often happens when a web designer includes a component the WW>developer doesn't know about so it is not getting populated. That's relatively simple: just loop through $template->param() and find everything that's !defined $template->param($_). (Or something like that... blame antihistamines for anything goofy in the preceding.) That might be a good recipe (a la Perl Cookbook) to include in the documentation, though. Especially fancy variations that can look inside loops. -- Karen J. Cravens si...@ph... |
From: Karen J. C. <si...@ph...> - 2003-12-09 01:31:17
|
Okay, I did think of a teeny-tiny thing I'd like to have. It's not exactly an addition to H::T itself, though. I occasionally find myself wanting to be able to define things in the template. That is, setting parameters, a sort of tiny configuration file. I've been meaning to write a standard bit of code to do something like that whenever I need some parameters that I don't want to hardcode, but that I don't really need a full-fledged configuration file manager for... something with just enough brains to parse a file, populate variables as needed, and recognize when the configuration ends and the template begins, and hand the rest of the file off to a new H::T instance. -- Karen J. Cravens si...@ph... |
From: Lance A. B. <la...@be...> - 2003-12-09 07:20:44
|
On Mon, 2003-12-08 at 20:31, Karen J. Cravens wrote: > Okay, I did think of a teeny-tiny thing I'd like to have. It's not > exactly an addition to H::T itself, though. > > I occasionally find myself wanting to be able to define things in the > template. That is, setting parameters, a sort of tiny configuration file. > > I've been meaning to write a standard bit of code to do something like > that whenever I need some parameters that I don't want to hardcode, but > that I don't really need a full-fledged configuration file manager for... > something with just enough brains to parse a file, populate variables as > needed, and recognize when the configuration ends and the template begins, > and hand the rest of the file off to a new H::T instance. Argh. I can't remember where, but I ran across a Website package using HTML::Template that had this feature. The templates in the package have <TMPL_VALUE name="foo" value="bar"> tags and used a filter function to extract them from the templates and insert them into the template params. It was a very neat hack. --[Lance] -- Carolina Spirit Quest: http://www.carolinaspiritquest.org/ Celebrate The Circle: http://www.angelfire.com/nc/celebratethecircle/ My LiveJournal: http://www.livejournal.com/users/labrown/ |
From: Cees H. <ce...@si...> - 2003-12-09 14:17:51
|
Lance A. Brown wrote: > On Mon, 2003-12-08 at 20:31, Karen J. Cravens wrote: > Argh. I can't remember where, but I ran across a Website package using > HTML::Template that had this feature. > > The templates in the package have <TMPL_VALUE name="foo" value="bar"> > tags and used a filter function to extract them from the templates and > insert them into the template params. It was a very neat hack. I spent about an hour last night trying to find the same website with no success :) It really was a cool little feature, but I can't for the life of me remember where I saw it... Hoping someone else remembers and is kind enough to post an URL. Cheers, Cees |
From: Lance A. B. <la...@be...> - 2003-12-09 15:21:47
|
Lance A. Brown wrote: > Argh. I can't remember where, but I ran across a Website package using > HTML::Template that had this feature. Aha! Found it! Yapcom, the CGI::App-based application to handle registration and workshops for YAP conferences! Here is the relevant piece of code. Personally, I think this is a VERY tasty hack. It lets page designers plug parameters back into the templating system for use elsewhere. Very cool. sub _server_page { my $self = shift; my ($page) = @_; my $q = $self->query; # we allow tags like this in our templates that will define values # to be set as parameters # <TMPL_VALUE NAME="name" VALUE="value"> my %h; my $filter = sub { my $text_ref = shift; while ($$text_ref =~ s/<\s*TMPL_VALUE\s+NAME="([^"]*)"\s+VALUE="([^"]*)"\s*>//) { $h{$1} = $2; } }; my $t = $self->load_tmpl( "$page.tmpl", die_on_bad_params => 0, filter => $filter, associate => $q, path => $templates_dir, ); $t->param(%h); $t->param(VERSION => $YAPC::Organizer::VERSION); return $t; } --[Lance] > > The templates in the package have <TMPL_VALUE name="foo" value="bar"> > tags and used a filter function to extract them from the templates and > insert them into the template params. It was a very neat hack. > > --[Lance] > -- Carolina Spirit Quest: http://www.carolinaspiritquest.org/ Celebrate The Circle: http://www.angelfire.com/nc/celebratethecircle/ My LiveJournal: http://www.livejournal.com/users/labrown/ |
From: Sam T. <sa...@tr...> - 2003-12-09 18:08:26
|
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... -sam |
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: 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: 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: 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: 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: 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: 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: 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: 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: Roger B. W. <ro...@fi...> - 2003-12-10 09:46:15
|
On Wed, Dec 10, 2003 at 12:18:52PM +1100, Mathew Robertson wrote: >Is this implemented as a filter? In any case, I would be interested in having a look at how you did this. Very much like the param version just posted here. Insert tags of the form: <tmpl_set name=x value=y> with _no_ quoting around the x and y (this is a quick-and-dirty hack); each one will provide a value for a top-level parameter. You can't do anything about values within loops with this. package HTML::Template::Set; use HTML::Template; use base qw(HTML::Template); sub new { my %set_params; my $set_filter = sub { my $text_ref=shift; my $match='<(?:\!--\s*)?tmpl_set\s*name=(.*?)\s*value=(.*?)\s*(?:--)?>'; my @taglist=$$text_ref =~ m/$match/gi; while (@taglist) { my ($t,$v)=(shift @taglist,shift @taglist); $set_params{$t}=$v; } $$text_ref =~ s/$match/<tmpl_if name=never><tmpl_var name=$1><\/tmpl_if>/gi; }; my $proto = shift; my $class = ref($proto) || $proto; my $self=HTML::Template->new(filter => $set_filter, @_); bless ($self, $class); $self->param(%set_params); return $self; } 1; |
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: 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: Roger B. W. <ro...@fi...> - 2003-12-20 11:13:32
|
On Tue, Dec 09, 2003 at 03:29:55AM -0500, Brett Sanger wrote: >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. The problem I have with it is that, when you add a page, you need to add both the file and the database entry. For the main site I administer with H::T, I use my Set extension and have a few lines at the top: <!-- tmpl_set name=title value=Personnel --> <!-- tmpl_set name=related0 value=/ --> <!-- tmpl_set name=related1 value=contact.html --> <!-- tmpl_include name=top.inc.tmpl> (actual page content here) <!-- tmpl_include name=bottom.inc.tmpl> The site-building script takes these, adds appropriate headers and <title> tags and so on, and (in a two-pass process) builds all the related-pages lists with full titles too. So if I change a page's title, or want to add or delete a related page, I just have one file to do it in. Everything about that page is in a single place. Roger |