(this ist not so much a feature request than more a question: how close is moin to the following architecture?)
Today we speak of parsers, formatters etc. Moin is really great because of its pluggable architecture. But IMHO parsers, formatters and themes are a little to narrowly knitted together. A more flexible solution would be a transparent and configurable pipeline architecture. It doesn't have to be that complex like cocoon, but the idea ist still there:
Entry edit request:
- let the user edit these parts of the document she is allowed to edit
- lexx the rawtext and transform it into a tree structure
- allow the processing of selected macros
- At this point of the processing? IMHO this should take place later-on in the pipeline, maybe even in multiple passes (includes/TOCs etc.)
- parse the tree structure and throw out a well defined wiki representation
- perform zero or more transformations, i.e. more macro processing
- cache the intermediary version now!
Entry read request:
- serialize the document according to the requested output format.
- If you want to have it on the screen garnish it with some theme or css sugar.
If you prefer to navigate through the document like a book look at the content through some DocBook stylesheets
To provide a sane, transparent and flexible pipeline, the interface between the respective steps should be an XML structure if possible. (I love xslt; it seems to me that a lot of python coding could be refactured quite elegantly with 4Suite.)
There is some work in process yet: In RadomirDopieralski/SimpleParser we have an emitter. And parser/pseudoXML suggest to split up tasks according to whether they have to be performed with some simple context free regex, a context aware (and thus more complex) stack automaton or even xslt.
We have to tackle at last three main tasks:
converge to a WikiDtd (cf. http://www.usemod.org/cgi-bin/mb.pl?WikiXmlDtd )
make the various wiki lexxer/parsers (moin, mediawiki, rst etc.) produce WikiXml
write one (or more?!) inverse functions WikiXml2moin, WikiXml2media etc.
- Why inverse? Compatiblity layers would make sense in any case - letting you use old plugins in the new system.
The current system is simple: have a parser that lexes, parses and calls the formatter which emits chunks that have to be sent to request.write by the parser. Many formatters have to build internal trees and dont emit anything because of that (empty chunks). The parser has to call macros etc. if necessary.
related pages: MoinDev/WikiDom
