Learn about DokuWiki
Learn about DokuWiki
The current renderer has the problem that there can always be only one renderer, i.e. if a plugin wants to change the output of a certain syntax it either needs to replace the syntax or be a renderer plugin but no two renderer plugins can be active at the same time. For adding (additional) metadata for core syntax elements the same problem exists, the metadata renderer can't be replaced at all but plugins can scan the instructions themselves (but are then missing plugins that are dynamically adding additional instructions).
There could be a list of handlers for each renderer function. During the renderer setup plugins would have the possibility to modify this list, i.e. to add or remove handlers. Handlers of a certain instruction would be called like current syntax plugin with the renderer object (see below) as first parameter. The list of renderers would be automatically populated with the current renderer functions. A plugin could choose to be added to every renderer (e.g. because it just modifies some content or some parameters) or just to be added to certain renderers.
Additionally, a new type of objects could be introduced: doc writers. Similar to call writers in the parsing process they would collect the renderer output. This would allow syntax plugins to post-process the output of other renderer functions without having to mess around with the doc string.
It should also be possible for renderer functions to modify the parameters that are passed to other renderer functions and renderer functions should have priorities.
The renderer functions are already called by their name as string, I don't think that adding a lookup in a two-dimensional array (first dimension instruction name, second handler list) where the second array is usually very small (or could also be replaced by the string itself) will have a large impact but this should of course be tested.
The current renderer class could be replaced by a compatibility wrapper that uses
__call for calling the handlers for all instructions. If this is too slow every instruction could be implemented with an explicit function that calls the registered handlers for this instruction. The doc writers could also be accessed using the
__set-functions for the current
doc variable. The renderer object would also store the various meta information (and the metadata in the case of the metadata renderer).
Existing renderer plugins could still work as they currently do.