Hi folks, I am just looking at Wiki::Toolkit and it's plugin infrastructure. I read in http://search.cpan.org/dist/Wiki-Toolkit/lib/Wiki/Toolkit/Plugin.pm that pre_retrieve does not allow declining of the read. It is marked as TODO. Is there a principle problem with it? or could it be added, just as for instance in sub write_node_post_locking { .... foreach my $plugin (@preplugins) { if ( $plugin->can( "pre_write" ) ) { handle_pre_plugin_ret( \$write_allowed, $plugin->pre_write( node => \$node, content => \$content, metadata => \$metadata_ref ) ); } } if($write_allowed < 1) { # The plugins didn't want to allow this action return -1; } ?? \rho
On Sat, 1 Sep 2007, Robert Barta wrote:
that pre_retrieve does not allow declining of the read. It is marked as TODO.
Is there a principle problem with it? or could it be added, just as for instance in
I think we just never figure out the best way for a call to retrieve_node to indicate the retrieve was denied. write_node_post_locking was easy, because it already returned 0 or 1, so adding -1 wasn't hard. retrieve_node either returns a hash or undef, so what to return for declined isn't immediately obvious. If someone can suggest what to return, then it's just a case of adding in the plugin return code checking, writing a test, and tweaking the documentation for retrieve_node :) Nick
On Sun, Sep 02, 2007 at 12:35:49PM +0100, Nick Burch wrote:
On Sat, 1 Sep 2007, Robert Barta wrote:
that pre_retrieve does not allow declining of the read. It is marked as TODO.
Is there a principle problem with it? or could it be added, just as for instance in
If someone can suggest what to return, then it's just a case of adding in the plugin return code checking, writing a test, and tweaking the documentation for retrieve_node :)
What about the following principle: - Every plugin (actually the methods in there) acts as a filter. Content towards the backend is filtered, content from the backend is filtered. (This is pretty much how I think it works now.) - If a plugin does not want progress, it raises an exception. - The precedence of plugins must be controllable, say ->plugin_a_before_b (a => $plugin1, b => $plugin2); Would this break things horribly? \rho
On Tue 04 Sep 2007, Robert Barta <rho@devc.at> wrote:
What about the following principle: [...] Would this break things horribly?
All the plugin stuff has fallen out of my head, so I can't comment intelligently on this. Does it make sense to people who've looked at the code more recently? Kake
participants (3)
-
Kake L Pugh -
Nick Burch -
Robert Barta