[xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues

[Hans Gerwitz]

I agree with everything Stephen and Erwan have said.  We should feel  
free to make syntax changes pre-1.0 to ensure we have the cleanest  
approach going forward.  I've found during a migration from SnipSnap  
that it's not too difficult to whip up some Groovy that filters old  
to new.

I would like, though, to see the API expose a DOM of sorts.  This  
would make migrating between syntaxes quite robust (use the "old"  
renderer to produce DOM, write out with "new" renderer) and the  
effort of opening up the rendering process would enable sectional  
editing and other fragment-context functionality later on.
- - -
Hans Gerwitz
http://phobia.com/


On Oct 28, 2005, at 11:59 AM, Erwan Arzur wrote:

> Hey Stephen
>
> we recently had a discussion with Ludovic about choosing a  
> rendering engine and not mix both velocity and groovy.
>
> About your UI proposal, i think it needs some more thinking because  
> we might want to plug other engines in addition to groovy and  
> velocity, but i find it better and easier to implement than my own  
> idea which was to implement a kind of preprocessor which would  
> allow the user to select the rendering engine to use for her document.
>
> agree with your proposal about {pre} and {code} radeox tags, with  
> the provision that it might prove very complex to hide selected  
> content from the velocity/groovy engines.
>
> Agree about error messages, they need a lot of improvements
>
> And you're right about all those not fitting into a single JIRA  
> issue :D
>
> 1. choosing a rendering engine. I'd like to add that mixing the two  
> in a document is a very bad design decision (but facts could prove  
> me wrong), just for the possible namespace collisions that could  
> happen (your $varname example)
> 2. {pre} syntax not coherent with other tag's
> 3. {pre} {code} specs should be amended
> 4. forcing enclose scripts into radeox tags
>
> All this make significant syntax changes to make me wonder about  
> existing documents ... how to migrate them or make sure the old  
> syntax is still ok for them ?
>
> Erwan
>
> On 10/28/05, Stephen Schaub <stephen_schaub_88 at hotmail.com> wrote:
> When XWiki renders a document, the interactions between the Groovy,
> Velocity, and Wiki (Radeox?) syntax processing can lead to  
> unexpected and
> undesirable behavior. There have been posts on this list in the  
> past where
> this issue has been discussed. However, I'm not aware that any  
> consensus has
> emerged as to how to deal with these problems.
>
> To summarize, here are a few of the issues that I'm aware of:
>
> * Getting XWiki to render a bit of text without doing any syntax  
> processing
> on it can be difficult. For example, the {pre} ... {/pre} markup  
> turns off
> XWiki syntax processing, but not Groovy processing.
>
> * The # symbol is used both to do numbered lists and is also used  
> for Groovy
> processing. If a user wants to create a numbered list and forgets  
> to put a
> space after the #, he can run into trouble. The following example  
> will cause
> a stack dump:
>
>   #bring coffee
>   #include doughnuts
>
> * Code samples on a Wiki page sometimes don't render correctly, due to
> conflicts with Velocity syntax processing. The following C/C++ code  
> sample
> results in a runtime stack dump:
>
> {code}
> #include <stdio.h >
> ...
> {code}
>
> * Groovy and Velocity both use $varname syntax. I think I've read  
> some posts
> in the past where this was an issue -- although I can't come up  
> with any
> examples at the moment.
>
> * A usability issue: Most XWiki tags ({table}, {code}, etc.) come  
> in pairs.
> The closing tag has no slash. For example:  {table} ... {table}.  
> However,
> the {pre} tag does have a closing slash: {pre} ... {/pre}. This
> inconsistency is annoying and causes difficulties for new users.
>
> * A significant usability issue for Windows users: Pathnames contain
> backslashes (\). XWiki uses the backslash as an escape character. So
> attempting to put a UNC path like  \\myserver\myshare\mydoc.txt in  
> an XWiki
> document triggers an XWiki runtime exception.  Boy, is that  
> frustrating for
> new XWiki users. The solution is to wrap the path in {pre} .. {/ 
> pre}, but
> the error message gives the user no clue what the problem was, much  
> less how
> to correct it.
>
> Here are some proposals for discussion:
>
> 1. {pre} ... {/pre} should turn off ALL syntax processing of its  
> contents.
> 2. {code} ... {code} should turn off ALL syntax processing, except for
> syntax coloring.
> 3. {pre} should allow {pre} as a closing tag.
> 4. Consider requiring users to explicitly enable Groovy/Velocity  
> processing
> for selected Wiki documents as needed. In the page editor, provide two
> checkboxes: "Perform Groovy Processing" and "Perform Velocity  
> Processing".
> The user could separately enable either Groovy or Velocity  
> processing, or
> both. People who enable them would presumably be in a better  
> position to
> deal with the kinds of syntax conflicts that would occur.
> 5. Provide more user-friendly error messages when a Groovy or Velocity
> processing exception occurs. Show the Wiki source line that caused the
> problem.
>
> I haven't opened a JIRA issue for this yet, because I'm not sure  
> how best to
> word it. But I think this is a high-priority issue that should be  
> carefully
> addressed before the 1.0 release. This may be an issue that  
> warrants a page
> on the xwiki.org developer site. I'll be glad to start one if the  
> developers
> desire it -- perhaps here:
> http://www.xwiki.org/xwiki/bin/view/Dev/Discussions
>
> Stephen
>
>
>
>
>
>
> --
> You receive this message as a subscriber of the xwiki- 
> dev at objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe at objectweb.org
> For general help: mailto: sympa at objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/ 
> wws
>
>
>
>
> --
> You receive this message as a subscriber of the xwiki- 
> dev at objectweb.org mailing list.
> To unsubscribe: mailto:xwiki-dev-unsubscribe at objectweb.org
> For general help: mailto:sympa at objectweb.org?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/ 
> wws
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.xwiki.org/pipermail/devs/attachments/20051028/46b5bd37/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2503 bytes
Desc: not available
URL: <http://lists.xwiki.org/pipermail/devs/attachments/20051028/46b5bd37/attachment-0001.bin>