On 9/16/09 4:56 PM, Kornel Lesiński wrote:
On 16-09-2009 at 14:45:39 Iván -DrSlump- Montes
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.
// Get the standard instance of the loader
$loader = $tpl->getFilterLoader();
// and add a new location for filters
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.
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
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.
// 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.
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.
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")?
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.
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
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