28 Oct
2005
28 Oct
'05
3:46 p.m.
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
28 Oct
28 Oct
6:59 p.m.
New subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues
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(a)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 <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 xwiki-dev(a)objectweb.orgmailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
8:43 p.m.
New subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues
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(a)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(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto: sympa(a)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(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/
wws
10:09 p.m.
New subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues
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
6 Nov
6 Nov
11:34 p.m.
New subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues
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 :
--
Ludovic Dubost
XPertNet: http://www.xpertnet.fr/
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost AIM: nvludo Yahoo: ludovic
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
------------------------------------------------------------------------
--
You receive this message as a subscriber of the xwiki-dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
7 Nov
7 Nov
8:42 a.m.
New subject: 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
8 Nov
8 Nov
11:45 p.m.
New subject: [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: cburleso(a)us.ibm.com
"Youcef BEY" <youcefb(a)grad.nii.ac.jp>
11/07/2005 02:42 AM
Please respond to
xwiki-dev(a)objectweb.org
To
<xwiki-dev(a)objectweb.org>
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 xwiki-dev(a)objectweb.org
mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
11:58 p.m.
New subject: [xwiki-dev] Problem with class creation
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: xwiki-dev(a)objectweb.org
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: cburleso(a)us.ibm.com
"Youcef BEY" <youcefb(a)grad.nii.ac.jp>
11/07/2005 02:42 AM Please respond to
xwiki-dev(a)objectweb.org
To <xwiki-dev(a)objectweb.org>
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 xwiki-dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@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(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
10 Nov
10 Nov
1:40 p.m.
New subject: [xwiki-dev] Problem with class creation
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: xwiki-dev(a)objectweb.org
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: cburleso(a)us.ibm.com
"Youcef BEY" <youcefb(a)grad.nii.ac.jp>
11/07/2005 02:42 AM Please respond to
xwiki-dev(a)objectweb.org
To <xwiki-dev(a)objectweb.org>
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 xwiki-dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@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(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
18 Nov
18 Nov
4:31 p.m.
New subject: Creating documents
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-
dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/
wws
- - -
Hans Gerwitz
http://phobia.com/
8 Nov
8 Nov
3:39 p.m.
New subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues
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 <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
>
>
10 Nov
10 Nov
11:25 a.m.
New subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues
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
--
Ludovic Dubost
XPertNet: http://www.xpertnet.fr/
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost AIM: nvludo Yahoo: ludovic
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
>
>
------------------------------------------------------------------------
--
You receive this message as a subscriber of the xwiki-dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
2 Nov
2 Nov
5:51 p.m.
New subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues
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"
<stephen_schaub_88(a)hotmail.com>
Reply-To: xwiki-dev(a)objectweb.org
To: xwiki-dev(a)objectweb.org
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
3 Nov
3 Nov
1:49 a.m.
New subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues
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
--
Ludovic Dubost
XPertNet: http://www.xpertnet.fr/
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost AIM: nvludo Yahoo: ludovic
From: "Stephen Schaub"
<stephen_schaub_88(a)hotmail.com>
Reply-To: xwiki-dev(a)objectweb.org
To: xwiki-dev(a)objectweb.org
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 xwiki-dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
4 p.m.
New subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues
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 <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: 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" <stephen_schaub_88(a)hotmail.com>
>>Reply-To: xwiki-dev(a)objectweb.org
>>To: xwiki-dev(a)objectweb.org
>>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]
8 Nov
8 Nov
12:50 a.m.
New subject: [xwiki-dev] Groovy, Velocity, and XWiki syntax processing issues
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"
<stephen_schaub_88(a)hotmail.com>
Reply-To: xwiki-dev(a)objectweb.org
To: xwiki-dev(a)objectweb.org
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 xwiki-dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
6869
days inactive
6890
days old
15 comments
8 participants
participants (8)
-
Cody Burleson -
Erwan Arzur -
Hans Gerwitz -
Ludovic Dubost -
Stephen Schaub -
Steve Bishop -
Trevor Cox -
Youcef BEY