Groovy, Velocity, and XWiki syntax processing issues

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Groovy, Velocity, and XWiki syntax processing issues

Stephen Schaub
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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Groovy, Velocity, and XWiki syntax processing issues

zuzur
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 <[hidden email]> 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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Groovy, Velocity, and XWiki syntax processing issues

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

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


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 <[hidden email]> 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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

smime.p7s (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Groovy, Velocity, and XWiki syntax processing issues

Stephen Schaub
In reply to this post by zuzur
>On 10/28/05, Stephen Schaub <[hidden email]> 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 <[hidden email]>

>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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

RE: Groovy, Velocity, and XWiki syntax processing issues

Stephen Schaub
In reply to this post by Stephen Schaub
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" <[hidden email]>
>Reply-To: [hidden email]
>To: [hidden email]
>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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Groovy, Velocity, and XWiki syntax processing issues

Ludovic Dubost

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" <[hidden email]>
>> Reply-To: [hidden email]
>> To: [hidden email]
>> 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 [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?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




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Groovy, Velocity, and XWiki syntax processing issues

Stephen Schaub
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 <[hidden email]>
>Reply-To: [hidden email]
>To: [hidden email]
>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" <[hidden email]>
>>>Reply-To: [hidden email]
>>>To: [hidden email]
>>>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 receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Groovy, Velocity, and XWiki syntax processing issues

Ludovic Dubost
In reply to this post by Stephen Schaub

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 <[hidden email]> 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 <[hidden email]>
>
>> 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 [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?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




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Problem with class creation

Youcef Bey
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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Groovy, Velocity, and XWiki syntax processing issues

Trevor Cox
In reply to this post by Stephen Schaub
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 &lt; instead of < or &amp; 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" [hidden email]
Reply-To: [hidden email]
To: [hidden email]
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 [hidden email] mailing list. To unsubscribe: [hidden email] For general help: [hidden email] ObjectWeb mailing lists service home page: http://www.objectweb.org/wws


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Groovy, Velocity, and XWiki syntax processing issues

Stephen Schaub
In reply to this post by Ludovic Dubost
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 <[hidden email]>
>Reply-To: [hidden email]
>To: [hidden email]
>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 <[hidden email]> 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 <[hidden email]>
>>
>>>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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Problem with class creation

cburleso
In reply to this post by Youcef Bey

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: [hidden email]




"Youcef BEY" <[hidden email]>

11/07/2005 02:42 AM

Please respond to
[hidden email]

To
<[hidden email]>
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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Problem with class creation

Steve Bishop
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.
----- Original Message -----
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: [hidden email]




"Youcef BEY" <[hidden email]>

11/07/2005 02:42 AM

Please respond to
[hidden email]

To
<[hidden email]>
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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Groovy, Velocity, and XWiki syntax processing issues

Ludovic Dubost
In reply to this post by Stephen Schaub

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 <[hidden email]>
>> Reply-To: [hidden email]
>> To: [hidden email]
>> 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 <[hidden email]> 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 <[hidden email]>
>>>
>>>> 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 [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?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




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: Problem with class creation

Youcef Bey
In reply to this post by cburleso
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 -----
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: [hidden email]




"Youcef BEY" <[hidden email]>

11/07/2005 02:42 AM

Please respond to
[hidden email]

To
<[hidden email]>
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 [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws


--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Creating documents

Hans Gerwitz
In reply to this post by Youcef Bey
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


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
:

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 [hidden email] mailing list.
To unsubscribe: [hidden email]
For general help: [hidden email]
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws



- - -
Hans Gerwitz




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws

smime.p7s (2K) Download Attachment