Hi Vincent,
On Tue, Nov 18, 2008 at 5:51 PM, Vincent Massol <vincent(a)massol.net>
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>
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:vincent@massol.net</p></html>
This should generate the following in wiki syntax;
mailto~:vincent@massol.net
So basically any inline link format should get the ":" escaped when
parsed by the XHTML parser.