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@massol.net> wrote:
On Sep 24, 2007, at 12:23 PM, Mikhail Kotelnikov wrote: Hi!
On 9/22/07, Vincent Massol <vincent@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@xwiki.org http://lists.xwiki.org/mailman/listinfo/devs