25 Sep
2007
25 Sep
'07
9:10 a.m.
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(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
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs 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