[dokuwiki] Re: event proposal : parser_text_parse
- From: Ben Coburn <btcoburn@xxxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Sat, 22 Jul 2006 16:34:11 -0700
On Jul 22, 2006, at 2:47 AM, Chris Smith wrote:
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
IMHO, the after event is redundant with PARSER_HANDLER_DONE.
conceivably this allows an action plugin to replace the handler
This could be useful in cases where the current handler mangles or
omits contextual information from the instruction list. Only one plugin
could replace the handler, so plugins that relied on this would be
completely incompatible(!). I think writing plugins that modify the
instruction list, and updating the handler code (as needed) to provide
more useful instructions is a better way to go.
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.
I also thought about this while writing them.... Currently there is a
lot of refactoring that would need to be done to make plugable IO work.
Most of the 'file_exists' and 'filemtime' calls would have to be
replaced with an io_* function and IO_* event that could be overridden.
To make an SQL back-end reasonably efficient I suspect the 'filemtime'
wrapper would have to intelligently cache the results, and aggregate
requests to avoid many small SQL queries. To aggregate 'filemtime'
requests DokuWiki would probably have to make a speculative 'filemtime'
request early in processing based on the request parameters. I agree
that it would be elegant to have fully plugable IO, however it was more
work than I wanted to do at the time and designing it so that plugins
can operate efficiently can become complicated very quickly.
Regards, Ben Coburn
-------------------
silicodon.net
-------------------
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
