Re: smarty recompiling with op-code accelerators

--- Monte Ohrt <[email protected]> wrote:
> This would be remedied if Smarty's compiled files did not retain the 
> mtime of the originating template file, but  that introduces a
> problem when someone dumps templates onto a production server (from
an 
> RPM or tarball) which wouldn't necessarily have a newer timestamp,
> ending up with spurratic recompile results.
> 
> Any thoughts on handling any of this a bit more gracefully? ;)
> 
> Maybe some more documentation details are in order as well.

This is a good point, but shouldn't operational issues be left to the
administrator? Perhaps a custom admin class example can be included in
the docs, but anything more seems to run outside of Smarty's domain,
IMHO. In my custom Smarty class, for example, I have it track the
version of the files in the cache/compiled directories by writing a
version file and comparing it to the running version of Smarty. It will
clear the directory on a mismatch (and then rewrite the version file).
Now that you have pointed this out, I am about to extend it to also
check to see if MMCache is loaded, and if so, to tell MMCache to flush.
Best of all, it is switchable so that it doesn't do this check all the
time--just when I update Smarty. It is simple, easy to implement and
eases the admin's chores--but I, for one, still see it as an admin
chore.

xo boots

-- 
Smarty Development Mailing List (http://smarty.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php