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

[Vincent Massol]

Does anyone have use cases that they would like to see covered?

(to test if the design below works for them)

Thanks
-Vincent

On Sep 26, 2007, at 8:34 PM, Vincent Massol wrote:

> Hi xwiki devs,
>
> This is a summary of the decisions so far and the remaining  
> questions. This is also the outcome of my discussion of today with  
> Mikhail on skype.
>
> 1) We'll be able to import all syntaxes.
>
> 2) An XWiki instance will use a single syntax at a time. Once the  
> database is created using that syntax it won't be possible to  
> change it (except by doing an export and reimport).
>
> We also need to decide what syntax we use by default OOB. I propose  
> we use the current xwiki syntax for some time and then switch to  
> the Wikimodel one (Common Syntax) later on.
>
> 3) All pages will be able to be exported to any syntax. Some  
> elements have no equivalent in other syntaxes and when this happens  
> a warning will be displayed and the elements in question ignored.
>
> 4) Mikhail has agreed to modify wikiModel to add macro block  
> recognition.The syntax isn't fully defined yet but it'll be  
> something like:
>
> {xxx param1=value1 param2=value2}
> ...
> {/xxx}
>
> (param1='value value' and param1="value value" will also be supported)
>
> This means we'll be able to have a common syntax for xwiki's macros  
> and also for groovy code:
>
> {groovy}
> ...
> {/groovy}
>
> And also for HTML blocks:
>
> {html}
> ...
> {/html}
>
> 5) We need to decide if we want:
>
> A) No velocity block but document properties/metadata to tell xwiki  
> to render the page using velocity. A user putting velocity code in  
> a page will have to check a box somewhere to say that this is a  
> velocity page.
>
> Pros:
> * Slightly easier to enter velocity code
>
> Cons:
> * Exception case compared to groovy, macros, etc
> * User must not forget to check the checkbox saying the page  
> contains velocity code
>
> OR
>
> B) Velocity blocks same as what exists for groovy/macros/html, namely:
>
> {velocity}
> ... velocity code with wiki syntax allowed
> {/velocity}
>
> Note1: For B) we would allow putting wiki syntax inside the  
> velocity block. Technically we'll apply the velocity rendering and  
> then re-apply wikimodel on the result.
> Note2: For backward compatibility we can have a config flag  
> (xwiki.compatibility = 1) that automatically adds the {velocity}{/ 
> velocity} marker around the whole page. The only downside is that  
> it'll be as slow as it currently is (actually it'll be faster since  
> wikimodel is going to be faster than radeox)
>
> Pros:
> * Speed. Since we know the blocks that use velocity we can cache  
> all the wiki syntax not inside the velocity/macros/groovy blocks  
> which will speed up considerably the rendering of pages
> * Consistency with macros and groovy blocks.
>
> My preferences goes to B) and I'm proposing to use that.
>
> 6) Mikhail is going to add support for recognizing XML tags in the  
> wikimodel parser so that onOpenXmlTag()/onCloseXmlTag() events are  
> called in listeners). This is needed for point 7 below.
>
> 7) We need to allow intermixing velocity/HTML and wiki syntax  
> easily.  For this our listener (the code that listens to {velocity}  
> events) will evaluate the content using velocity and will call wiki  
> model again on the resulting code. Since wikimodel requires HTML to  
> be in a block ({html} for us) we'll use a different wikimodel  
> listener that intercepts the onOpenXmlTag/onCloseXmlTag so that  
> it'll output XML tags with no modifications (the standard HTML  
> listener generates &lt; and &gt; for < and >). This will allow  
> writing:
>
> {velocity}
> <div>
> <h1>Hello $customer.Name!</h1>
> <table>
> #foreach( $mud in $mudsOnSpecial )
>    #if ( $customer.hasPurchased($mud) )
>       <tr>
>         <td>
>           * [link>$flogger.getPromo( $mud )]
>         </td>
>       </tr>
>    #end
> #end
> </table>
> </div>
> {/velocity}
>
> 8) Documents are stored in textual format in the DB (i.e. as the  
> user sees them). Portions of them will be cached after they're  
> rendered for the first time (see option B above for the best  
> caching option).
>
> Are you ok on these points and especially about using the 5B solution?
>
> Anything else I've forgotten?
>
> If we agree, then my next steps are:
> * Understand the wikimodel API in more details
> * Understand the doxia API too (it's a "competitor" to wikimodel).  
> The reason is that I'd like to see two implementations to ensure  
> that the XWiki Interfaces can be implemented using different  
> implementations so that XWiki is independent of the underlying  
> rendering/parsing framework used. Jason Van Zyl is also interested  
> in implementing the doxia part for XWiki in the future.
> * Propose a XWiki API
> * Propose an integration path
> * Implement it using WikiModel
>
> Thanks
> -Vincent
>
> _______________________________________________
> devs mailing list
> devs at xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.xwiki.org/pipermail/devs/attachments/20070926/f0c9f864/attachment-0001.html