26 Sep
2007
26 Sep
'07
8:41 p.m.
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 < and > 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(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs