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

Vincent Massol vincent at massol.net
Tue Sep 11 13:46:14 CEST 2007


Hi,

I've started working on designing the new Rendering/Parsing  
components and API for XWiki. The implementation will be based on  
WikiModel but we need some XWiki wrapping interfaces around it. Note  
that this is a prerequisite for the new WYSIWYG editor based on GWT  
(see http://www.xwiki.org/xwiki/bin/view/Design/ 
NewWysiwygEditorBasedOnGwt).

I've updated http://www.xwiki.org/xwiki/bin/view/Design/ 
WikiModelIntegration with the information below, which I'm pasting  
here so that we can have a discussion about it. I'll consolidate the  
results on that wiki page.

Componentize the Parsing/Rendering APIs
==================================

We need 4 main components:

     * A Scripting component to manage scripting inside XWiki  
documents and to evaluate them.
     * A Rendering component to manage rendering Wiki syntax into  
HTML and other (PDF, RTF, etc)
     * A Wiki Parser component to offer a typed interface to XWiki  
content so that it can be manipulated
     * A HTML Parser component (for the WYSIWYG editor)

Different Syntaxes
===============

Two possible solutions:

    1. Have a WikiSyntax Object (A simple class with one property: a  
combox box with different syntaxes: XWiki Legacy, Creole, MediaWiki,  
Confluence, JSPWiki, etc) that users can attach to pages to tell the  
Renderers what syntax is used. If no such object is attached then  
it'll default to XWiki's default syntax (XWiki Legacy or Creole for  
example).
    2. Have some special syntax, independent of the wiki syntaxes to  
tell the Rendered that such block of content should be rendered with  
that given syntax. Again there would be a default.

XWiki Interfaces
=============

     * ScriptingEngineManager: Manages the different Scripting  
Engines, calling them in turn.
     * ScriptingEngine
           o Method: evaluate(String content)
           o Implementation: VelocityScriptingEngine
           o Implementation: GroovyScriptingEngine
     * RenderingEngineManager: Manages the different Rendering  
Engines, calling them in turn.
     * RenderingEngine
           o Method: render(String content)
           o Implementation: XWikiLegacyRenderingEngine (current  
rendering engine)
           o Implementation: WikiModelRenderingEngine
     * Parser: content parsing
           o HTMLParser: parses HTML syntax
           o WikiParser: parses wiki syntax
           o Implementation: WikiModelHTMLParser
           o Implementation: WikiModelWikiParser

Open Questions:

     * Does WikiModel support a generic syntax for macros?
     * Is the Rendering also in charge of generating PDF, RTF, XML, etc?
           o I think so, need to modify interfaces above to reflect  
this.
     * The WikiParser needs to recognizes scripts since this is  
needed for the WYSIWYG editor.

Use cases
========

     * View page
           o ViewAction -- template -> ScriptingEngineManager.evaluate 
() -- wiki syntax -> RenderingEngineManager.render() ---> HTML, XML,  
PDF, RTF, etc
     * Edit page in WYSIWYG editor
           o Uses the WikiParser to create a "DOM" of the page  
content and to render it accordingly. NOTE: This is required since  
rendering in the WYSIWYG editor is different from the final  
rendering. For example, macros need to be shown in a special way to  
make them visible, etc.
           o Changes done by the user are entered in HTML. Note: it  
would be better to capture them so that they are entered in the  
"DOM". Is that possible? If not, then the HTMLParser is used to  
convert from HTML to Wiki Syntax but they're likely be some loss in  
the conversion. The advantage is the ability to take any HTML content  
and generate wiki syntax from it.

This is my very earlier thinking but I wanted to make it visible to  
give everyone the change to 1) know what's happening and 2) suggest  
ideas.

I'll refine this in the coming days and post again on this thread.

Thanks
-Vincent



More information about the devs mailing list