I have a (large) patch to Template::Provider. But, need help
answering a few questions about Provider's expected behavior
in a few small areas.
I started out a day or so ago where I wanted to override Provider so
that a template would be first fetched from the database, and if not
found would then fetch from disk. And once found on disk it would be
stored in the database automatically. Easy enough.
There were some changes in the 2.15's Provider to help with this --
namely the addition of the $self->_modified() method. That would
allow overriding _load() and _modified() to supply the template and
its modified time.
Unfortunately, not all the stat()s were updated to use _modified().
Also, I didn't really want to override _load, but just the part of
_load the fetches from the file system. Plus, overriding _load()
didn't work for INSERTs.
So, I added a few more methods, including _template_mtime() and
_fetch_content() and also reduced a bit of code duplication. Most of
the changes are to _load(), _fetch(), and _fetch_path().
Perhaps these changes could be useful to others.
Here's the updated version:
http://hank.org/Provider.pm
And diff against cvs:
http://hank.org/Provider.diff
(although it includes a bunch of white space changes, too).
So, for the list, I have a few questions about how the Provider is
suppose to work. They are minor issues, but ones I'm not clear on.
1) The new code fails a test in t/compile2.t. That test modifies the
compiled .ttc file directly and then makes sure TT uses that modified
file.
My version tests if the mtime of the source .tt and compiled .ttc
files are *the same*, but the existing code just makes sure that the
.ttc file is the same or *newer*. That seems wrong because if one
reverts a source template to a previous version (with an older date)
then TT will continue to use the (newer but out-of-date ;) version in
the disk cache.
I'm confused, because t/compile2.t specifically tests for that
behavior, so I must not be understanding the reasoning.
2) When a source template is first fetched it is parsed to Perl code
and saved to disk (assuming COMPILE_DIR or COMPILE_EXT is set) and is
also compiled and saved to memory if CACHE_SIZE != 0.
If the source template changes relative to the version in memory then
the Provider will load the template re-parse it, but in this case it
doesn't save the code to the disk cache.
Not a huge deal because the template will get cached to disk as soon
as a fresh process starts (when the memory cache is empty).
Should the logic be that the whenever a template is parsed that
it is saved to disk so that the disk cache stays current?
3) Should store() be a NOOP if CACHE_SIZE == 0?
store() and the private method _store() save the compiled template in
the memory cache.
=head2 store($name, $template)
Stores the compiled template, $template, in the cache under the name,
$name. Susbequent calls to fetch($name) will return this template in
preference to any disk-based file.
That's a public method but the Provider currently only calls store() or
_store() if the cache is not disabled (with setting CACHE_SIZE = 0).
Should _store() (and thus store() ) respect the CACHE_SIZE setting?
Or should store() be available even if CACHE_SIZE == 0?
Thanks,
--
Bill Moseley
[EMAIL PROTECTED]
_______________________________________________
templates mailing list
[email protected]
http://lists.template-toolkit.org/mailman/listinfo/templates
