On 07/07/2010 06:03 PM, Thomas Mortagne wrote:
> Yes there are (sadly common) bugs and feel free to report any one you can
> find.
>
> The main issue is that wiki link syntax [[ ]] does not support enough
> things which leads use to use html macro where we should not. See
>
> For the workaround, the easiest and most effective solutions currently are:
> 1) make sure you really need that "wiki=true"
> 2) make sure you can't write this link using wiki syntax
> 2) if you can't get rid of it put a sub {{html}} macro around the link like in
> {{html wiki=true}}
> * some list item with a {{html}}<a
> href="http://another.space.toom.su/";>link</a>{{/html}}
> {{/html}}
You can also escape XWiki syntax special characters if you have access
to the source:
href="http:~/~/another.space.toom.su/"
Hope this helps,
Marius
>
> On Wed, Jul 7, 2010 at 16:52, Ivan Levashew<[email protected]> wrote:
>> Ivan Levashew wrote:
>>> Does anybody had this idea before?
>>>
>>> I'd like to establish the mapping as follows:
>>>
>>> http://something.metrolace.ru/Page ->
>>> http://metrolace.ru/bin/view/Something/Page/
>>>
>>> http://something.another.metrolace.ru/ ->
>>> http://metrolace.ru/bin/view/SomethingAnother/WebHome/
>>>
>>> That is, the whole domain is a collaborative wiki with
>>> pretty short URLs. New domains are being created on demand
>>> because they are essentially good old Spaces.
>>>
>>> I'm going to use url_rewrite in Squid (in particular, because I
>>> don't know why it's so difficult to get rid of /bin/) and custom
>>> XWikiURLFactory implementation.
>>>
>>> Any advices? Did somebody already write custom URLFactory before?
>>>
>>
>> If anyone is wondering about this, it was almost enough to rewrite
>> ServletURLFactory.
>>
>> Bad news is that XWiki pages often misbehave when URLs are not relative.
>> This is due to {{html wiki="true"}} being commonly used everywhere.
>> Things like<a href="$xwiki.getURL(... work nice when URLs are relative.
>> <a href="/bin/view/Main/"> remains unchanged after applying wiki parser.
>> However,<a href="http://another.space.toom.su/";> gets messed because<a
>> href="http://another.space.toom.su/";> turns into<a href=""><span
>> class="wikiexternallink"><a class="wikimodel-freestanding"
>> href="http://another.space.toom.su/";><span
>> class="wikigeneratedlinkcontent">http://another.space.toom.su/</span></a></span>
>>
>> Another bad news is that tricks like<a href="//another.space.toom.su/">
>> didn't work. They are also being changed by XWiki parser, this time it
>> creates<em> tag which again messes everything.
>>
>> I've done my best to make most troublesome URLs relative. E. g. "get"
>> URLs are always relative due to AJAX crossdomain restrictions. Still
>> there are some dark corners where the problem can't be workarounded by
>> just tweaking my servlet URL factory implementation without completely
>> sacrificing multidomain illusion. This bug (it is, isn't it?) looks like
>> this:
>>
>> http://www.peeep.us/2aded8d0
>>
>> Should it be fixed?
>>
>> When I was fixing Main.Spaces I thought there should be something like
>> {{wiki}} or better<wiki> in html mode.<wiki> is better because
>> xmlescape encodes<> in Velocity output.
>>
>> Having both systems in effect is glitches-prone. Not having<wiki> makes
>> proper introducing wiki fragments annoying. In the Main.Spaces wiki
>> engine is only used to reference WebHome of every space. I've got to put
>> {{html wiki="false"}} in several places instead of putting<wiki> in
>> just one.
>>
>> --
>> If you want to get to the top, you have to start at the bottom
>>
>> _______________________________________________
>> users mailing list
>> [email protected]
>> http://lists.xwiki.org/mailman/listinfo/users
>>
>
>
>
_______________________________________________
users mailing list
[email protected]
http://lists.xwiki.org/mailman/listinfo/users
