> - takes the input between two tags <myplug>blah</myplug>, > - passes "blah" to a command that produces a pdf for download, > - and generates some thumbnails for the downloadable pdf Will "blah" contain any other wiki syntax? if not use a substitution plugin and you don't need to worry about the lexer state. > 1) I managed to render <p>blah</p> with the color-example of > the tutorial. But I dont understand the return values of handler(). The > skeleton says > > @return Integer The current lexer state for the match. > > But all examples return a more complicated array(). Is this explained > somewhere a bit more detailed? What is the structure of "lexer state" > is it the params and result of handle() ? See http://www.dokuwiki.org/devel:parser#handler_token_methods for a description of the states. But as I said this is only relevant when your syntax can contain other syntax. > 2) If I get it right, I would generate the files in handle() (but on > "ENTRY" or "UNMATCHED" ?). UNMATCHED I'd say. But you can ignore the state in substitution plugins. > How would i > pass the filenames to render()? Via a private field in the plugin > class? No, through the array you return in the handler - it is passed to the renderer in a parameter. Because handler and renderer do not need necessarily be called on the same object instance you can not pass any data in plugins via private object members. > 3) As I said I generate a pdf via the shell and have > thumbnails for the single pages. > Where should the files go best? Would I need to generate any metadata > when I simply put it under data/media? How about versioning/caching > then? data/media is fine I think. caching is a bit tricky, generally regenerate the data for old revisions and use caching for the current revision only. Have a look at the ABC plugin which deals with a similar problem. BTW. there is a completely different approach - using a render plugin. Explaining this is a bit hard because I never tried it before. But it should work a bit like this: In the xhtml renderer mode replace the plugin syntax with a call to export the page with your own syntax plus an additional parameter identifying the syntax position in the page (eg. the 5th call to your plugin in that page generates do=export_myplugin&part=5). The in the renderer part of your plugin, skip all syntax except your own. Of course also skip all parts not matching the part variable. Then generate the PDF and stream it to the browser. As I said - I never tried this aproach but it should work. Andi -- splitbrain.org -- DokuWiki mailing list - more info at http://wiki.splitbrain.org/wiki:mailinglist