Hi again,

Find attached a simple implementation of the plugin loader using a subset of
Zend Framework's api.

Check ZF docs [1]  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() );

[1] http://framework.zend.com/manual/en/zend.loader.pluginloader.html


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

<<attachment: PluginLoader.php>>

PHPTAL mailing list

Reply via email to