On 9/26/07, Vincent Massol <[EMAIL PROTECTED]> 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
> >). 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}
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
_______________________________________________
devs mailing list
devs@xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
