I can't think of any good usage examples at the moment, but it does
make sense to have a hook for filtering text to be rendered for
display. While this would be implemented as an action event, I think it
makes more sense to treat it as a hook for filters. This way there is
no default action to prevent. If we are going to add a pre-parse filter
it would be logical to also add a post-render filter that takes the
rendered output (pre-caching) and the name of the generating renderer.
How about the these event names: PARSER_TEXT_PREPROCESS (or PARSER_WIKITEXT_PREPROCESS) and RENDERER_CONTENT_POSTPROCESS
On Jul 20, 2006, at 7:00 PM, Chris Smith wrote:
Hi,
In order to fix a problem with the line break plugin[1] I need to ensure a space occurs between text and line endings in the preparsed wiki data. I can do this by using the new IO_WIKIPAGE_READ event[2] but that means I am modifying the data when its being read for other purposes besides parsing for display.
I think there is probably enough separation between the two uses to warrant an event which can supply preprocessing of raw wiki data along these lines[3] as it will also catch any inline uses of the parser.
event: PARSER_TEXT_PARSE (or perhaps PARSER_TEXT_GETINSTRUCTIONS) data: raw wiki text action: parse the text and generate the instructions list preventable: ? probably signalled: p_get_instructions result: instruction list
Any comments?
Cheers,
Chris
[1] to avoid messing up double new lines the plugin can't grab a new line when its the first character being processed - which also occurs when dokuwiki syntax occurs immediately prior to a line break.
[2] great addition Ben.
[3] the recent <IF***> discussion could also make use of access to the data immediately before it is parsed to strip out any content that shouldn't be included.
Regards, Ben Coburn
------------------- silicodon.net -------------------
-- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist
