Hi Guillaume L, On Mon, Nov 17, 2008 at 7:55 PM, Guillaume Lerouge <[email protected]>wrote:

Hi Asiri,

I just tested it and got an exception: http://91.121.237.216/xwiki/bin/view/Test/WikiDeveloppeurs

I can send you the original file if you wish. Could the exception be related to the presence of bulleted lists in the original document? I checked the JIRA issue related to lists but it didn't seem to be the same one.

Nope, this seems to be a different issue. This is the exception thrown at the back-end : <dump> org.xwiki.velocity.XWikiVelocityException: Failed to evaluate content with id [/templates/contentview.vm] at org.xwiki.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:187) at org.xwiki.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:143) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:107) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1600) at com.xpn.xwiki.api.XWiki.parseTemplate(XWiki.java:654) at sun.reflect.GeneratedMethodAccessor107.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:295) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at org.apache.velocity.runtime.directive.VelocimacroProxy.render(VelocimacroProxy.java:194) at org.apache.velocity.runtime.parser.node.ASTDirective.render(ASTDirective.java:170) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:74) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:88) at org.apache.velocity.runtime.parser.node.ASTBlock.render(ASTBlock.java:74) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at org.apache.velocity.runtime.parser.node.ASTIfStatement.render(ASTIfStatement.java:107) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at org.xwiki.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:178) at org.xwiki.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:143) at com.xpn.xwiki.render.XWikiVelocityRenderer.evaluate(XWikiVelocityRenderer.java:107) at com.xpn.xwiki.XWiki.parseTemplate(XWiki.java:1600) at com.xpn.xwiki.web.Utils.parseTemplate(Utils.java:124) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:226) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:115) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doGet(ActionServlet.java:414) at javax.servlet.http.HttpServlet.service(HttpServlet.java:596) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.xpn.xwiki.plugin.webdav.DavFilter.doFilter(DavFilter.java:68) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at com.xpn.xwiki.wysiwyg.server.filter.ConversionFilter.doFilter(ConversionFilter.java:96) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at com.xpn.xwiki.web.SavedRequestRestorerFilter.doFilter(SavedRequestRestorerFilter.java:287) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getRenderedContent' in class com.xpn.xwiki.api.Document threw exception com.xpn.xwiki.XWikiException: Error number 0 in 4: Failed to render content using new rendering system Wrapped Exception: Failed to parse input source @ /templates/contentview.vm[7,7] at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:286) at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:203) at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:294) at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:318) at org.xwiki.velocity.DefaultVelocityEngine.evaluate(DefaultVelocityEngine.java:178) ... 55 more Caused by: com.xpn.xwiki.XWikiException: Error number 0 in 4: Failed to render content using new rendering system Wrapped Exception: Failed to parse input source at com.xpn.xwiki.doc.XWikiDocument.getRenderedContentUsingNewRenderingModule(XWikiDocument.java:531) at com.xpn.xwiki.doc.XWikiDocument.getRenderedContent(XWikiDocument.java:470) at com.xpn.xwiki.api.Document.getRenderedContent(Document.java:367) at sun.reflect.GeneratedMethodAccessor220.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:585) at org.apache.velocity.util.introspection.UberspectImpl$VelMethodImpl.invoke(UberspectImpl.java:295) at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:245) ... 59 more </dump> Thanks for sending the original document :) I will track this down and let you know. - Asiri

Guillaume

On Mon, Nov 17, 2008 at 12:57 PM, Asiri Rathnayake < [email protected]> wrote:

...

Hi All,

I have setup a test server for testing the new xwiki-office-importer feature @ http://91.121.237.216/xwiki/bin/view/Main/

Please note that this is the same server used for testing xwiki-webdav interface.

Known issues for office-importer :

* Table support is limited due to : http://jira.xwiki.org/jira/browse/XWIKI-2804 & http://jira.xwiki.org/jira/browse/XWIKI-2834 * List support is limited due to : http://jira.xwiki.org/jira/browse/XWIKI-2812 * Image links (links with images as labels) are not supported yet : http://jira.xwiki.org/jira/browse/XWIKI-2832

Please help us improve office importer by testing it out and reporting as many bugs as you can ;)

Thanks.

- Asiri _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/ _______________________________________________ users mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/users

Hi, On Nov 18, 2008, at 6:04 AM, Asiri Rathnayake wrote:

Hi Guillaume,

On Mon, Nov 17, 2008 at 7:55 PM, Guillaume Lerouge <[email protected]

...

wrote:

...

Hi Asiri,

I just tested it and got an exception: http://91.121.237.216/xwiki/bin/view/Test/WikiDeveloppeurs

I can send you the original file if you wish. Could the exception be related to the presence of bulleted lists in the original document? I checked the JIRA issue related to lists but it didn't seem to be the same one.

It's the following content that is causing the exception to be thrown :

Par exemple:*#if($context.user == «XWiki.Admin»)Vous êtes l'administrateur par défaut de ce wiki!#else Vous êtes un utilisateur classique.#end*

[snip]

The issue here is that the rendering mechanism thinks "exemple://#if($context.user ...." is a url and tries to parse it...

I think this is something that has to be handled in the rendering module. We'll wait for vincent's opinion on this.

First, a comment: * I'm currently working on error handling and this error will be reported inline with an ErrorBlock and thus with a visual error where it happened in the very near future. The format for an inline link is (scheme):(something) However for URIs, only some are considered valid: mailto, image, attach For URL (i.e of the form (scheme)://(something) there's no check currently and all are considered URLs and checked to be valid. The reason we don't check for validity is because there can be any number of valid URL schemes (for example skype:// is a valid scheme if you've registered skype URL in your browser). I don't see any solution for this except not allowing inline links but I'm not sure this is a good solution. I think the inline error handling is the best solution and the user will use {{{exemple://#if($context.user..}}} if we really wants to enter this text. WDYT? Thanks -Vincent

On Nov 18, 2008, at 10:54 AM, Sergiu Dumitriu wrote:

Vincent Massol wrote:

...

Hi,

On Nov 18, 2008, at 6:04 AM, Asiri Rathnayake wrote:

...

Hi Guillaume,

On Mon, Nov 17, 2008 at 7:55 PM, Guillaume Lerouge <[email protected]

...

wrote: Hi Asiri,

I just tested it and got an exception: http://91.121.237.216/xwiki/bin/view/Test/WikiDeveloppeurs

I can send you the original file if you wish. Could the exception be related to the presence of bulleted lists in the original document? I checked the JIRA issue related to lists but it didn't seem to be the same one.

It's the following content that is causing the exception to be thrown :

Par exemple:*#if($context.user == «XWiki.Admin»)Vous êtes l'administrateur par défaut de ce wiki!#else Vous êtes un utilisateur classique.#end*

[snip]

...

The issue here is that the rendering mechanism thinks "exemple://#if($context.user ...." is a url and tries to parse it...

I think this is something that has to be handled in the rendering module. We'll wait for vincent's opinion on this.

First, a comment: * I'm currently working on error handling and this error will be reported inline with an ErrorBlock and thus with a visual error where it happened in the very near future.

The format for an inline link is (scheme):(something)

However for URIs, only some are considered valid: mailto, image, attach For URL (i.e of the form (scheme)://(something) there's no check currently and all are considered URLs and checked to be valid.

The reason we don't check for validity is because there can be any number of valid URL schemes (for example skype:// is a valid scheme if you've registered skype URL in your browser).

I don't see any solution for this except not allowing inline links but I'm not sure this is a good solution.

I think the inline error handling is the best solution and the user will use {{{exemple://#if($context.user..}}} if we really wants to enter this text.

WDYT?

We should not try to let through every URL, but just a few we are sure are working: http, https, ftp, mailto. For the others, there's always copy/paste.

I don't quite agree. I should be able to enter a skype URL for example and since you can register any type of URL in your browser we can't filter them. What we could do though is test for the URL validity and if not valid then don't consider the element as a link. That is not very easy to implement but possible. I'm not sure I prefer this over displaying an inline error. Thanks -Vincent

Hi,



On Tue, Nov 18, 2008 at 5:12 PM, Sergiu Dumitriu <[email protected]> wrote:

> Vincent Massol wrote:
> > On Nov 18, 2008, at 10:54 AM, Sergiu Dumitriu wrote:
> >
> >> Vincent Massol wrote:
> >>> Hi,
> >>>
> >>> On Nov 18, 2008, at 6:04 AM, Asiri Rathnayake wrote:
> >>>
> >>>> Hi Guillaume,
> >>>>
> >>>> On Mon, Nov 17, 2008 at 7:55 PM, Guillaume Lerouge <
> [email protected]
> >>>>> wrote:
> >>>>> Hi Asiri,
> >>>>>
> >>>>> I just tested it and got an exception:
> >>>>> http://91.121.237.216/xwiki/bin/view/Test/WikiDeveloppeurs
> >>>>>
> >>>>> I can send you the original file if you wish. Could the exception
> >>>>> be
> >>>>> related
> >>>>> to the presence of bulleted lists in the original document? I
> >>>>> checked the
> >>>>> JIRA issue related to lists but it didn't seem to be the same one.
> >>>>>
> >>>>>
> >>>> It's the following content that is causing the exception to be
> >>>> thrown :
> >>>>
> >>>> Par exemple:*#if($context.user == «XWiki.Admin»)Vous êtes
> >>>> l'administrateur
> >>>> par défaut de ce wiki!#else Vous êtes un utilisateur classique.#end*
> >>> [snip]
> >>>
> >>>> The issue here is that the rendering mechanism thinks
> >>>> "exemple://#if($context.user
> >>>> ...." is a url and tries to parse it...
> >>>>
> >>>> I think this is something that has to be handled in the rendering
> >>>> module.
> >>>> We'll wait for vincent's opinion on this.
> >>> First, a comment:
> >>> * I'm currently working on error handling and this error will be
> >>> reported inline with an ErrorBlock and thus with a visual error where
> >>> it happened in the very near future.
> >>>
> >>> The format for an inline link is (scheme):(something)
> >>>
> >>> However for URIs, only some are considered valid: mailto, image,
> >>> attach
> >>> For URL (i.e of the form (scheme)://(something) there's no check
> >>> currently and all are considered URLs and checked to be valid.
> >>>
> >>> The reason we don't check for validity is because there can be any
> >>> number of valid URL schemes (for example skype:// is a valid scheme
> >>> if
> >>> you've registered skype URL in your browser).
> >>>
> >>> I don't see any solution for this except not allowing inline links
> >>> but
> >>> I'm not sure this is a good solution.
> >>>
> >>> I think the inline error handling is the best solution and the user
> >>> will use {{{exemple://#if($context.user..}}} if we really wants to
> >>> enter this text.
> >>>
> >>> WDYT?
> >> We should not try to let through every URL, but just a few we are sure
> >> are working: http, https, ftp, mailto. For the others, there's always
> >> copy/paste.
> >
> > I don't quite agree.
> >
> > I should be able to enter a skype URL for example and since you can
> > register any type of URL in your browser we can't filter them.
> >
> > What we could do though is test for the URL validity and if not valid
> > then don't consider the element as a link. That is not very easy to
> > implement but possible. I'm not sure I prefer this over displaying an
> > inline error.
> >
>
> Well, this time the user didn't do anything wrong. It just happened that
> the document contained an italic text after ':'. He will see the error
> and think that XWiki is faulty, not that he did something wrong. I
> certainly wouldn't like to receive such an error after importing a
> "simple" document.


I too agree with this. If the user was entering the wiki syntax himself, the
exception is acceptable. But here the exception is internal to us. Anyway,
working around this problem from the office-importer code might be possible,
but it would be ugly (searching for : followed by italics....).

Thanks.

- Asiri


>
>
> --
> Sergiu Dumitriu
> http://purl.org/net/sergiu/
> _______________________________________________
> devs mailing list
> [email protected]
> http://lists.xwiki.org/mailman/listinfo/devs
>

On Nov 18, 2008, at 1:00 PM, Vincent Massol wrote:

>
> On Nov 18, 2008, at 12:42 PM, Sergiu Dumitriu wrote:
>
> [snip]
>
>> Vincent Massol wrote:
>>> On Nov 18, 2008, at 10:54 AM, Sergiu Dumitriu wrote:
>>>
>>>> Vincent Massol wrote:
>>>>> Hi,
>>>>>
>>>>> On Nov 18, 2008, at 6:04 AM, Asiri Rathnayake wrote:
>>>>>
>>>>>> Hi Guillaume,
>>>>>>
>>>>>> On Mon, Nov 17, 2008 at 7:55 PM, Guillaume Lerouge <[email protected]
>>>>>>> wrote:
>>>>>>> Hi Asiri,
>>>>>>>
>>>>>>> I just tested it and got an exception:
>>>>>>> http://91.121.237.216/xwiki/bin/view/Test/WikiDeveloppeurs
>>>>>>>
>>>>>>> I can send you the original file if you wish. Could the  
>>>>>>> exception
>>>>>>> be
>>>>>>> related
>>>>>>> to the presence of bulleted lists in the original document? I
>>>>>>> checked the
>>>>>>> JIRA issue related to lists but it didn't seem to be the same  
>>>>>>> one.
>>>>>>>
>>>>>>>
>>>>>> It's the following content that is causing the exception to be
>>>>>> thrown :
>>>>>>
>>>>>> Par exemple:*#if($context.user == «XWiki.Admin»)Vous êtes
>>>>>> l'administrateur
>>>>>> par défaut de ce wiki!#else Vous êtes un utilisateur  
>>>>>> classique.#end*
>>>>> [snip]
>>>>>
>>>>>> The issue here is that the rendering mechanism thinks
>>>>>> "exemple://#if($context.user
>>>>>> ...." is a url and tries to parse it...
>>>>>>
>>>>>> I think this is something that has to be handled in the rendering
>>>>>> module.
>>>>>> We'll wait for vincent's opinion on this.
>>>>> First, a comment:
>>>>> * I'm currently working on error handling and this error will be
>>>>> reported inline with an ErrorBlock and thus with a visual error  
>>>>> where
>>>>> it happened in the very near future.
>>>>>
>>>>> The format for an inline link is (scheme):(something)
>>>>>
>>>>> However for URIs, only some are considered valid: mailto, image,
>>>>> attach
>>>>> For URL (i.e of the form (scheme)://(something) there's no check
>>>>> currently and all are considered URLs and checked to be valid.
>>>>>
>>>>> The reason we don't check for validity is because there can be any
>>>>> number of valid URL schemes (for example skype:// is a valid  
>>>>> scheme
>>>>> if
>>>>> you've registered skype URL in your browser).
>>>>>
>>>>> I don't see any solution for this except not allowing inline links
>>>>> but
>>>>> I'm not sure this is a good solution.
>>>>>
>>>>> I think the inline error handling is the best solution and the  
>>>>> user
>>>>> will use {{{exemple://#if($context.user..}}} if we really wants to
>>>>> enter this text.
>>>>>
>>>>> WDYT?
>>>> We should not try to let through every URL, but just a few we are  
>>>> sure
>>>> are working: http, https, ftp, mailto. For the others, there's  
>>>> always
>>>> copy/paste.
>>>
>>> I don't quite agree.
>>>
>>> I should be able to enter a skype URL for example and since you can
>>> register any type of URL in your browser we can't filter them.
>>>
>>> What we could do though is test for the URL validity and if not  
>>> valid
>>> then don't consider the element as a link. That is not very easy to
>>> implement but possible. I'm not sure I prefer this over displaying  
>>> an
>>> inline error.
>>>
>>
>> Well, this time the user didn't do anything wrong.
>
> I don't agree. He did not follow the defined wiki syntax so he did  
> something wrong and we need to tell him/her.
>
>> It just happened that
>> the document contained an italic text after ':'. He will see the  
>> error
>> and think that XWiki is faulty, not that he did something wrong. I
>> certainly wouldn't like to receive such an error after importing a
>> "simple" document.
>
> The import is a different matter. I was talking about the wiki  
> syntax here. For the import I don't understand since you'll never  
> get a link if you the original document didn't have a <a href="">  
> element so this can't happen since it'll be considered as text.

Ok I understand now. It's imported as text and saved in wiki syntax as  
normal text. When rendered later in XHTML it's parsed again and then  
this time considered an inline element and rendered accordingly.

So the real solution is that the XHTML parser should either generate a  
verbatim block event or simply escape the ":" with "\:".

I'll add a unit test for this to see how it goes.

Thanks
-Vincent

On Tue, Nov 18, 2008 at 1:21 PM, Vincent Massol <[email protected]> wrote:

On Nov 18, 2008, at 1:03 PM, Vincent Massol wrote:

[snip]

...

...

...

...

...

> WDYT? We should not try to let through every URL, but just a few we are sure are working: http, https, ftp, mailto. For the others, there's always copy/paste.

I don't quite agree.

I should be able to enter a skype URL for example and since you can register any type of URL in your browser we can't filter them.

What we could do though is test for the URL validity and if not valid then don't consider the element as a link. That is not very easy to implement but possible. I'm not sure I prefer this over displaying an inline error.

Well, this time the user didn't do anything wrong.

I don't agree. He did not follow the defined wiki syntax so he did something wrong and we need to tell him/her.

...

It just happened that the document contained an italic text after ':'. He will see the error and think that XWiki is faulty, not that he did something wrong. I certainly wouldn't like to receive such an error after importing a "simple" document.

The import is a different matter. I was talking about the wiki syntax here. For the import I don't understand since you'll never get a link if you the original document didn't have a <a href=""> element so this can't happen since it'll be considered as text.

Ok I understand now. It's imported as text and saved in wiki syntax as normal text. When rendered later in XHTML it's parsed again and then this time considered an inline element and rendered accordingly.

So the real solution is that the XHTML parser should either generate a verbatim block event or simply escape the ":" with "\:".

I'll add a unit test for this to see how it goes.

Actually this is working fine. Here's the test:

.#------------------------------------------------------------------------------------------- .input|xhtml/1.0

.#------------------------------------------------------------------------------------------- <html>something://whatever</html> .#----------------------------------------------------- .expect|event .#----------------------------------------------------- beginDocument beginParagraph onWord [something] onSpecialSymbol [:] onEscape [/] onEscape [/] onWord [whatever] endParagraph endDocument .#----------------------------------------------------- .expect|xwiki .#----------------------------------------------------- something:~/~/whatever

So I don't know what's wrong. Asiri could you dig?

Maybe we should ask Guillaume whether he entered this manually after the import? :)

Nope, I didn't touch the file, I simply selected it in my file browser and uploaded it as is. I didn't do anything special afterwards, I simply tried to access the page where it was imported. Guillaume

Thanks -Vincent _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs

-- Guillaume Lerouge Product Manager - XWiki Skype ID : wikibc http://blog.xwiki.com/

On Nov 18, 2008, at 6:19 PM, Asiri Rathnayake wrote:

Hi Vincent,

On Tue, Nov 18, 2008 at 5:51 PM, Vincent Massol <[email protected]> wrote:

...

On Nov 18, 2008, at 1:03 PM, Vincent Massol wrote:

[snip]

...

...

...

...

>> WDYT? > We should not try to let through every URL, but just a few we > are sure > are working: http, https, ftp, mailto. For the others, there's > always > copy/paste.

I don't quite agree.

I should be able to enter a skype URL for example and since you can register any type of URL in your browser we can't filter them.

What we could do though is test for the URL validity and if not valid then don't consider the element as a link. That is not very easy to implement but possible. I'm not sure I prefer this over displaying an inline error.

Well, this time the user didn't do anything wrong.

I don't agree. He did not follow the defined wiki syntax so he did something wrong and we need to tell him/her.

...

It just happened that the document contained an italic text after ':'. He will see the error and think that XWiki is faulty, not that he did something wrong. I certainly wouldn't like to receive such an error after importing a "simple" document.

The import is a different matter. I was talking about the wiki syntax here. For the import I don't understand since you'll never get a link if you the original document didn't have a <a href=""> element so this can't happen since it'll be considered as text.

Ok I understand now. It's imported as text and saved in wiki syntax as normal text. When rendered later in XHTML it's parsed again and then this time considered an inline element and rendered accordingly.

So the real solution is that the XHTML parser should either generate a verbatim block event or simply escape the ":" with "\:".

I'll add a unit test for this to see how it goes.

Actually this is working fine. Here's the test:

.#------------------------------------------------------------------------------------------- .input|xhtml/1.0

.#------------------------------------------------------------------------------------------- <html>something://whatever</html> .#----------------------------------------------------- .expect|event .#----------------------------------------------------- beginDocument beginParagraph onWord [something] onSpecialSymbol [:] onEscape [/] onEscape [/] onWord [whatever] endParagraph endDocument .#----------------------------------------------------- .expect|xwiki .#----------------------------------------------------- something:~/~/whatever

So I don't know what's wrong. Asiri could you dig?

This test case doesn't address the problem we are facing. The input should be xwiki/2.0 not html.

As I said before, the html input is :

<p>Par exemple:<i>#if($context.user == «XWiki.Admin»)Vous êtes l'administrateur par défaut de ce wiki!#else Vous êtes un utilisateur classique.#end</i></p>

This is HTML AFAIK and not wiki syntax so the input is indeed HTML.

And this get's converted into xwiki/2.0 syntax as :

Par exemple://#if($context.user == «XWiki.Admin»)Vous êtes l'administrateur par défaut de ce wiki!#else Vous êtes un utilisateur classique.#end//

This is where the url like format appears .

I see the problem. So we need somehow to get the following instead: Par exemple~://#if($context.user == "XWiki.Admin")Vous l'administrateur par dŽfaut de ce wiki!#else Vous un utilisateur classique.#end// I think this could be addressed with some rule like the following in the XHTML parser: * if there's a ":" character and if the next element is an italic start tag then escape the ":" with "~:" I'm already doing several checks in XWikiXhtmlEscapeHandler to automatically escape characters so that they are not mistaken for wiki syntax. Could you please create a jira issue for this with the content of this discussion? BTW the issue should be more generic since we have the same problem with the following input for example: <html><p>mailto:[email protected]</p></html> This should generate the following in wiki syntax; mailto~:[email protected] So basically any inline link format should get the ":" escaped when parsed by the XHTML parser. Thanks -Vincent

Thanks.

- Asiri

...

Maybe we should ask Guillaume whether he entered this manually after the import? :)

Thanks -Vincent

Hi,

<p>Par exemple:<i>#if($context.user == «XWiki.Admin»)Vous êtes

...

l'administrateur par défaut de ce wiki!#else Vous êtes un utilisateur classique.#end</i></p>

This is HTML AFAIK and not wiki syntax so the input is indeed HTML.

I meant the output you get once you parse this html content via xhtml->xwiki parser. That output contains the "://" sequence.

...

And this get's converted into xwiki/2.0 syntax as :

Par exemple://#if($context.user == «XWiki.Admin»)Vous êtes l'administrateur par défaut de ce wiki!#else Vous êtes un utilisateur classique.#end//

This is where the url like format appears .

I see the problem. So we need somehow to get the following instead:

Par exemple~://#if($context.user == "XWiki.Admin")Vous l'administrateur par dŽfaut de ce wiki!#else Vous un utilisateur classique.#end//

I think this could be addressed with some rule like the following in the XHTML parser: * if there's a ":" character and if the next element is an italic start tag then escape the ":" with "~:"

I'm already doing several checks in XWikiXhtmlEscapeHandler to automatically escape characters so that they are not mistaken for wiki syntax.

Could you please create a jira issue for this with the content of this discussion?

BTW the issue should be more generic since we have the same problem with the following input for example:

<html><p>mailto:[email protected]</p></html>

This should generate the following in wiki syntax;

mailto~:[email protected]

So basically any inline link format should get the ":" escaped when parsed by the XHTML parser.

Ok, I will raise a jira issue for this. Falling asleep. Good night. - Asiri

Hi Guillaume L, How do you handle cases when the target document already exists? Right now I

only receive an unhelpful error message ("you are not authorized to perform this action").

Yes, I didn't update this code yet. We need to provide a descent error message.

...

Sample document imported (styles filtered) : http://91.121.237.216/xwiki/bin/view/Import/NoStyles

(% align="JUSTIFY" class="western" %) is still present even though it does not seem to bring useful information (since added text should follow the wiki conventions regarding text alignement and font: those shoulmd be the same on every page for the wiki, thus the wiki's default should prevail on those from the original file when converting to wiki wyntax with no styles).

...

Sample document imported (styles preserved) : http://91.121.237.216/xwiki/bin/view/Import/WithStyles

I have a small bug here: a text element that has underlined + bold + italics + color + background color is rendered as bold + italics + underlined in no styles (so far so good) but the same element is rendered italics + bold + background color but without color and underlined in withstyles mode.

Both of these issues will be handled when we introduce strict style filtering. Thank you very much for testing office-importer. :) - Asiri

Hi Vincent,

This should be done now (for 1.7) and not wait for later.

Yes, i'm implementing syntax filtering (severe) from tomorrow onwards. It won't take much time. Thanks. - Asiri

Hi Devs, Users, I have uploaded yet another new version of office-importer @ http://91.121.237.216/xwiki/bin/view/Import/. This version utilizes the latest rendering module which has improved a lot since the last upload. Also a moderate style filtering option is introduced. Please try it out and let us know what you think. Thanks. - Asiri