[xwiki-devs] [Discussion] Designing the new Rendering/Parsing component/API

[Erin Schnabel]

I should never ever reply to documents until I get to the end of the
note chain. My apologies for being redundant:

This is getting complicated. My view (because of what I know our
documents are loaded with:

A) velocity script just intermixed with text has to be supported.
B) The wiki formatting we have now (loosely based on Radeon) has to
work, with {code} and {pre} tags actually working (which is fixed in
1.1, I understand.. I've yet to move up

It's my view that having all this macro stuff (between groovy,
velocity, the macro defs, etc) jammed into the XWikiPreferences doc is
inappropriate-- That doc in general is too big. I think, for example,
that there should be a separate doc for "ad" configuration that you
only use if ads are enabled, etc. That's a separate discussion, I
think. ;)

But anyway, remember consumability with this: if we're mucking around
with the syntax that's supported, the macros that are supported, etc.
those should be specified in a separate prefs doc.

On 9/14/07, Vincent Massol <vincent at massol.net> wrote:
> +1 to all that. So let me summarizes and rephrase to see if I have
> understood :)
>
> 1) We have 4 types of objects:
> * TextProcessors: take text and generate text
> * Parsers: take text and generate an internal DOM format (pivot format)
> * DomProcessors: take DOM and generate DOM
> * Renderers: take DOM and generate anything (text, PDF, RTF, HTML,
> XML, etc)
>
> 2) Document contents are stored in the database in textual format in
> the main xwiki syntax (whatever we decide it is - we could
> standardize on creole for example)
>
> 3) Use case 1: Viewing a document
>
> a) Get the doc from the DB --> text1 (xwiki text format)
> b) Apply TextProcessors --> text2
> c) Call XWikiParser --> DOM1 (transforms XWiki text syntax into an
> internal DOM)
> d) Apply DomProcessors --> DOM2
> e) Call the required Renderer --> PDF, XML, HTML, RTF, text, etc
>
> 4) Use case 2: Editing a document, assuming the user wants to use the
> MediaWiki syntax for editing
>
> a) Get the doc from the DB --> text1 (xwiki text format)
> b) Call XWikiParser --> DOM1 (transforms XWiki text syntax into an
> internal DOM)
> c) Call MediaWikiRenderer --> text2 (text in MediaWiki format)
> d) the user edits and hits save
> e) MediaWikiParser --> DOM2 (transforms MediaWiki text syntax into
> the internal DOM)
> f) Call XWikiRenderer --> text" (transforms DOM into xwiki textual
> format)
> g) Save text3 in the database
>
> 5) In practice this means the following classes:
>
> * TextProcessorManager: to chain several text processors
> * TextProcessor
>    - VelocityTextProcessor
>    - GroovyTextProcessor
> * WikiParser: Takes wiki syntax and generates a DOM in a XWiki-
> specific format (independent of the different wiki syntaxes).
>    - LegacyXWikiWikiParser
>    - XWikiWikiParser (or simply use CreoleWikiParser if we want our
> internal format to be Creole)
>    - ConfluenceWikiParser
>    - MediaWikiWikiParser
>    - JSPWikiWikiParser
>    - CreoleWikiParser
>    - HTMLParser: I think all parsers above need to support HTML since
> the wiki syntaxes can be mixed with HTML. So this HTMLParser is
> probably a parent of the other parsers in some regard. Anyway we need
> this one for the WYSIWYG editor which may need to transform HTML to
> wiki syntax (so we may need a XWikiDomProcessor too to transform into
> XWiki syntax). The alternative (much better) is to have the WYSIWYG
> editor only use the internal XWiki-specific DOM format for all its
> manipulations.
> * DomProcessorManager: to chain several DOM processors
> * DomProcessor
>    - Don't know yet what we're going to use this for. TOCDomProcessor
> as you say above maybe.
> * Renderer
>    - XMLRenderer
>    - HTMLRenderer
>    - PDFRenderer
>    - RTFRenderer
>    - XWikiRenderer (or simply use CreoleRenderer if we want our
> internal format to be Creole)
>    - ConfluenceRenderer
>    - MediaWikiRenderer
>    - JSPWikiRenderer
>    - CreoleRenderer
>
> WDYT? Do I have it right? :)
>
> Thanks
> -Vincent
>
> On Sep 13, 2007, at 6:37 PM, Stéphane Laurière wrote:
>
> > Hi Vincent, hi everyone,
> >
[snip....]
> >
> > WikiModel generates events for blocks that are not to be parsed
> > (typically because they contain scripts).
> >
> > For example, in the WikiModel syntax currently called "CommonSyntax",
> > this looks like the following:
> > ==============
> > {{{macro:mymacro (String parameters)
> > dothis
> > dothat
> >
> > }}}
> >
> >
> > $mymacro(parameters)
> > ==============
> >
> > For each syntax, macro blocks are identified as far as possible (we
> > still have to check it's the case for all types of macro blocks inde
> > indeed).
> >


-- 
'Waste of a good apple' -Samwise Gamgee