Hi again, Find attached a simple implementation of the plugin loader using a subset of Zend Framework's api.
Check ZF docs  for documentation, it should behave the same way. The use with PHPTAL might be something like this: // 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'); // or, setup PHPTAL with our custom loader $tpl->setFilterLoader( new Zend_Loader_PluginLoader() );  http://framework.zend.com/manual/en/zend.loader.pluginloader.html regards, /imv On Wed, Sep 16, 2009 at 12:23 PM, Iván -DrSlump- Montes < drsl...@pollinimini.net> wrote: > 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. > > 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 ... > > It will also be nice, for me at lease, is that the plugin loader uses a > subset of Zend_Loader_PluginLoader api, so that users of ZF can inject the > zend loader version in PHPTAL. > > I'll come up with a working prototype of the loader, so you can use it if > you see fit. > > /imv > > 2009/9/16 Kornel Lesiński <kor...@aardvarkmedia.co.uk> > > On 16-09-2009 at 10:20:59 Iván -DrSlump- Montes <drsl...@pollinimini.net> >> wrote: >> >> The API looks ok to me, just one thing, since it's not a runtime >>> operation (in the sense that a php file is generated for the template), I >>> think it'll be great if it used something along the lines of >>> Zend_Loader_PluginLoader. >>> >>> Which basically when setup with paths and class prefixes is able to find >>> "plugins" in several folders. This would allow to have a set of default >>> filters in PHPTAL distribution but override them and create new ones >>> easily just by placing the class files in a directory, not needing to >>> register them manually at runtime, which once the template is compiled, is >>> of no use. >>> >>> So -- phptal:filter="remove_whitespace" -- would automatically try to >>> include and instantiate a class for that filter. >>> >>> While -- PHPTAL->addPreFilter("remove_whitespace") -- would just store >>> the name for when compiling the template and instantiate the class then. >>> >> >> That's great idea. >> >> Do you think I could get away with reliance on autoload or include_path, >> instead of implementing PluginLoader? >> >> (e.g. if (!class_exists($name."PreFilter")) include >> $name."PreFilter.php";) >> >> Regarding the tutorials, creating documentation is always hard, specially >>> for OSS projects, perhaps we could use a simple wiki to collect >>> information (there is quite a bit of information scattered around, mainly >>> from Zope's >>> implemenation). >>> By the way, DokuWiki is a great wiki for this kind of tasks. >>> >> >> Ok, I'll install it. >> >> -- >> regards, Kornel >> >> >> _______________________________________________ >> PHPTAL mailing list >> PHPTAL@lists.motion-twin.com >> http://lists.motion-twin.com/mailman/listinfo/phptal >> > >
_______________________________________________ PHPTAL mailing list PHPTAL@lists.motion-twin.com http://lists.motion-twin.com/mailman/listinfo/phptal