28 Sep
2007
28 Sep
'07
12:05 p.m.
Hi Erin,
On Sep 27, 2007, at 10:15 PM, Erin Schnabel wrote:
Yep that's the point too but it means anything inside will be left
alone, including wiki syntax and HTML. But that's fine I think.
You'll get some benefits (since Wikimodel is faster than Radeox) but
not all performance gains.
Ah I see... You mean when not using the {velocity} tag I guess. Good
point....
hmm....
I guess we could allow the {html} macro to interpret wiki syntax too.
We could have a parameter like this:
{html renderWikiSyntax=true}
...
{html}
WDYT?
On 9/26/07, Vincent Massol <vincent(a)massol.net>
wrote:
These exports would be only useful for people moving away from xwiki
I think and they would be useful only to import into another wiki.
The way to import history in each wiki is different I guess so saving
the history in a format specific to each wiki will be too much work
for us so I'd say not to exporting the history. However exporting any
version of a page is doable easily.
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."
Yes I guess that's possible but requires more work. We have so much
work to do already that I think this would be left for later or left
for the community to implement with patches.
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?
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?
Right. It would be allowe for Velocity but not for Groovy for example.
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).
Yep, that's what I proposed.
An html block would specify that you wouldn't
want any wiki parsing
at all, right?
Yes
(wait a minute, isn't that what the pre tags were
supposed to do?).
Yes. We'll deprecate the pre tag then since an html tag makes more
sense and is better named IMO.
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. ). 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} 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.
Yes, it's possible to also have XHTML (not HTML) with the new
onOpenXmlTag/onCloseXmlTag() that Mikhail is going to add. So we
could have a listener that outputs the XHTML as is.
It's a good question, I'm not sure sure which is best. Right now I'd
be tempted to use the {html} notation proposed above (with the
renderWikisyntax parameter).
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?
Templates will be treated the same as documents (as is the case now I
think).
The templates would use the same {velocity} macro.
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...
hmm... Are they cached now? I don't see how they could be since it
would mean the velocity doesn't get executed at each request.
Yes, I would assume we would use {velocity} blocks.
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)?
We need to bring more consistency to this area too but it's another
topic I think.
Would you have to make script {script} {/script}
blocks in textarea
content of objects? (I'm thinking Panels, so I'd say yes).
I think 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}
That will work. The velocity macro will run velocity on the whole
block and then pass the result back to wikimodel. Wikimodel will see
the {groovy} macro and the groovy macro will be executed.
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.
Good questions ;)
Thanks
-Vincent