[dokuwiki] Re: plugin output information after $match
- From: "Martin Tschofen" <martin.tschofen@xxxxxxxxx>
- To: dokuwiki@xxxxxxxxxxxxx
- Date: Wed, 27 Dec 2006 23:24:12 -0600
I think I get it. But just to make sure, here's what I'm trying to
accomplish. Simplified:
addEntryPattern = '{plug [^\d/}]*?\|(?=.*?/})'
exitPattern = '/}'
This allows for: {plug 100|wikitext with links/} which should be converted
to:
<span class="plug">wikitext with link<span>[...some js that uses 100 as a
parameter]</span></span>
the handle function state will find for the above example:
DOKU_LEXER_ENTER: {plug label|
DOKU_LEXER_MATCHED:wikitext with links
DOKU_LEXER_EXIT:/}
So based on my understanding of your post, I'll construct the following data
in these situations and pass them to the renderer:
DOKU_LEXER_ENTER:
//assign the js stuff based on the numbers to a variable for the Exit
pattern
$this->$tag_end = '<span>[...some js that uses "numbers" as a
parameter]</span>';
return array('enter','<span class="plug">);
DOKU_LEXER_MATCHED:
return array('matched', $data);
DOKU_LEXER_EXIT:
return array('exit', $this->$tag_end);
In the render function:
list($instr, $data) = $indata;
if($mode == 'xhtml'){
switch ($instr) {
case 'enter' :
$renderer->doc .= $data;
break;
case 'data' :
$renderer->doc .= $data;
break;
case 'exit' :
$renderer->doc .= $data;
break;
}
return true;
....
On 12/27/06, Chris Smith <chris@xxxxxxxxxxxxx> wrote:
Martin Tschofen wrote:
> I have the need to output text after the matched text of a plugin.
> Given this regex pattern:{plug [^\d/}]*?(?=[\d]+/}) as an entry
> pattern in a
> plugin (exit pattern; '/}':
>
> In the handle function all the numbers found are processed in the
> DOKU_LEXER_MATCHED state which happens after the additional parameters
> are
> already handled.
> I want to output any of the additional parameter that get's caught right
> after '{plug ' and output it after the the numbers.
>
> Is my only choice to set the additional parameter after the matched
> text by
> assigning it to a variable inside my plugin and then when
DOKU_LEXER_EXIT
> occures return that variable to the render method?
>
> Is there a better way?
>
> Hope this makes sense. Thanks in advance...martin
>
No, it doesn't make sense to me.
What do you mean by output?
Is this for debugging?
DokuWiki works by processing your wiki text into a php serialised array
of render instructions. The handle() method is where your plugin tells
DW the data that your render instructions need. Since the instructions
are a representation of the wiki text they are created once after each
page edit.
Whenever DW needs to display the page, it will either, check the xhtml
cache and if it finds a valid version display that version (with no
additional processing) or it will load up the instructions and render
the page.
As you'll see from the above, there is a disconnect between handle() and
render(). Although it is usual for a render() to be called after every
handle() it can not be guaranteed that this will always be the case. On
the other hand, it is unlikely render() calls will occur during the same
instance as handle() is called. Both functions should be independent
and only communicate through the data handle() returns and render()
receives as its parameters.
DOKU_LEXER_MATCHED refers to a pattern that is valid for your plugin
after the entry pattern and before the exit pattern. You don't mention
what that pattern is.
If you wish to catch various data, aggregate and process it in the
handle() function. Then the sensible method is to either use a single
pattern ( DOKU_LEXER_SPECIAL ) and process everything at once. Or to
aggregate each individual match onto a local property (a variable
defined on the plugin class) and then return that data during the
handling of the DOKU_LEXER_EXIT pattern.
The handle() function is passed the DW handler. Using that you can
modify the already saved instructions. So conceivably you could:
- find and modify the instruction created by plugin's entry match.
- find another point in the instruction array and insert your own
instruction.
Rather than hacking the instruction stack, which can't be guaranteed
future proof, more complex syntax structures (e.g. tables and lists) use
a slightly different mechanism. On entering those modes, they swap out
the DW call writer and put in place their own. Then when processing
their exit pattern they reexamine the instructions created by their own
call writer writing those instructions or modifications of them to the
main DW call stack before restoring the original call writer and
exiting. I may not have explained that too well, if you think you might
need something similar let me know and I'll try to explain in more detail.
It might be better if you explained what it is you are trying to with
your plugin.
Cheers,
Chris
--
DokuWiki mailing list - more info at
http://wiki.splitbrain.org /wiki:mailinglist
Other related posts:
