[xwiki-devs] [Discussion] Designing the new Rendering/Parsing component/API
Vincent Massol
vincent at massol.net
Tue Sep 25 09:10:15 CEST 2007
Hi Erin,
On Sep 24, 2007, at 7:14 PM, Erin Schnabel wrote:
> I'm sure I missed something in the above, I was skimming pretty
> fast...
>
> I have, for example, a pretty hefty macro to create a navigation menu
> (corporate standards for look/feel, plus some pretty fun prototype
> stuff to add in dynamic bits.. ). It's a pretty awesome piece of
> code.. but it is 100% in velocity. I've used groovy only a handful of
> times, and all of them were in those cases where I had to do something
> velocity just wouldn't allow me to do.
>
> We have a few problems, as I see it: unless all of the skin templates
> have changed in 1.1, all of the templates currently use velocity
> (which just asks those of us writing our own skins based on the xwiki
> skins as a model to use velocity). Most of the pages (and I'm not
> kidding about that.. we have a lot of pages displaying objects from
> other pages, etc) use velocity.
As I stated in past emails by current view is that we need to keep
Velocity if only as a backward compatibility layer. I think it's more
than that though since:
1) it's simple
2) it mingles well with xwiki syntax
> Any kind of "translate velocity to groovy" incurs more overhead for
> the velocity pages. Even if the groovy code is cached, you still have
> the velocity-groovy conversion to worry about. How is that stored,
> anyway? I need to figure out more about what is and isn't cached and
> where.
If there were a conversion (which is definitely not agreed upon at
this point) it would be done once.
> The groovy vs. velocity discussion seems like one of those "religious"
> debates. Regardless of which macro language you prefer, the bottom
> line is that users have a crap-ton of velocity code in use-- you can't
> just drop the language, or incur a lot of overhead converting it into
> something else.
We all agree. Mikhail was mentioning that because he's thinking about
the best architecture for XWiki starting with a clean slate. On my
side, I do the opposite and start with current XWiki and see how we
could go towards Mikhail's ideas without breaking too much stuff ;)
> After looking @ all the samples, I'm really NOT happy with all the {{{
> }}} crap. None of my pages have that in there now, and I think it
> looks ugly and unreadable and just ... UGH. If I have to go and update
> ALL of my pages to add those silly characters I'll totally lose my
> mind! So what did I miss.. are those silly characters actually
> required with this new environment? if so, something is seriously
> broken.
I think those {{{ verbatim blocks can serve a useful purpose: they
tell XWiki what to do with the verbatim block. I can see the
following uses:
* Definition of a macro: {{{ macro:
* Definition of a Velocity block: {{{ velocity:
* Definition of a Freemarker block (or whatever other template
system): {{{ freemarker:
* Definition of a Groovy block: {{{ groovy:
However, as you mentioned we need to keep backward compatibility. We
could have a xwiki.compatibility=1 config property to keep the
current behavior. Internally, this would mean:
* Adding {{{ velocity: at the top of all existing pages before the
rendering is done
* Transforming <% to {{{ groovy:
I'm personally not too fond of the {{{ marker either but:
1) It's the only way I can think of that allows us to save the
document as a DOM tree in the DB and thus increase performances (it
still needs to be proved it increases performances - Mikhail/
Stephane, would be nice if you could send some stats). Note that the
performances will be improved ONLY for the part of the document not
inside a {{{ }}} block since those blocks are texts that need to be
parsed, thus incurring the speed penalty of parsing.
2) It allows to add other templating/scripting engines in a generic
manner. If we add other templating solutions it would be too costly
and non deterministic to apply them one after another.
3) It offers a common syntax for all extensions to the wiki syntax:
macros, scripts, templates, etc.
Question for Mikhail: is it possible to change the characters
representing the verbatim block in a given wiki syntax. For example
say I'm using the wiki syntax.
Ideally I would have preferred the following kind of syntax:
{velocity}
{/velocity}
{groovy}
{/groovy}
{jsp}
{/jsp}
{macro}
{/macro}
with the ability to pass parameters: {macro:param1=value1|
param2=value2...}
Is that possible with WikiModel?
Thanks
-Vincent
> On 9/24/07, Vincent Massol <vincent at massol.net> wrote:
>>
>>
>> On Sep 24, 2007, at 12:23 PM, Mikhail Kotelnikov wrote:
>> Hi!
>>
>> On 9/22/07, Vincent Massol <vincent at massol.net > wrote:
>>> Thinking more about storing documents into a DOM in the database, I
>>> have found 2 issues to discuss:
>>
>> 2) We need to consider current users who are using velocity
>>> intermixed with wiki syntax and we need to continue supporting them,
>>> either by having TextProcessors and a VelocityTextProcessor (thus
>>> storing text in the DB) or by somehow converting the current way of
>>> writing velocity to the "new" way, whatever this is. But in any case
>>> we need to find something better than what is in 1) above. I'd hate
>>> that it be worse for users. This leads me to believe we might
>>> need to
>>> keep TextProcessors and store the content in textual format in
>>> the DB.
>>
>> You can have the following scenarios:
>>
>> Scenario A: Processing of the source for each request
>> 1. You load your content from the DB
>> 2. You process the content using a template engine
>> (Velocity/Freemarker/StringTemplate/...). The whole page is
>> considered as a simple template for the corresponding template
>> engine.
>> 3. The results of such a processing is parsed by the WikiModel
>> parsers.
>> pro: You template engine can be used to generate additional wiki
>> elements.
>> No needs to use "embedded blocks" and stuff like that
>> con: You have to repeat the operations 2) and 3) for *each
>> request*. These
>> steps are the slowest steps in the page processing.
>>
>> Scenario B: You process only some verbatim blocks containing
>> template-based
>> "inclusions".
>> 1. You load your page from the DB as an XML document or as a wiki
>> syntax
>> 2. You parse it and transform the content into an in-memory
>> structure (DOM).
>> This object can be cached in memory.
>> 3. You handle only some verbatim blocks in this DOM structure to
>> transform
>> its content using a template engine.
>> pro: For each query you repeat only the step 3. The initial DOM
>> structure is
>> the same and it can be cached. In this case we avoid the parsing
>> the wiki
>> document from wiki syntax or DOM
>> con: You can not generate the wiki syntax. Your template blocks
>> have to
>> generate the resulting (X)HTML.
>>
>> Personally I prefer the Scenario B. In this case some verbatim
>> blocks can be
>> considered as an HTML/TeX/... markup, as
>> Groovy/Javascript/JPython/JRuby/... script blocks and some
>> - as template blocks
>> (Velocity/Freemarker/StringTemplate/...)
>>
>> Yes, this is exactly my point. I don't see a way to have the pros
>> of both A
>> and B.
>>
>> I'm leaning towards B right now, not for performance reasons of
>> course (for
>> this B is better) but for usability and backward compatibility.
>>
>> When say you "prefer" solution B, I'm pretty sure you're
>> preferring it as a
>> developer but not as an end user. The following:
>>
>> {{{
>> #foreach ($link in $doc.backlinks)
>> * [whatever>$link]
>> #end
>> }}}
>>
>> Is always more complex for users than:
>>
>> #foreach ($link in $doc.backlinks)
>> * [whatever>$link]
>> #end
>>
>> I feel users will write stuff like this:
>>
>> {{{
>> full content of the page containing wiki syntax and velocity markup
>> }}}
>>
>> which means we're back to square one and to solution A, since we
>> can have
>> velocity markup include wiki syntax...
>>
>> This in term of performance I don't think A and B will be very
>> different.
>> Only advantage of B is that we can define a notation to specify which
>> templating engine to use. Something like:
>>
>> {{{ velocity|freemarker:
>> content
>> }}}
>>
>> This would be in addition to the macro definition presented by
>> Stephane in
>> an earlier message:
>>
>> {{{macro:mymacro (String parameters)
>> dothis
>> dothat
>> }}}
>>
>> BTW Stephane/Mikhail, how do you call macros? Do you call them
>> using a
>> verbatim block too?
>>
>> Also is there a generic support in WikiModel for variables? For
>> example:
>>
>> A list:
>> * item $myitem
>>
>> BTW: I created a very simple common template API which is
>> available in the
>> public Nepomuk repository. There are two implementations for this
>> API: a
>> Velocity and a Freemarker-based on (see Freemarker here:
>> http://freemarker.org/) I think it is easy to implement the same
>> API for
>> StringTemplate (http://www.stringtemplate.org/). It may be useful
>> for the
>> future implementations of the XWiki templating...
>>
>> Ok good to know in case we need it.
>>
>> [snip]
>>
>> Thanks
>> -Vincent
>
>
> --
> 'Waste of a good apple' -Samwise Gamgee
> _______________________________________________
> devs mailing list
> devs at xwiki.org
> http://lists.xwiki.org/mailman/listinfo/devs
More information about the devs
mailing list