[dokuwiki] Re: Line-break preservation in Wiki text
- From: Christopher Smith <chris@xxxxxxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Sun, 24 Feb 2008 03:22:07 +0000
On 23 Feb 2008, at 09:50, Andreas Gohr wrote:
(3) Add a hook into the xhtml renderer to allow the behaviour of
"cdata" method to be modified.
That one is more interesting, as it would allow to replace the cdata
function completely. But I'm not sure how to implement that without
having to fire lots of events like in (2).
I envisage a single event during renderer setup which would request
filters for unmatched data. The result would be an array of callbacks
applied one after the other to unmatched data. Effectively making
cdata() something like
function cdata($text) {
for ($this->filter_list as $filter) {
$text = call_user_func($filter, $text);
}
$this->doc = $text;
}
Normally there would only be one function in the filter list, $this-
>_xmlEntities(). Heavier than it used to be, but not too bad.
(4) Add a config setting to select the xhtml renderer in much the
same way as auth backends or templates are selected.
That one is very interesting. It would mean to create new renderer
class which inherits from the standard xhtml renderer replacing or
extending its standard methods. This would be easy to implement using
renderer plugins and a mechanism to define one renderer as the default
renderer. The overhead would be minimal and we would have much added
flexibility. But you only could use *one* of those plugins using this
method. I still like this approach as it could make a lot of sense for
plugins like the Creole one.
I would do this in a similar manner to the way both templates and auth
backends are handled. The Config manager provides a list of
alternatives and the wiki admin chooses the one they want to use.
Right now the renderer class name is based on the renderer format
(e.g. xhtml -> Doku_Renderer_xhtml). It would be necessary to add
another level of separation, e.g. $renderer_class = 'Doku_Renderer_'.
$renderer_lookup['xhtml'];
I'm not 100% sure but I think there might be another alternative:
(5) postpone this to the next release and switch to PHP5 only then.
This makes the Reflection API available which might give us an easy
way
to replace methods in classes without the need for any complicated
hook
system or the use of inheritance. I haven't really digged into what is
possible through reflection so this might not work out as I imagine
it.
I'm not clued up on the reflection api but I thought it was for
introspection rather than modification (which is handled by runkit) I
am not sure mixing plugins with method modification would be a good
idea. Plugins would be competing for a single resource rather than
all operating on the same data.
-- Chris
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist
Other related posts:
