27 Sep
2007
27 Sep
'07
10:15 p.m.
On 9/26/07, Vincent Massol <vincent(a)massol.net> 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).
This is the only thing that makes sense to me.
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.
OUCH. It's the only possible answer, but OUCH. I can just see the
complaints about data-loss piling up.. This will have to be
well-documented, perhaps including some tips about a) how to back
things up for real, and b) how to identify those areas later to assess
the damage...
Would you convert the syntax in the document history, too? Or does a
switch in syntax imply that the history is wiped... the document
history is very sensitive to random mucking around, I've found.
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}
Consistency is good, as is the lack of smashed-together-curly-braces.
If we demarcate all scripts in nice little blocks like this, will the
WYSIWYG editor be smart enough to leave it alone?
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.
...
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.
...
My preferences goes to B) and I'm proposing to use
that.
The compatibility flag in xwiki.cfg would help, but the problem is
that I wouldn't ever be able to turn the flag off if I have a large
legacy database... which means none of my new documents get whatever
performance benefit might be gained.
I would like to say: "I'm running in a compatibility mode, and have
flagged all of the documents that pre-dated the new syntax processing
model. Shame on me if we don't start using the scripting blocks for
new documents."
As far as adding {velocity} {/velocity} around content when in
compatibility mode.. that would apply to all pages, which means all
content would get passed through the velocity renderer, right?
I would think that whether or not wikitext (or raw html for that
matter) is allowed within a script block {script} {/script} would
depend on the nature of the language being invoked, right?
Velocity is easily integrated with wikitext and html without a lot
of fuss, so, in my view, you would be obligated to allow html and
wikitext within that block (generally agreed).
An html block would specify that you wouldn't want any wiki parsing
at all, right? (wait a minute, isn't that what the pre tags were
supposed to do?).
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
It seems there is this assumption that people either write wiki OR
they write html. I write both. At the same time. I am a nightmare for
anyone even thinking about stuff in neat little either/or packages. I
write a bunch of wikitext, and then throw some div tags around bits of
it, or to make a specific kind of heading that the silly syntax won't
generate for me, or..
I don't know that much about wikimodel, but I have to assume it isn't
going to complain if you intermix html in your wikitext. The only
benefit I see of the {html}{/html} tag is if the WYSIWYG editor will
then be smart enough not to bother messing with it. at all.
Does the templating model change? All of the templates/skins to date
use velocity, and are rendered using velocity, which seems not to be
an issue. Am I right in assuming (therefore) that this discussion
applies only to "documents" in the DB, and not to templates or skins?
What happens when portions of the templates are defined in a skin
document in the DB?
It seems semi-tangential to ask questions about skin/template
rendering, but I feel there is a significant amount of interdependency
between the skin and the content, especially if you consider the
#panel macros, for example. The #panel macros are a) velocity macros,
b) defined in files in the filesystem, and c) are included and used by
every document defining a panel.
Do changes to the rendering/parsing API require skin/template *.vm
files to be updated with {velocity} {/velocity} tags? Or would the
velocity engine continue to pre-read and cache those files as it does
now...
A bunch of other random questions:
Is there something we have to keep in mind here RE: document content
vs. object field content (which already has a flavor of content
rendering attribute)?
Would you have to make script {script} {/script} blocks in textarea
content of objects? (I'm thinking Panels, so I'd say yes). Will the
page parser panic if you either include the content of a field
containing a block within a different content block? e.g.
{velocity}
.. find an object of type x (with field y)
display object field y:
{groovy}
crazy scripting, man
{/groovy}
{/velocity}
As far as use cases go, mine is just this:
A LOT of pages (some of which have an extensive history and a lot of
attachments): largest portion have mix of html and wiki; second
largest is mix of velocity, html, and wiki; last is pages with groovy
(usually on pages also containing html, wiki, AND velocity).
That was rather stream-of-consciousness. So tell me if I was confusing.
--
'Waste of a good apple' -Samwise Gamgee
). 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}