On 9/16/09 6:03 PM, Kornel Lesiński wrote:
On 16-09-2009 at 16:30:35 Iván Montes <drsl...@pollinimini.net> wrote:

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.

Right, however I think that it's something the developer should be aware of and handle herself. Filters are going to change on the development environment so the developer should either disable caching alltogether in that environment or flush it when she changes a filter.

Besides, couldn't the loader configuration be added to the cache hashing algorithm, that would solve the problem. Although, in my opinion, the developer should invalidate the cache manually or disable it if she changes the filters.
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.

The first thing that pops to mind is to create a proxy around the standard handler to do rather trivial tasks like logging, profiling or change the damn long "structure" modifier for something shorter :)

However I don't have an strong use case now and honestly I can't easily think of one, it's obvious however that there are many hardcoded dependencies between PHPTAL and its standard "handlers" which could be replaced with just one dependency with the loader. It just feels better at the design level.


regards,
/imv

_______________________________________________
PHPTAL mailing list
PHPTAL@lists.motion-twin.com
http://lists.motion-twin.com/mailman/listinfo/phptal

Reply via email to