[dokuwiki] Re: event proposal : parser_text_parse

  • From: Chris Smith <chris@xxxxxxxxxxxxx>
  • To: dokuwiki@xxxxxxxxxxxxx
  • Date: Sat, 22 Jul 2006 10:47:27 +0100

Andreas Gohr wrote: 

On Fri, 21 Jul 2006 10:51:36 -0700
Ben Coburn <btcoburn@xxxxxxxxxxxxx> wrote:

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_WIKITEXT_PREPROCESS
and
RENDERER_CONTENT_POSTPROCESS

I like those eventnames. Keep in mind that the renderer is mode specific
(xhtml, meta, ...) so the eventhandler needs to get info about this.
I am not so sure these can't be structured as preventable actions. The cost in terms of processing is minor but the restriction is significant.

PARSER_WIKITEXT_GENERATEINSTRUCTIONS

before event acts as preprocess
after event acts as an instruction list modifier

conceivably this allows an action plugin to replace the handler

PARSER_CONTENT_RENDER

similarly, an after event acts as post process.

I don't particularly think anyone will write an action plugin to prevent these actions, however I reckon we're better off not removing that possibility.

I'd also make this point about the two IO_* events. If they were preventable an action plugin could be written to store content in a different way, e.g. an sql database.

Cheers,

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

Other related posts:

  1. Home
  2. dokuwiki
  3. Archive
  4. 07-2006