[dokuwiki] Re: Line-break preservation in Wiki text


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: