[dokuwiki] Re: syntax plugin question wrt handle() vs render()

  • From: Christopher Smith <chris@xxxxxxxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Mon, 10 Mar 2008 02:53:50 +0000





the idea was for the handle() function to create an associative array of [key#] => [value#] and then have that be passed to render(), but it would
seem like that's not possible ?  i would have to maintain state across
MATCHED/UNMATCHED calls ... is that what the &$handler parameter is for ?

No, not really.

The handler translates raw wiki text into a series of render instructions - the return values from the handler. Those instructions are cached and can be sent to the renderer at any time. Quite possibly at times when the handler has not been run. Also they aren't only used by the xthml renderer, but by the metadata renderer and any other renderers (e.g. S5 plugin).

The "EntryPattern ... AddPattern(s) ... Exit Pattern" sequence is aimed at syntax modes which need to support other syntax modes nested with them. e.g. A table which allows bold text or links within the table cells.

If no other output is possible between <register> and </register> you should use a addSpecialPattern and process the whole lot as a single renderer instruction. Taking into account caching and attempting to reduce the page generation overhead as much as possible, your render instruction could be your associative array or the handler phase could generate and cache the image and your render instruction could be sufficient information to generate an img element in the xhtml (or similar in any other renderer format you support).

To get a sense of what I mean, take a look at any of the ".i" files in cache directories.

If you were to stick with the current set of patterns, you could still build up the associative array in the handler, effectively returning render instructions that do nothing for each(*). When the ExitPattern is processed you would return the whole array(**).

- Chris

(*) I reckon there is a case for a plugin to be able to return a special value to the handler that tells it not to create an instruction for that particular pattern.

(**) You can then access the handler and its call rewriter to trawl through the call stack and remove all the redundant render instructions created for the earlier patterns.


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

Other related posts: