On 16-09-2009 at 16:30:35 Iván Montes <drsl...@pollinimini.net> wrote:
And overriding of implementations wouldn't be easy with template
caching. Without loading of filters, I wouldn't know which ones were
overridden since template was cached, and of course loading of
prefilters every time is the thing we want to avoid.
I'm not too fond in how the caching works so I might be completely wrong
here. Why are prefilters needed to compute the caching logic? As I
understand it, the filters are run at compile time not at run/rendering
Whenever prefilters change, template has to be recompiled (or rather
different cache copy needs to be used), otherwise change won't make any
For example if your regular code compiles template with prefilter, and
then you'll change prefilter implementation in unit test, unit test will
still use copy cached by regular code.
That's the whole point of using the loader pattern. Instead of manually
overriding the filter in the code, the loader would allow to use
different "whitespace removers" filters based on the instantiated
loader. So I can use a dummy filter for development (no whitespace
removed) and a very aggressive one in production.
For just one filter the benefits are not clear but once you start adding
filters I think they become obvious.
In case of code it isn't that hard:
If ($production) $phptal->addPreFilter('whitespace');
but I see usefulness of this for <div phptal:filter="whitespace">, as this
couldn't be easily done conditionally.
While I agree that encouraging the change of standard functionality is
not a good idea at all, as an application developer I would like to have
the possibility to do it, if I absolutely need to, in a clean way.
When do you need to and how?
I'm aware that phptal:cache needs to be configurable, but that's rather
exceptional. I don't see why anybody would override tal:content attribute,
not: modifier and such.
PHPTAL mailing list