> 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?
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. > 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. > > 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 ------------------------------------------------------- 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 Html-template-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/html-template-users
