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

From: Ludovic Dubost <ludovic(a)xwiki.com> Reply-To: xwiki-dev(a)objectweb.org To: xwiki-dev(a)objectweb.org Subject: Re: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues Date: Sun, 06 Nov 2005 23:34:03 +0100 Hi, I've commented on http://www.xwiki.org/xwiki/bin/view/Dev/SyntaxProcessingIssues I agree with all your comments and remarks. I would however suggest to introduce new tags instead of {pre} in order to preserve backwards compatibility. Another solution would be to have a rendered version so that multiple versions of the wiki rendering can be available. The default rendering can be chosen in the XWiki Prefs and it's possible to choose the renderers and versions on a per page basis Concerning the DOM, this is difficult with the current rendering engine. However, I had discussions with a company that has started a wiki rendering engine which is really powerfull and was thinking about making it open-source. I'll re-discuss this with them. Ludovic Stephen Schaub a écrit : >> On 10/28/05, Stephen Schaub <stephen_schaub_88(a)hotmail.com> wrote: > >> > 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. > >> From: Erwan Arzur <earzur(a)gmail.com> > >> 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. > > Good point. I personally feel that mixing both Groovy and Velocity > processing on the same page is asking for trouble, but I worded my > initial proposal with backwards compatibility in mind, since some > existing pages probably use both. > > If we can agree that the user should be allowed to select only one > scripting language for a given page, then the page editor could > provide a UI that enforces that. (For example, radio buttons or a > dropdown list to choose the scripting engine for the page.) > > Stephen > >