SilvaDocument: relative links are not handled correctly

Assigning this to JW. I don't think we should always use absolute url as
care was actually taken to support relative views.. JW should have a
better idea of the issues involved here, I hope.

I thought that indeed we wanted to support relative links. E.g. to not make
moving/renaming folders break links to images, files and hyperlinks. But maybe I
just do not understand the issue in the first place - Zagy, could you elaborate
some more?

The problem is *not* storing relative references. The problem is *not* rendering
relative references.

The problem is rendering *wrong* relative references. As stated before you'll
get relative URLs like doc/edit/foo or doc/foo while foo is the same container
as doc. This only works due to Zope acquisition.

To get the relative links right in the public view, something like

<base href="." tal:attributes="href python:'%s/'
%here.get_container().absolute_url()" />

in the layout_marco.html would hepl. (I guess I have suggested this on some
mailinglist, but I forgot, where ...)

Unfortunately this does not work in the SMI, because all the forms
e.g. in the metadata and publish tab would be broekn, as their
action is relative ... but maybe one can live with some shaken
up links here?

clemens is right, this seems to solve most cases. From my point of view this
issue could be resolved by putting the base in the default layout_template.

I'm currently working on better virtual host support in Silva. Part of this work
is some code in EditorSupport (SilvaDocument - on the
jw-deep_virtual_hosting_support-branch, at this moment still depending on
jw-deep_virtual_hosting_support-branch of Silva ) which tries to render an
absolute_url for objects referenced with an absolute or relative path in link
elements.

This would also solve this issue.

Could the nosies please have a look at the code?

zagy: I'm using a regex copied from silvaparser.py. Is this regex efficient for
this usage?

uhm, actually I posted this again in issue 800.

Resolving this one as issue 800 was resolved.