On 9/16/09 4:56 PM, Kornel Lesiński wrote:
On 16-09-2009 at 14:45:39 Iván -DrSlump- Montes <drsl...@pollinimini.net> wrote:

// Get the standard instance of the loader
$loader = $tpl->getFilterLoader();
// and add a new location for filters
$loader->addPrefixPath('My_Filter', '/path/to/my/filter');

I'm afraid it doesn't save much work compared to setting prefilter objects directly - you still have to load, instantiate and set a class, just a different one this time.

Correct but the point is that it separates concerns among different classes. PHPTAL is the coordinator while FilterLoader takes care of loading filters. This way I could easily change the filters used when running unit tests for example. Besides, it improves code re-use in my opinion, I can have filters which are used among all the company's projects and specific filters for my project.
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.
// or, setup PHPTAL with our custom loader
$tpl->setFilterLoader( new Zend_Loader_PluginLoader() );

I probably could support optional use of Zend's loader. That would require little code on PHPTAL's side.

I wouldn't recommend it, it'll add another dependency (although optional) to PHPTAL which was I was trying to avoid in the first place.
Using only the autoloader/include_path might be a little limiting in my
opinion. It would make it harder to replace a "standard" filter class for example.

Why would you want to do that?

I am planning to ship some standard prefilters with PHPTAL (like removal of whitespace or comments), but if someone doesn't want them, why wouldn't he simply use addPreFilter("my_better_whitespace_remover")?

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.
Besides, implementing a simplified "plugin loader" wouldn't be that
difficult and it would allow to use it in other parts of PHPTal in the
future, for example, to override the default implementation of standard
namespaces, tales modifiers ...

Standard namespaces and modifiers have clearly defined behavior. I'd rather not let users override that, as this could let them create standard-looking templates that don't work as documented. It also makes it harder for PHPTAL to optimize code generation.

It would however be nice to ease adding of your own namespaces and modifiers.

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. Instead of hacking PHPTAL to add my custom code I could have a clean interface to add my own logic, and only me would be responsible for that. Of course I'll need then to double check my changes when I want to upgrade the PHPTAL version but I will not have avoided a branched version of the library.

Finally, I'm not implying that this is the only possible way to implement this. It's just a common pattern used in other projects which works quite well when having a few dependencies (filters in this case) and also when having a lot of them.


PHPTAL mailing list

Reply via email to