[dokuwiki] Re: Plugin writing questions / recursive parser

Interesting requirement that opens a can of worms.

Actually have a similar requirement - been meaning to get round to
using Dokuwiki as a tool for commentable API docs (see:
http://wiki.splitbrain.org/wiki:discussion:integrationwithapidoctool).
A particular issue is I want to be able to keep the generated text in
a document uneditable while allowing comments to be interspersed with
the generated text. There's various simple ways to do this, all of
which have the risk that people lose their comments next time the docs
are generated. Ideal would be being able to lock pages of the page
from editing then be able to replace those sections with the next
generation.

Anyway - as I see it it's a can of worms for two reasons;

First you've introduced imperative syntax where everything else is
declarative. That's a step in the direction of making Dokuwiki syntax
a programming language. Similar issues arise when it comes to template
languages. Some interesting reads;

http://www.phpwact.org/pattern/template_view
http://www.myxaml.com/wiki/ow.asp?DeclarativeVsImperativeProgramming

My view would be avoid imperative syntax at all costs as it's going to
be road to future nightmares. An alternative might be to have a syntax
for calling a PHP function in wiki syntax e.g.;

<filter:auth.check_user_permission "joe">
Here comes some text...
</filter:auth.check_user_permission>

Which might correspond to a PHP class and method like

class Auth extends Filter {
    function check_user_permission($username) {
        // Check user perms - return TRUE if allowed to see this
    }
}

The second issue as Chris mentions is you're raising the issue of "run
time" vs. "compile time" operations. Right now a wiki page might be
parsed and cached at a different time to the when the user "joe"
requests it - the "compile time" happens seperately from the "run
time". Probably best to keep things this way for performance reasons.
At the same time, per-request, you'd need need things happening at
"run time" - further checks on what gets displayed.

Given the current code I'd guess the best place to handle that would
be the page renderer, which is effectively already the "run time" for
a wiki page. Some careful thought would be needed e.g. view source and
page editing would then also need to pass through the renderer. To an
extent what Dokuwiki does with "sections" might also work for this
requirement when editing.

The example above is suggestive - if some kind of "filter api" was
defined, similar to the plugin API, it might allow Dokuwiki to support
different modes of runtime operation. Fleshing out the above example a
bit more, the Auth class have a property "type" like;

class Auth extends Filter {
    var $type = 'conditional';
    function check_user_permission($username) {
        // Check user perms - return TRUE if allowed to see this
    }
}

Dokuwiki checks the type of the filter and understands it needs to be
careful when displaying pages for editing etc.

The caution here though - the more that happens at "run time", the
slower it gets... As Chris points out, perhaps Dokuwiki is the wrong
tool for this.
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org/wiki:mailinglist

Other related posts: