At 03:09 AM 2/18/2004, Chris Ochs wrote:
Knowing what I know now, I probably should be setting the include path to
the catalog directory itself (plus the templates directory) on each request,
so that
the file I hand to TT to process would be just 'index.html', and would work
for either the catalog directory or the templates directory.

That's exactly what I'm doing for a similar situation, but now I want to take it a step further: I want to take advantage of mod_perl's object persistence and cache the compiled templates in memory. Unfortunately, the INCLUDE_PATH is defined when the Template::Service object is first instantiated. Using Chris's catalog example, that means that if I set the path to something like "catalog1:templates" on the first access of catalog1, then when someone tries to access catalog2, the path will still point to catalog1.


"But wait," you say, " the INCLUDE_PATH can be generated dynamically from a subroutine or generator object each time a template is to be fetched." "Brilliant," I say, except that my subroutine/generator has no way of knowing the current "context", since that information isn't available to the Provider class. And it's the current context which can tell me which catalog was requested.

What I really need is for the Context object to pass a reference to itself when it calls $provider->fetch(), so the provider can utilize path information in the context to generate include paths, either on its own or by passing the context on to the aforementioned subroutine/generator. Subclassing Template::Provider to do this isn't a big deal: override fetch() to collect the context param, store it in the current object instance, and call SUPER::fetch(); and override paths() (reproducing 30-some lines of code) to pass the context when eval-ing a code ref or calling the paths() method of a generator object. But the headache comes in subclassing Template::Context: I'd have to override the template() method and reproduce all 90-some lines of code in order to pass the context when calling $provider->fetch(). That means I'll have to keep track of and duplicate any modifications to that method in future releases. Is there any chance this could be patched in a future version? (It's interesting to note that the calls to fetch() for both plugins and filters already pass along the context...why not for templates, too?)

Of course, I could be missing something really obvious here. Anyone?

Jason Gottshall
[EMAIL PROTECTED]


_______________________________________________ templates mailing list [EMAIL PROTECTED] http://lists.template-toolkit.org/mailman/listinfo/templates

Reply via email to