Thread: Re: [htmltmpl] Is HTML::Template pure Perl?
Brought to you by:
samtregar
From: Carl F. <C.A...@du...> - 2004-08-02 08:15:20
|
Hi Dan, Yes, HTML::Template is pure perl. To figure out if any other module is pure perl, search for it on search.cpan.org Then follow the link with the module version number (e.g. HTML-Template-2.7). Then click on the [Browse] link to view the modules' files. If there are no *.xs *.c or *.h files and no 'b' folder, then the module is probably pure perl. For HTML::Template, you could create a folder in your home directory called (for example) 'lib' and then copy the Template.pm file into 'lib/HTML/Template.pm'. With shared hosting, you may be unable to change environment variables, in which case you could use the 'use lib' command, eg: use lib "/home/dan/lib"; Hope this helps, Carl Carl Franks Web Developer Computer And Media Services Level 8 Ninewells Hospital Faculty of Medicine, Dentistry & Nursing University of Dundee ext 35508 >>> "Dan Horne" <dan...@re...> 02/08/2004 05:00:39 >>> Hi all I'm looking for an HTML templating system that is pure Perl. The reason is that I need a templating package that can be installed on shared hosts without requiring the hosting service administrators to compile anything. I'm after something that is OS agnostic, so if I use it with a cgi app it would run on Windows, UNIX, Apache, IIS, etc. I'm kind of hoping that I can copy the root tree and set my PERL5LIB variable apprpriately. Does HTML::Template fit the bill? Regards Dan |
From: Carl F. <C.A...@du...> - 2004-08-03 08:44:24
|
Yeah, that's why I said "probably": I knew there'd be something I'd missed or didn't know about. "There's More Than One Way To Do It" Cheers, Carl >>> Sam Tregar <sa...@tr...> 03/08/2004 04:25:45 >>> On Mon, 2 Aug 2004, Carl Franks wrote: > To figure out if any other module is pure perl, search for it on > search.cpan.org Then follow the link with the module version number > (e.g. HTML-Template-2.7). Then click on the [Browse] link to view > the modules' files. If there are no *.xs *.c or *.h files and no > 'b' folder, then the module is probably pure perl. Good advice, but there's one possibility you missed. If a module uses Inline::C then it won't be pure Perl, even if it has no C source files. -sam ------------------------------------------------------- This SF.Net email is sponsored by OSTG. Have you noticed the changes on Linux.com, ITManagersJournal and NewsForge in the past few weeks? Now, one more big change to announce. We are now OSTG- Open Source Technology Group. Come see the changes on the new OSTG site. www.ostg.com _______________________________________________ Html-template-users mailing list Htm...@li... https://lists.sourceforge.net/lists/listinfo/html-template-users |
From: Sam T. <sa...@tr...> - 2004-08-03 03:25:49
|
On Mon, 2 Aug 2004, Carl Franks wrote: > To figure out if any other module is pure perl, search for it on > search.cpan.org Then follow the link with the module version number > (e.g. HTML-Template-2.7). Then click on the [Browse] link to view > the modules' files. If there are no *.xs *.c or *.h files and no > 'b' folder, then the module is probably pure perl. Good advice, but there's one possibility you missed. If a module uses Inline::C then it won't be pure Perl, even if it has no C source files. -sam |
From: Cees H. <ce...@si...> - 2004-08-04 03:04:28
|
Sam Tregar wrote: > On Mon, 2 Aug 2004, Carl Franks wrote: >>To figure out if any other module is pure perl, search for it on >>search.cpan.org Then follow the link with the module version number >>(e.g. HTML-Template-2.7). Then click on the [Browse] link to view >>the modules' files. If there are no *.xs *.c or *.h files and no >>'b' folder, then the module is probably pure perl. > > Good advice, but there's one possibility you missed. If a module uses > Inline::C then it won't be pure Perl, even if it has no C source > files. Another thing to check for is the dependancies of a module. The module itself may be pure perl, but it may depend on a module that is not. As far as I can remember, HTML::Template only depends on modules that are included in a standard perl installation, so it does not require the installation of any extra modules (that excludes the caching modules like, IPC::SharedCache[1], but they are all optional). Cheers, Cees [1] IPC::SharedCache depends on IPC::ShareLite which is an XS module |
From: Mark F. <mar...@ea...> - 2005-01-04 21:23:41
|
I just had a need to conditionally include one of a few templates dependnig on the value of a TMPL_VAR. One of the includes (which would not have been loaded) did not exist, but H::T died because it couldn't locate that file. I realized H::T probably loads everything at compile time and applies the conditions at the time the output method is called. This makes sense since caching would be screwed up if it had to keep reloading conditional includes with every output. However, I still feel like I have a need to conditionally load included templates and I know which ones they are at compile time. It's not going to change over repeated outputs called on the same cached template. I'm faced with either structuring the template includes differently (making it uglier and some duplicated HTML). Or, let it load all the stuff I know I don't need at compile time and use a TMPL_VAR (the same value for the life of the template) to tell the output method which included fragment to output. Question: Does this lead to the idea that it would be useful to have variables used only at compile time? When I tell it to load a template, why can't I give it variable name=value pairs to apply *only* at compile time? I know everyone's a fanatic about efficiency. But, couldn't this lead to more efficent template processing? If you know you have static values used for the life of the loaded template, wouldn't it be more efficient to apply them at the time the template is loaded? Instead of every time the output method is called? Examples of such life-of-the-template variables might be the language and encoding variables used to specify the language being used within that template? Or, a variable used to pick a navigation side-bar based upon system-wide parm? (Customized navigation bars for seasonal occasions? Where the CGI decides at runtime which one it wants loaded based upon the time of year?) In my case, all my pages share a common sidebar layout, but different sidebar choices. I want to nest the set of choices within the common sidebar layout and let each page (different CGI::App modules) specify which set of choices should be loaded from that common sidebar layout. But, to do that, it has to load all of them at compile time and then reevaluate the decision for each output of the template. When, it's not going to change for the life of that loaded template. It's not the end of the world. But, it seemed like a potential opportunity to make H::T a little more efficient by allowing some evaluation criteria to be performed at compile time. Am I totally off base? Thanks, Mark |
From: Mathew R. <mat...@re...> - 2005-01-04 22:01:56
|
> I just had a need to conditionally include one of a few templates = dependnig > on the value of a TMPL_VAR. One of the includes (which would not have = been > loaded) did not exist, but H::T died because it couldn't locate that = file. I > realized H::T probably loads everything at compile time and applies = the > conditions at the time the output method is called. >=20 > This makes sense since caching would be screwed up if it had to keep > reloading conditional includes with every output. >=20 > However, I still feel like I have a need to conditionally load = included > templates and I know which ones they are at compile time. It's not = going to > change over repeated outputs called on the same cached template. I'm = faced > with either structuring the template includes differently (making it = uglier > and some duplicated HTML). Or, let it load all the stuff I know I = don't need > at compile time and use a TMPL_VAR (the same value for the life of the > template) to tell the output method which included fragment to output. >=20 > Question: Does this lead to the idea that it would be useful to have > variables used only at compile time? When I tell it to load a = template, why > can't I give it variable name=3Dvalue pairs to apply *only* at compile = time? Its an interesting idea... > I know everyone's a fanatic about efficiency. But, couldn't this lead = to > more efficent template processing? If you know you have static values = used > for the life of the loaded template, wouldn't it be more efficient to = apply > them at the time the template is loaded? Instead of every time the = output > method is called? certainly, except that if a template parameter never changes then just = add it directly to the html. =20 > Examples of such life-of-the-template variables might be the language = and > encoding variables used to specify the language being used within that > template? Or, a variable used to pick a navigation side-bar based upon > system-wide parm? (Customized navigation bars for seasonal occasions? = Where > the CGI decides at runtime which one it wants loaded based upon the = time of > year?) umm... both of these examples prove that the template variables are = dynamic - its just that the lifetime is extremely long compared to most = template variables. eg: If a webserver runs for 12 months, then you = would have to use a different value for the seasonal variations. > In my case, all my pages share a common sidebar layout, but different > sidebar choices. I want to nest the set of choices within the common = sidebar > layout and let each page (different CGI::App modules) specify which = set of > choices should be loaded from that common sidebar layout. But, to do = that, > it has to load all of them at compile time and then reevaluate the = decision > for each output of the template. When, it's not going to change for = the life > of that loaded template. "...nest the set of choices within the common sidebar layout..." = precludes "it's not going to change for the life of that loaded = template" which way is it? either you are providing choice or you're not. > It's not the end of the world. But, it seemed like a potential = opportunity > to make H::T a little more efficient by allowing some evaluation = criteria to > be performed at compile time. >=20 > Am I totally off base? although the concept is interesting (eg compile-time evaluation of = template variables), however it appears that you cant see the difference = between static information and dynamic information. Mathew |
From: Mark F. <mar...@ea...> - 2005-01-04 23:24:14
|
From: "Mathew Robertson" <mat...@re...> > >which way is it? either you are providing choice or you're not. I'm sorry. I probably didn't explain the example very well. This example is somewhat a problem of nesting, and somewhat a problem of semi-static values. Let's say I have 20 different top-level pages (represented by 20 CGI::App modules). Each has its own set of sub-areas (pages produced by the module). The side-bar navigation lists the sub-areas a visitor can go to from one top-level page. Therefore, there is one side-bar structure which can have 20 different sets of values (depending on which module is using it). I'd like have a top-level page include the side-bar structure which (here's the important part) contains an include where the filename is partially constructed by a TMPL_VAR. This way, the side-bar structure can be reused across the 20 top-level templates, and each top-level template can specify which list of values should be included in the structure by using a TMPL_VAR. <TMPL_INCLUDE NAME="includes/navigation/area<TMPL_VAR NAME=AREA_NUM>.html"> I can't do that because H::T (for good reason) loads all the includes at compile time and performs variable substition at output time. This is a case where it's not so static that the value can be hard-coded in the included component. But, not so dynamic that all *20* list values need to be hauled into the template and re-evaluated at output time using a gigantic <TMPL_IF> construction. :) I hope that's a clearer explanation. I know I could do one of two things to get around this. 1. I could create 20 side-bar includes and simply include the correct one for the top-level template. The problem (possibly slight) is that I'll duplicate quite a bit of HTML to surround the values with the entire construct. All 20 use the same general construct, it's just the 5-10 list values comprising the actual links that change. 2. I could organize it differently and include a side-bar_top, the specific values, and a side-bar_bottom. That's not the end of the world. But, it starts getting a little ugly when what we're really talking about is nesting and semi-persistent values. 3. I could use a TMPL_LOOP and replace the values from within my CGI::App module. Again, not the end of the world. But, I don't need to re-evaluate with every output of the template. It's semi-persistant data. I can't hard code it. And, it doesn't change after compile time. I have another example (not involving nesting) regarding language support. Let me think that one through and I'll write another email. Thanks for considering this topic, Mark |
From: Mark F. <mar...@ea...> - 2005-01-05 03:04:28
|
Here's another example. To accomodate multiple foreign languages I store my loaded templates in a hash keyed by language code. The loaded template is mostly the same template files with param information filled in specific to the language. My procedure is this: I always check if the template exists in the hash for each display of the page (using the visitor's language preference). If not, I go through my load process which involves "tmpl_load" and a series of Locale::Maketext calls to translate English into whatever language the template needs to be in. Generally, this means using the param method to set the xml:lang, the encoding, the stylesheet (to get the font for non-Roman languages), and a slew of Maketext calls to translate fill in form captions, heading values, etc. Not all the page text dynamically translated like this. Some larger paragraph text may exist in files included into the template from a directory structure representing the language (like /templates/en-US). This gets back to the earlier example of how it's difficult to dynamically select includes. (In this case HTML_TEMPLATE_ROOT would work *if* all my templates (non-language specific) existed in that directory too.) Anyway, this language processing only needs to be done *at the time the template is loaded*. I don't need to do it for each output of the template. I'm keeping my own template objects for each language (in the hash). There are only a few output-time params that need to be re-evaluated at output time (status message, select lists because the selection may have changed, form fields). All the translated text performed when the template was first tmpl-loaded doesn't need to be re-evaluated. This case is a little different than the previous example. In the previous example, I needed substitution to occur at compile time. In this case, I need to specify that the evaluation of the param is *permanent*. If compile-time substitution were available I could setup all my name=value pairs prior to the tmpl-load. But, in my mind I'd rather do the tmpl-load (specifying anything that needs to be done at compile time, like the conditional include mentioned previously) and then have a method to perform one-time, permanent substitution to the loaded template. This way I could issue my numerous Maketext calls after the template is loaded and let the results be stored in the template rather than creating my own temporary holder just to so the values are available at compile time (assuming there could be a feature to perform compile-time evaluation). Does that make sense? Am I completely missing something? Thanks, Mark |
From: Mathew R. <mat...@re...> - 2005-01-05 07:00:30
|
hmm... I'm not sure I can answer how you would go about making H::T do a = compile-time parse, but I can solve your need for <TMPL_INCLUDE = <TMPL_VAR num>>... I use a modified version of H::T which does this (and a number of other = useful things, such as custom TMPL tags). Go to: http://members.optusnet.com.au/mathew/ and download the version of H::T from there. The perldoc explains how = to enable recursive templates. Mathew PS. I am very familar with Locale::Maketext, and I think it is a great = step forward in handling language translation capabilities (compared to = say 'catgets'), however I found it to be limiting in some specific = ways, thus I created Locale::MakePhrase which I believe to be much more = powerful. ----- Original Message -----=20 From: "Mark Fuller" <mar...@ea...> To: "Mathew Robertson" <mat...@re...>; = <htm...@li...> Sent: Wednesday, January 05, 2005 2:03 PM Subject: Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE > Here's another example. >=20 > To accomodate multiple foreign languages I store my loaded templates = in a > hash keyed by language code. The loaded template is mostly the same = template > files with param information filled in specific to the language. My > procedure is this: I always check if the template exists in the hash = for > each display of the page (using the visitor's language preference). If = not, > I go through my load process which involves "tmpl_load" and a series = of > Locale::Maketext calls to translate English into whatever language the > template needs to be in. Generally, this means using the param method = to set > the xml:lang, the encoding, the stylesheet (to get the font for = non-Roman > languages), and a slew of Maketext calls to translate fill in form = captions, > heading values, etc. >=20 > Not all the page text dynamically translated like this. Some larger > paragraph text may exist in files included into the template from a > directory structure representing the language (like = /templates/en-US). This > gets back to the earlier example of how it's difficult to dynamically = select > includes. (In this case HTML_TEMPLATE_ROOT would work *if* all my = templates > (non-language specific) existed in that directory too.) >=20 > Anyway, this language processing only needs to be done *at the time = the > template is loaded*. I don't need to do it for each output of the = template. > I'm keeping my own template objects for each language (in the hash). = There > are only a few output-time params that need to be re-evaluated at = output > time (status message, select lists because the selection may have = changed, > form fields). All the translated text performed when the template was = first > tmpl-loaded doesn't need to be re-evaluated. >=20 > This case is a little different than the previous example. In the = previous > example, I needed substitution to occur at compile time. In this case, = I > need to specify that the evaluation of the param is *permanent*. If > compile-time substitution were available I could setup all my = name=3Dvalue > pairs prior to the tmpl-load. But, in my mind I'd rather do the = tmpl-load > (specifying anything that needs to be done at compile time, like the > conditional include mentioned previously) and then have a method to = perform > one-time, permanent substitution to the loaded template. This way I = could > issue my numerous Maketext calls after the template is loaded and let = the > results be stored in the template rather than creating my own = temporary > holder just to so the values are available at compile time (assuming = there > could be a feature to perform compile-time evaluation). >=20 > Does that make sense? Am I completely missing something? >=20 > Thanks, > Mark >=20 > |
From: Keith J. <kja...@ey...> - 2005-01-05 12:20:41
|
On Wed, 2005-01-05 at 01:58, Mathew Robertson wrote: > hmm... I'm not sure I can answer how you would go about making H::T do a compile-time parse, but I can solve your need for <TMPL_INCLUDE <TMPL_VAR num>>... > > I use a modified version of H::T which does this (and a number of other useful things, such as custom TMPL tags). Go to: > > http://members.optusnet.com.au/mathew/ > Your version has some nice features that I could use, especially the recursive HTML::Template invocation. Is there a reason why Sam has not included your mods into the CPAN version? I'd like to stay consistent and use versions from CPAN for our production servers. Keith |
From: Mark F. <mar...@ea...> - 2005-01-05 17:41:30
|
From: "Keith Jackson" <kja...@ey...> > On Wed, 2005-01-05 at 01:58, Mathew Robertson wrote: > > http://members.optusnet.com.au/mathew/ > > Your version has some nice features that I could use, especially the recursive HTML::Template invocation. Is there a reason why Sam has not included your mods into the CPAN version? > I'd like to stay consistent and use versions from CPAN for our production servers. I agree. Matt's feature to do <TMPL_INCLUDE <TMPL_VAR NAME="VARIABLE_INCLUDE_FILE">> would make H::T easier to use (in the example where I have a side navigation bar used in 20 pages and the only thing different is the list element of links). I'd like to hear what Sam thinks of this. I'd also like to hear what he or others think of my suggestion to be able to perform "permanent" evaluation on a template. I really think this would be useful such as the example where I language translate a template and all that evaluation of the template is permanent for the life of the loaded template. I suppose the one complication is that a cached template is not gauranteed to be present? Doesn't it discard cached templates after a certain cache size is reached? I guess there would need to be a way to test if the template is in cache and, if not, I'd have to re-execute my tmpl_load and all the one-time evaluation. Or, the ability to mark a tmpl_load'ed template as not discardable? Mark |
From: Sam T. <sa...@tr...> - 2005-01-05 18:07:20
|
On Wed, 5 Jan 2005, Keith Jackson wrote: > Your version has some nice features that I could use, especially the > recursive HTML::Template invocation. Is there a reason why Sam has > not included your mods into the CPAN version? The discussion of these changes is available in the mailing-list archive. If memory serves I didn't think that most of them required changes to HTML::Template itself. My feeling is that if HTML::Template::Expr could be done without changes to HTML::Template then there's really no limit on the changes that can be accomplished by a sub-class using filter. Put simply, HTML::Template has suffered from feature-creap through its life and it's nearly at the breaking point now. The current code-base won't remain maintainable with many more features added without a major rearchitecture. Someday maybe I'll do that and then all kinds of extension will be easier... -sam |
From: Keith J. <kja...@ey...> - 2005-01-05 18:41:03
|
OK, I understand. So I guess my question is redirected to Mathew, could you subclass H::T and put your version on CPAN? Thanks! PS. IMHO It doesn't get said enough, H::T is a GREAT module and all the people involved deserve tons of credit! Thanks and have a great New Year. Keith On Wed, 2005-01-05 at 13:07, Sam Tregar wrote: > On Wed, 5 Jan 2005, Keith Jackson wrote: > > > Your version has some nice features that I could use, especially the > > recursive HTML::Template invocation. Is there a reason why Sam has > > not included your mods into the CPAN version? > > The discussion of these changes is available in the mailing-list > archive. If memory serves I didn't think that most of them required > changes to HTML::Template itself. My feeling is that if > HTML::Template::Expr could be done without changes to HTML::Template > then there's really no limit on the changes that can be accomplished > by a sub-class using filter. > > Put simply, HTML::Template has suffered from feature-creap through its > life and it's nearly at the breaking point now. The current code-base > won't remain maintainable with many more features added without a > major rearchitecture. Someday maybe I'll do that and then all kinds > of extension will be easier... > > -sam > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Html-template-users mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/html-template-users -- Keith Jackson <kja...@ey...> |
From: Mark F. <mar...@ea...> - 2005-01-07 18:30:05
|
Matthew, I second Keith's request. Your feature to <tmpl_incl> a variable-substituted filename would be valuable to me. But, I'm not comfortable departing from H::T. Sam, I'm not a big object guy. Subclassing H::T is probably beyond my capability. However, if you think it would be useful to have a "persistent evaluation" of the *cached* template (so that the partially-evaluated template is returned with each subsequent "new" method calls), I hope you'll keep it in mind if/when H::T is enhanced. The only complication I can think of is that the "new" method would have to provide some kind of result indicating that it read the template from disk, not cache (so the caller can reinitialize the cached copy). I can get around this by by caching my own template object. Instead of calling "new" with each display of the page (and relying upon any of H::T's caching mechanisms), I can store the template in $my_template_hash{$visitor_language} (once, when it is found to be undef), perform my one-time language-specific evaluation upon that template, and then use that template for each redisplay of the page. The only problem here is that I have to be aware of anything that might be optionally evaluated. Things that default to a certain display. I have to always evaluate them to be sure they don't have a non-default value when they should be default (that sounds confusing!). Sorry if this is a dumb question, but is there an easy way I could clone the template object in $my_template_hash{$visitor_language}, perform my single display-specific evaluations upon it (without disturbing the original object), and then reclone it for the next display (discarding the earlier clone)? If there is a way, in your opinion would this be more or less efficient than me performing my own re-evaluation of things that otherwise would be default values (i.e., the problem mentioned in the previous paragraph)? Thanks! Mark ----- Original Message ----- From: "Keith Jackson" <kja...@ey...> To: "Sam Tregar" <sa...@tr...> Cc: "Mathew Robertson" <mat...@re...>; "Mark Fuller" <mar...@ea...>; "HTML::Template users" <htm...@li...> Sent: Wednesday, January 05, 2005 11:40 AM Subject: Re: [htmltmpl] RFC: Conditional TMPL_INCLUDE > OK, I understand. So I guess my question is redirected to Mathew, could > you subclass H::T and put your version on CPAN? > > Thanks! > > PS. IMHO It doesn't get said enough, H::T is a GREAT module and all the > people involved deserve tons of credit! Thanks and have a great New > Year. > > Keith > On Wed, 2005-01-05 at 13:07, Sam Tregar wrote: > > On Wed, 5 Jan 2005, Keith Jackson wrote: > > > > > Your version has some nice features that I could use, especially the > > > recursive HTML::Template invocation. Is there a reason why Sam has > > > not included your mods into the CPAN version? > > > > The discussion of these changes is available in the mailing-list > > archive. If memory serves I didn't think that most of them required > > changes to HTML::Template itself. My feeling is that if > > HTML::Template::Expr could be done without changes to HTML::Template > > then there's really no limit on the changes that can be accomplished > > by a sub-class using filter. > > > > Put simply, HTML::Template has suffered from feature-creap through its > > life and it's nearly at the breaking point now. The current code-base > > won't remain maintainable with many more features added without a > > major rearchitecture. Someday maybe I'll do that and then all kinds > > of extension will be easier... > > > > -sam > > > > > > ------------------------------------------------------- > > The SF.Net email is sponsored by: Beat the post-holiday blues > > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > > _______________________________________________ > > Html-template-users mailing list > > Htm...@li... > > https://lists.sourceforge.net/lists/listinfo/html-template-users > -- > Keith Jackson <kja...@ey...> > > > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Html-template-users mailing list > Htm...@li... > https://lists.sourceforge.net/lists/listinfo/html-template-users |
From: Sam T. <sa...@tr...> - 2005-01-07 18:38:18
|
On Fri, 7 Jan 2005, Mark Fuller wrote: > I'm not a big object guy. Subclassing H::T is probably beyond my capability. I doubt that. Give it a try. If you have trouble, post here and I'll be happy to give you a hand. If you have no idea where to start I'd suggest picking up Damian Conway's "Object Oriented Perl". It's a great book. > However, if you think it would be useful to have a "persistent evaluation" > of the *cached* template (so that the partially-evaluated template is > returned with each subsequent "new" method calls), I hope you'll keep it in > mind if/when H::T is enhanced. Why? I still haven't heard a compelling use-case aside from dynamic includes which I think can be handled in better ways. > Sorry if this is a dumb question, but is there an easy way I could clone the > template object in $my_template_hash{$visitor_language}, perform my single > display-specific evaluations upon it (without disturbing the original > object), and then reclone it for the next display (discarding the earlier > clone)? If there is a way, in your opinion would this be more or less > efficient than me performing my own re-evaluation of things that otherwise > would be default values (i.e., the problem mentioned in the previous > paragraph)? Easy? No, I doubt it. I can think of some hard ways... -sam |
From: Mark F. <mar...@ea...> - 2005-01-07 19:03:44
|
From: "Sam Tregar" <sa...@tr...> > On Fri, 7 Jan 2005, Mark Fuller wrote: > > However, if you think it would be useful to have a "persistent evaluation" > > of the *cached* template (so that the partially-evaluated template is > > returned with each subsequent "new" method calls), I hope you'll keep it in > > mind if/when H::T is enhanced. > > Why? I still haven't heard a compelling use-case aside from dynamic > includes which I think can be handled in better ways. Ooops. We're talking about two different things. What I said above concerns evaluation of a template which needs to be performed *only once*. For example: let's say a template's title, headings, field captions, etc., are generated using Locale::Maketext (to get a foreign language). The template is evaluated to get this language-specific text into the template. It wouldn't make sense to have to re-evaluate all this stuff for each re-display of the page (in this language). That's why I said that I "new" the same template (as needed for a language) into a hash keyed by language. This way I have one template for each language. The problem is: each time I "new" it (for each redisplay) I loose all the one-time evaluation performed upon the template. I need these one-time evaluations cached. I can perform my own caching, but then I have to take steps concerning the state of non-one time evaluations and make sure I don't take anything for granted. I can't get a fresh copy of the template as it existed at the time I performed my one-time evaluations. I also have to perform my own test of whether the template changed so I can discard my cached copy. Does that sound like a reasonable usage? Thanks! Mark |
From: Sam T. <sa...@tr...> - 2005-01-07 19:23:10
|
On Fri, 7 Jan 2005, Mark Fuller wrote: > > Why? I still haven't heard a compelling use-case aside from dynamic > > includes which I think can be handled in better ways. > > Ooops. We're talking about two different things. What I said above concerns > evaluation of a template which needs to be performed *only once*. Are you sure it needs to happen "only once"? Your example doesn't support that meaning. In your example the language-specific stuff needs to change when the language changes. It's not as often as the rest of the variables (presumably) but it's surely not just once. For transformations that really need to happen only once I suggest you make them with a text editor! > Does that sound like a reasonable usage? Maybe, but I still don't see why you'd want to do it. HTML::Template is fast enough that it doesn't seem like a worthwhile optimization versus the work it would take to implement. -sam |
From: Mark F. <mar...@ea...> - 2005-01-07 20:28:06
|
From: "Sam Tregar" <sa...@tr...> > Are you sure it needs to happen "only once"? Your example doesn't > support that meaning. In your example the language-specific stuff > needs to change when the language changes. Sam. First, thank you for your consideration. I only load a template for a language once. When I load it I perform all the one-time language-specific value replacements. Otherwise I'd have to keep a language-specific copy of the template in directory structures and "new" the template from the correct structure. I used to do this. But now I prefer keeping all the language specifics in Locale::Maketext and do a one-time replacement of template values which heretofore had been kept in language-specific templates. The psuedo-code looks like this: ============== if (!exists($template_hash{$visitor_language})) { template->new(template-path/name) $maketext_languageHandle_hash{$visitor_language} = Locale::Maketext->get_handle($visitor_language); initialize_language_specific($template-hash{$visitor_language}, $maketext_language_handle_hash{$visitor_language}); } =============== Inside "initialze_language_specific" I do *not* evaluate *everything* in the template. There are some things that are specific to each display of the page. So, that's done with each re-display. Two problems with this mechanism are: 1. I'm effectively caching my own template so I can keep the one-time evaluations across multiple displays. - Now I have to add my own test of whether a template has changed. An unwelcome movement of functionality in H::T into my domain. :) - If I had concerns about how much memory I was consuming and/or how long I keep a little-used template in memory, I have to build this into my logic. 2. My self-cached template's state is exactly as last output'ed. I can't take for granted that default (think TMPL_ELSE) evaluations have their default values. I always have to perform all evaluations (other than the ones I did in the initialize). To me this seems like something that could be useful to all H::T users. It seems like it wouldn't burden H::T to have the option to specify that evaluation be performed on the cached copy of the template? Thanks! Mark |
From: Mark F. <mar...@ea...> - 2005-01-18 17:26:09
|
Sam, earlier I said it would be useful if I could apply some evaluation once. Then operate upon that partially evaluated template. I didn't realize H::T applies everything at output(?). If H::T applies everything at output, wouldn't it be relatively easy to accomplish this if there was a way to tell H::T to perform an "output" *but don't eliminate any H::T tags that are unevaluated*? If I could do this, I could set all my one-time page evaluation and do a "new_scalar_ref->" (using the output from my first "new->" from a file). If there were a way to tell H::T to reload it internally there may be a way to utilize H::T's caching mechanism (instead of me keeping my H::T object in %hash_of_templates{language}). Doing a "new->" would have to tell me it reloaded the template so that I could do the one-time processing again (and output_internal-> to put it back into the state where it's mostely prepared for repeated processing). What do you think? Would it be easy to do by sub-classing? Did you eventually agree there is a legitimate case for one-time page evaluation? (One-time language replacement of title, headings, navigation, etc.) I'd like to apply some heavy replacement and do it only once. Keep the resulting text containing only the tags that are evaluated on a display-by-display basis (messages, etc.). This might have some application for select/option lists too. I won't confuse the issue with that yet. My main concern is just to avoid repetitive numerous replacement of text which is constant for a page. Thanks! Mark |
From: Mathew R. <mat...@re...> - 2005-01-10 22:10:12
|
I respect Sam's opinion on what should and shouldn't go into H::T, = although I wouldn't consider some of the enhancements "feature creep" = (ie I think not having TMPL_ELSIF would mean that a feature is missing) = -> I thank him for producing a very use piece of code. =20 And these enhancements show that H::T can undergo more enhancements = without 'breaking'... some of the features added to this version, are = based on ideas from the people on this list -> they were added without a = major re-architecture, more like a code evolution. That said, the reason that I put together the functionality in my = version of the H::T bundle was that I very-much needed certain = functionality, such as: - TMPL_ELSIF make my templates a lot clearer to read (under some = circumstances) - I absolutely need support for custom TMPL_xxx constructs - I absolutely needed some bug fixes which Sam hasn't fixed As to putting it up on CPAN... what would I call it ? = HTML::TemplateEnhanced ? (note that most of these changes / enhancements cant be made by = subclassing H::T...) Mathew > OK, I understand. So I guess my question is redirected to Mathew, = could > you subclass H::T and put your version on CPAN? >=20 > > > Your version has some nice features that I could use, especially = the > > > recursive HTML::Template invocation. Is there a reason why Sam = has > > > not included your mods into the CPAN version? > >=20 > > The discussion of these changes is available in the mailing-list > > archive. If memory serves I didn't think that most of them required > > changes to HTML::Template itself. My feeling is that if > > HTML::Template::Expr could be done without changes to HTML::Template > > then there's really no limit on the changes that can be accomplished > > by a sub-class using filter. > >=20 > > Put simply, HTML::Template has suffered from feature-creap through = its > > life and it's nearly at the breaking point now. The current = code-base > > won't remain maintainable with many more features added without a > > major rearchitecture. Someday maybe I'll do that and then all kinds > > of extension will be easier... |
From: Sam T. <sa...@tr...> - 2005-01-11 05:18:07
|
On Tue, 11 Jan 2005, Mathew Robertson wrote: > I respect Sam's opinion on what should and shouldn't go into H::T, > although I wouldn't consider some of the enhancements "feature > creep" (ie I think not having TMPL_ELSIF would mean that a feature > is missing) -> I thank him for producing a very use piece of code. Thanks, I appreciate that. I'm certainly not above changing my mind if enough people see a need for a particular feature. I'm definitely thinking about doing something about variable TMPL_INCLUDEs, for example. > And these enhancements show that H::T can undergo more enhancements > without 'breaking'... some of the features added to this version, > are based on ideas from the people on this list -> they were added > without a major re-architecture, more like a code evolution. When I think about the dangers of feature creep I think about global_vars. It's a great feature which I've come to think of as the way HTML::Template should have worked from the beginning. It's also a terrible hack which still doesn't work quite right and clutters the code in a number of places. > - I absolutely needed some bug fixes which Sam hasn't fixed Can you refresh my memory about these? > (note that most of these changes / enhancements cant be made by > subclassing H::T...) Which ones would you consider impossible? I'm sure I could implement TMPL_xxx extensions and TMPL_ELSIF in a sub-class. -sam |
From: Mathew R. <mat...@re...> - 2005-01-11 06:16:50
|
> > although I wouldn't consider some of the enhancements "feature > > creep" (ie I think not having TMPL_ELSIF would mean that a feature > > is missing) -> I thank him for producing a very use piece of code. >=20 > Thanks, I appreciate that. I'm certainly not above changing my mind > if enough people see a need for a particular feature. I'm definitely > thinking about doing something about variable TMPL_INCLUDEs, for > example. ok - thats good to hear... =20 > > And these enhancements show that H::T can undergo more enhancements > > without 'breaking'... some of the features added to this version, > > are based on ideas from the people on this list -> they were added > > without a major re-architecture, more like a code evolution. >=20 > When I think about the dangers of feature creep I think about > global_vars. It's a great feature which I've come to think of as the > way HTML::Template should have worked from the beginning. It's also a > terrible hack which still doesn't work quite right and clutters the > code in a number of places. fair enough - the way I look at it is: if it works, then it will always be a better design that something = which doesn't yet exist... H::T may contain some hacks, but most of the cool stuff in this world, = is a result of good hacks... I consider H::T to be a good hack... :-) > > - I absolutely needed some bug fixes which Sam hasn't fixed >=20 > Can you refresh my memory about these? The main one that needed fixing was that the wrong *fname *fcounter and = *fmax where populated when reaching the end of more than one = TMPL_INCLUDEd file. Starting at line 2300, it reads: # count newlines in chunk and advance line count $fcounter +=3D scalar(@{[$chunk =3D~ m/(\n)/g]}); # if we just crossed the end of an included file # pop off the record and re-alias to the enclosing file's info pop(@fstack), (*fname, *fcounter, *fmax) =3D \ ( = @{$fstack[$#fstack]} ) if ($fcounter > $fmax); where as it should read: # count newlines in chunk and advance line count $fcounter +=3D scalar(@{[$chunk =3D~ m/(\n)/g]}); # if we just crossed the end of an included file # pop off the record and re-alias to the enclosing file's info while ($fcounter > $fmax) { my $counter_offset =3D $fcounter - $fmax; pop(@fstack), (*fname, *fcounter, *fmax) =3D \ ( = @{$fstack[$#fstack]} ); $fcounter +=3D $counter_offset; } Notice here that we pop() the current frame off multiple times, = depending on how many TMPL_INCLUDEs deep were at. I cant remember _why_ I needed it fixed, but I remember being bitten a = few times when I forgot to apply the patch... Another... sub _normalise_options {...} (line 1582) is used to push options into = LOOPs, but doesn't work 100% of the time when used with H::T::E, as the: $template->{options}{expr} $template->{options}{expr_func} values are not pushed into the LOOP. Again I cant remeber why I fixed = it, but it needed doing... Note that this fix implies also pushing = 'expr ' and 'expr_func' onto the _new_from_loop(%hash) (ie where it is = used in the '/TMPL_LOOP' test, line 2067) And for the purests... H::T::E should read (line 236): $self =3D $self->SUPER::output(...); rather than : my $result =3D HTML::Template::output($self, ...); just in case someone is overloading $self->output(). > > (note that most of these changes / enhancements cant be made by > > subclassing H::T...) >=20 > Which ones would you consider impossible? I'm sure I could implement > TMPL_xxx extensions and TMPL_ELSIF in a sub-class. granted, if you can sub-class to create TMPL_xxx, you can quite easily = create TMPL_ELSIF... but TMPL_ELSIF is such a nice thing to have as = part of the standard H::T.... As for custom TMPL_xxx, I dont see how you can simply subclass '_parse' = to detect your custom tag, without impacting quite a large performance = hit. The simplest solution is to have H::T's big honking regex, = capture TMPL_xxx directly; then if the user has the 'use_custom_tag' = enabled in the options, call into the sub-class via a virtual function. cheers, Mathew PS: As for custom TMPL_VAR ESCAPE support (which I didn't mention = before), I simply moved the package definitions into their own files so = that H::T can dynamically load them. This allows me to have as many = useful/useless ESCAPE types that I care for, just by sub-classing from = H::T::ESCAPE, ie, I can do the following: some html...<TMPL_VAR NAME=3D"data" ESCAPE=3D"MyCustomEscapeRoutine"> Where "MyCustomEscapeRoutine" gets auto-loaded by H::T... |
From: Sam T. <sa...@tr...> - 2005-01-05 18:02:50
|
On Tue, 4 Jan 2005, Mark Fuller wrote: > I just had a need to conditionally include one of a few templates dependnig > on the value of a TMPL_VAR. One of the includes (which would not have been > loaded) did not exist, but H::T died because it couldn't locate that file. I > realized H::T probably loads everything at compile time and applies the > conditions at the time the output method is called. And just to explain why this was done in the first place, HTML::Template allows includes to be syntactically invalid. For example, this is valid: <tmpl_loop foo> <tmpl_var bar> <tmpl_include foo_end.tmpl> And foo_end.tmpl: </tmpl_loop> Obviously there's no way to parse this without doing the include at compile-time. Now, maybe this was a mistake. I've considered breaking this support in my fantasy version 3 rewrite. But at least for v2 it has to stay. > However, I still feel like I have a need to conditionally load included > templates and I know which ones they are at compile time. It's not going to > change over repeated outputs called on the same cached template. I'm faced > with either structuring the template includes differently (making it uglier > and some duplicated HTML). Or, let it load all the stuff I know I don't need > at compile time and use a TMPL_VAR (the same value for the life of the > template) to tell the output method which included fragment to output. I've thought about allowing something like: $t = HTML::Template->new(filename => 'foo.tmpl', includes => { bar => 'bar.tmpl' }); And in foo.tmpl: <tmpl_include name="bar"> This would have to be factored into the cache-signature, but since that's now centralized in a single place in the code that should be easy enough. Actually, it occurs to me that this would be pretty easy to do with filter in a sub-class. So you don't even have to wait for me! > Question: Does this lead to the idea that it would be useful to have > variables used only at compile time? When I tell it to load a > template, why can't I give it variable name=value pairs to apply > *only* at compile time? Aside from doing variable includes, is there any other reason to want this? I doubt it would be much more efficient in the general case for just a few variables. Compared to the difficulty of coding it in the current code-base it doesn't seem worthwhile. -sam |