[dokuwiki] Re: Specifying page template for new pages in URL

Jason Grout wrote:


Okay, it's done.
There's a newpagetemplate action plugin that will look for the "newpagetemplate" parameter in $_REQUEST. If the parameter exists, then the page is loaded as a template, with the substitutions currently offered by the namespace templates. Note that this overrides the namespace template.
I have a quick question about my implementation. In the following, a BEFORE callback is an event handler registered with the BEFORE advisement (sp?), and similarly for an AFTER callback. I implemented the plugin as a BEFORE callback, then manually set the $event->result variable and called $event->preventDefault(). Is that all right to do in a BEFORE callback? The documentation seems to indicate that you should only mess with $event->result in an AFTER callback. However, I'd just as soon not go through the expense of loading the default namespace template if I know I'm overriding it. I suppose I could make two callbacks, one BEFORE and one AFTER, with the BEFORE callback checking the $_REQUEST variable and preventing the default, while the AFTER callback actually loads the page, but that seems wasteful as well.
I've also patched the addnewpage plugin to take advantage of the newpagetemplate functionality. The new syntax is: 

{{NEWPAGE>ns|:newpage:template}}
where the new page template follows the vertical bar. I posted the patch up to the addnewpage plugin discussion area. 

Thanks again for everyone's help!

Jason


There aren't so many rules in how you do things in a plugin.
The method you have chosen seems sensible. If a plugin needs to modify an existing result it should handle the "AFTER" event - in so much as there is a result, it is guaranteed to exist. If a plugin provides a result "instead of" the DW result it really should do that using the "BEFORE" advise and call preventDefault(), that way you are maintaining the model that "AFTER" handlers will see the result. You're doing that. :-)
If this isn't clear in the documentation, please feel free to enhance it ;-) 

Cheers,

Chris
PS. I think the above may be the argument I missed for the original three advise system. 

before event - prepares the data
event - creates a result
after event - modifes a result
Under our present system, where order isn't guaranteed, one before handler that prepares the data may be called after a different handler that sets a result. 

Any one for a change :D



--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: