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
-
Kake L Pugh -
Nick Burch -
Robert Barta