Groovy, Velocity, and XWiki syntax processing issues
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
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 <[email protected]> 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 <http://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 [email protected] list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
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 <[email protected]> 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- [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto: [email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/ wws
-- You receive this message as a subscriber of the xwiki- [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/ wws
On 10/28/05, Stephen Schaub <[email protected]> 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 <[email protected]>
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
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 <[email protected]> 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 <[email protected]>
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
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
Hi all, I have followed the tutorial for crating a new classe and insert it in a new document, but it not work! This is the link that I have followed to do that : http://www.xwiki.org/xwiki/bin/view/DevGuide/FAQs+Tutorial Other question: How to create by groovy or velocity a new document and put text in it's content. (like I give the name of document in edit area and after that I click a button, this will be create for me a new document with the given name of document) All my thanks in advance ---------------------------------------------------------------------------- ------------- Youcef
Can you try to provide more information about your problem? what part of the tutorial did you get through successfully? When i wrote the tutorial, I installed new versions of XWiki 3 times and went through the tutorial step-by-step 3 times to ensure its accuracy. I know that it works. See if you can give me some more information and maybe I can help. ================================== Cody Burleson IBM, Business Consulting Services On Demand Workplaces "Simplifying access to content, applications, people and processes." Current Client Office (Mon - Thur): (404) 828-4583 Home Office [Friday, Sat. Sun. or email a voice message]: (214) 233.3546 Cell [anytime]: (214) 537-8783 Email: [email protected] "Youcef BEY" <[email protected]> 11/07/2005 02:42 AM Please respond to [email protected] To <[email protected]> cc Subject [xwiki-dev] Problem with class creation Hi all, I have followed the tutorial for crating a new classe and insert it in a new document, but it not work! This is the link that I have followed to do that : http://www.xwiki.org/xwiki/bin/view/DevGuide/FAQs+Tutorial Other question: How to create by groovy or velocity a new document and put text in it's content. (like I give the name of document in edit area and after that I click a button, this will be create for me a new document with the given name of document) All my thanks in advance ---------------------------------------------------------------------------- ------------- Youcef -- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
I think that I can tell you what's wrong with it. It doesn't mention the fact that you need to the xxxxxTemplate page has to include an object "Edit Objects" of the Class type that is being created. See the following thread. This was the missing key for me to get it working. http://mail-archive.objectweb.org/xwiki-users/2005-07/msg00072.html ----- Original Message ----- From: Cody Burleson To: [email protected] Sent: Tuesday, November 08, 2005 3:45 PM Subject: Re: [xwiki-dev] Problem with class creation Can you try to provide more information about your problem? what part of the tutorial did you get through successfully? When i wrote the tutorial, I installed new versions of XWiki 3 times and went through the tutorial step-by-step 3 times to ensure its accuracy. I know that it works. See if you can give me some more information and maybe I can help. ================================== Cody Burleson IBM, Business Consulting Services On Demand Workplaces "Simplifying access to content, applications, people and processes." Current Client Office (Mon - Thur): (404) 828-4583 Home Office [Friday, Sat. Sun. or email a voice message]: (214) 233.3546 Cell [anytime]: (214) 537-8783 Email: [email protected] "Youcef BEY" <[email protected]> 11/07/2005 02:42 AM Please respond to [email protected] To <[email protected]> cc Subject [xwiki-dev] Problem with class creation Hi all, I have followed the tutorial for crating a new classe and insert it in a new document, but it not work! This is the link that I have followed to do that : http://www.xwiki.org/xwiki/bin/view/DevGuide/FAQs+Tutorial Other question: How to create by groovy or velocity a new document and put text in it's content. (like I give the name of document in edit area and after that I click a button, this will be create for me a new document with the given name of document) All my thanks in advance ---------------------------------------------------------------------------- ------------- Youcef -- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws ------------------------------------------------------------------------------ -- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Dear Cody, I have a research work on Machine Translation, more especially on CAT (Computer-Aided Tools) for volunteer translators (my system will be for free). However I want to develop a collaborative environment for translation. For this, I have choose XWiki for its advantages. The installation was so easy, but the comprehension (for me) was so hard. On the one hand, I could not find a rich documentation (may be there are?) for programming inside xwiki. On the other, most of example does not work for me. For examples: 1. I want to create a specific forms for edition of documents. For this I am tried to construct some classes but still not work! (just for example). And more, I found that I could not develop my thinking about groovy and velocity for programming XWiki, because examples are not enough. I mean, for the instance I just find some examples and try to understand it, but this for me not productive. What I want is a riche documentation with which I can develop my idea (like java). 2. I want to attach files a text files in page. And after that, read the content of each files and put it a new page for reading and writing (by programming). For this example I have the following troubles: - I can read the attached files (I mean the list), but how to get the content of files? - How to take the extracted text and put it in a new page (in a specific space) by programming You could see, I am just a beginner! As for your tutorial for creating classes: It still not work. In fact, I follow the same instructions. But when I put the name of document and push "create document" button, in the status bar, the explorer display the following error : rectangle containing a explanation mark and the message string "error". I followed also the advices of Steve (all my thanks for him), but still not work. This is for what I am thinking to change to other Wiki, but I am sure that this XWiki is better because it contain most proprieties which I am look for. Finally, could you orient me to rich documentation. For example, Groovy and Velocity for programming XWiki. could you also give me documentation on how to exploit enhanced functionalities of classes creation? Best regards, ----------------------------------------------------------------------------------------- Youcef Bey, Graduate School of Advanced Studies, National Institute of Informatics, on study leave GETA/CLIPS (IMAG) Joseph Fourier University Kyo kageura Natinal Institute of Informatics ----- Original Message ----- From: Cody Burleson To: [email protected] Sent: Wednesday, November 09, 2005 7:45 AM Subject: Re: [xwiki-dev] Problem with class creation Can you try to provide more information about your problem? what part of the tutorial did you get through successfully? When i wrote the tutorial, I installed new versions of XWiki 3 times and went through the tutorial step-by-step 3 times to ensure its accuracy. I know that it works. See if you can give me some more information and maybe I can help. ================================== Cody Burleson IBM, Business Consulting Services On Demand Workplaces "Simplifying access to content, applications, people and processes." Current Client Office (Mon - Thur): (404) 828-4583 Home Office [Friday, Sat. Sun. or email a voice message]: (214) 233.3546 Cell [anytime]: (214) 537-8783 Email: [email protected] "Youcef BEY" <[email protected]> 11/07/2005 02:42 AM Please respond to [email protected] To <[email protected]> cc Subject [xwiki-dev] Problem with class creation Hi all, I have followed the tutorial for crating a new classe and insert it in a new document, but it not work! This is the link that I have followed to do that : http://www.xwiki.org/xwiki/bin/view/DevGuide/FAQs+Tutorial Other question: How to create by groovy or velocity a new document and put text in it's content. (like I give the name of document in edit area and after that I click a button, this will be create for me a new document with the given name of document) All my thanks in advance ---------------------------------------------------------------------------- ------------- Youcef -- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws ------------------------------------------------------------------------------ -- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
To answer your "how to create a new document" query, I present a snippet of Groovy: newDoc = xwiki.getDocument(spaceName, newTitle) newDoc.doc.setContent(newContent) newDoc.doc.setAuthor(authorName) newDoc.doc.setCreationDate(createdTime) newDoc.doc.setDate(modifiedTime) newDoc.saveDocument() - - - Hans Gerwitz http://phobia.com/ On Nov 7, 2005, at 1:42 AM, Youcef BEY wrote:
Hi all,
I have followed the tutorial for crating a new classe and insert it in a new document, but it not work! This is the link that I have followed to do that : http://www.xwiki.org/xwiki/bin/view/DevGuide/FAQs+Tutorial
Other question:
How to create by groovy or velocity a new document and put text in it's content. (like I give the name of document in edit area and after that I click a button, this will be create for me a new document with the given name of document)
All my thanks in advance ---------------------------------------------------------------------- ------ ------------- Youcef
-- You receive this message as a subscriber of the xwiki- [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/ wws
- - - Hans Gerwitz http://phobia.com/
Ludovic, Thanks for taking the time to respond. It seems there is fairly broad agreement on most of these proposals. I would be glad to add some or all of these proposals as JIRA tasks, if there is a consensus. Some of the proposals are no doubt easier than others to implement. It sounds like disabling syntax processing in {pre} and {code} may require more effort than is manageable in a 1.0 release timeframe. (?) What about requiring users to enable scripting on a per-page basis? Along with improving error messages, that would go a long way toward helping matters. Stephen
From: Ludovic Dubost <[email protected]> Reply-To: [email protected] To: [email protected] 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 <[email protected]> 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 <[email protected]>
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
Yes, go ahead and try segmenting this in tasks.. Indeed conditionnal processing would be the first thing that can be done quite easily The default behavior should be chosen by the administrator of the wiki The pre and code modifications are more complex Ludovic Stephen Schaub a écrit :
Ludovic,
Thanks for taking the time to respond. It seems there is fairly broad agreement on most of these proposals. I would be glad to add some or all of these proposals as JIRA tasks, if there is a consensus.
Some of the proposals are no doubt easier than others to implement. It sounds like disabling syntax processing in {pre} and {code} may require more effort than is manageable in a 1.0 release timeframe. (?) What about requiring users to enable scripting on a per-page basis? Along with improving error messages, that would go a long way toward helping matters.
Stephen
From: Ludovic Dubost <[email protected]> Reply-To: [email protected] To: [email protected] 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 <[email protected]> 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 <[email protected]>
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
------------------------------------------------------------------------
-- You receive this message as a subscriber of the [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
I was hoping there would be a bit more discussion about this -- do the developers have any input on their plans to address some of these issues? Is there a need to start a Wiki page to document these and other related syntax-processing issues? Stephen
From: "Stephen Schaub" <[email protected]> Reply-To: [email protected] To: [email protected] Subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues Date: Fri, 28 Oct 2005 09:46:13 -0400
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
I still plan to have a look at it, but I was swamped by other things. Do write a wiki page to give the status of your discussions.. Ludovic Stephen Schaub a écrit :
I was hoping there would be a bit more discussion about this -- do the developers have any input on their plans to address some of these issues? Is there a need to start a Wiki page to document these and other related syntax-processing issues?
Stephen
From: "Stephen Schaub" <[email protected]> Reply-To: [email protected] To: [email protected] Subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues Date: Fri, 28 Oct 2005 09:46:13 -0400
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 [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
-- Ludovic Dubost XPertNet: http://www.xpertnet.fr/ Blog: http://www.ludovic.org/blog/ XWiki: http://www.xwiki.com Skype: ldubost AIM: nvludo Yahoo: ludovic
I've created a page to document and discuss these issues: http://www.xwiki.org/xwiki/bin/view/Dev/SyntaxProcessingIssues It's linked on the Developer discussions page. Regards, Stephen
From: Ludovic Dubost <[email protected]> Reply-To: [email protected] To: [email protected] Subject: Re: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues Date: Thu, 03 Nov 2005 01:49:22 +0100
I still plan to have a look at it, but I was swamped by other things. Do write a wiki page to give the status of your discussions..
Ludovic
Stephen Schaub a écrit :
I was hoping there would be a bit more discussion about this -- do the developers have any input on their plans to address some of these issues? Is there a need to start a Wiki page to document these and other related syntax-processing issues?
Stephen
From: "Stephen Schaub" <[email protected]> Reply-To: [email protected] To: [email protected] Subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues Date: Fri, 28 Oct 2005 09:46:13 -0400
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.
[snip]
You have been discussing the ability to turn on and off Groovy or Velocity processing. I think it is necessary to go further and conditionally disable HTML as well. I am putting together a wiki application aimed at general Internet users, i.e. I must assume minimal skills. I am having to do many things to simplify XWiki. There is no way I am going to tell my users, for example: - to type < instead of < or & instead of & - to avoid using # next to subsequent letters - to be careful about the "$" character My users won't know what HTML is and don't want to know. All I will do is give them information on a minimal set of wiki tags, and that will be challenge enough! I will use HTML and Velocity in pages I create. Regardless of what Space those pages are in, they must be non-editable for end users. Pages created by end users must escape special HTML characters so that the pages display as expected. Solutions: I think the processing categories which can be turned on and off should include Velocity, Groovy, HTML, and possibly even Wiki. - In XWikiPreferences, specify which processing to perform for pages in the Space. (But this doesn't support per-page configuration?) - Require a directive on the first line of the page, like: #use(vm, html) If it doesn't exist, default to Wiki processing only. For backward compatibility, the default processing could be set in XWikiPreferences. I'm going to have to go ahead and do something like this for myself shortly, so I'd be happy to help. Trevor http://www.condowiki.com Stephen Schaub wrote:
I was hoping there would be a bit more discussion about this -- do the developers have any input on their plans to address some of these issues? Is there a need to start a Wiki page to document these and other related syntax-processing issues?
Stephen
From: "Stephen Schaub" <[email protected]> Reply-To: [email protected] To: [email protected] Subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues Date: Fri, 28 Oct 2005 09:46:13 -0400
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:
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 [email protected] mailing list. To unsubscribe: mailto:[email protected] For general help: mailto:[email protected]?subject=help ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
participants (8)
-
Cody Burleson -
Erwan Arzur -
Hans Gerwitz -
Ludovic Dubost -
Stephen Schaub -
Steve Bishop -
Trevor Cox -
Youcef BEY