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 time.

Whenever prefilters change, template has to be recompiled (or rather different cache copy needs to be used), otherwise change won't make any effect.

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.

regards, Kornel

PHPTAL mailing list

Reply via email to