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.
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.
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.
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.
IMO, anyhow. ;)
On 9/24/07, Vincent Massol <[EMAIL PROTECTED]> wrote:
>
>
> On Sep 24, 2007, at 12:23 PM, Mikhail Kotelnikov wrote:
> Hi!
>
> On 9/22/07, Vincent Massol <[EMAIL PROTECTED] > 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
