24 Sep
2007
24 Sep
'07
7:14 p.m.
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 <vincent(a)massol.net> wrote:
On Sep 24, 2007, at 12:23 PM, Mikhail Kotelnikov wrote:
Hi!
On 9/22/07, Vincent Massol <vincent(a)massol.net > wrote:
--
'Waste of a good apple' -Samwise Gamgee
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