On 2/2/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> Josias Thoeny wrote:
>
> [...]
>
> >> On the contrary, I believe that LinkRewritingTransformer should handle
> >> more types of links, not less. It should transform all types of
> >> relative and absolute URI's and not just the ones that other parts of
> >> Lenya happen to produce. That includes the following forms:
> >>
> >> foo.bar
> >> ../foo.bar
> >> dir/foo.bar
> >> dir1/../dir2/foo.bar
> >> /CONTEXT/dir/foo.bar
> >> SCHEME://host.domain.xyz/CONTEXT/dir/foo.bar
> >>
> >> where host.domain.xyz matches the current host name.
> >>
> >> Editors can (and should be able to) introduce links in a page using
> >> whatever URI syntax is valid (including cut-and-paste from other
> >> sources), and LinkRewritingTransformer should adjust them correctly,
> >> according to the rules the site manager wants. Some sight managers
> >> want all URI's to start with "/". Others prefer the use of ../..
> >> links. There are arguments to be made for each philosophy, and the
> >> CMS shouldn't prohibit either. (There should probably be optional
> >> parameters passed to the transformer to control some behaviors
> >> according to the needs of the site.)
> >
> > I don't quite agree with that,
>
> Same here. If your editor can't work with the Lenya link syntax,
> an import layer has to be added to transform the links. Supporting
> different link syntaxes would make it much harder to implement
> interoperable components.
That's fine, I'm not particular about where the link rewriting occurs.
Doing it at the point when the document is being saved or moved makes
the most sense to me anyway. But accounting for a variety of possibly
URI forms coming in from the editors seems like the right thing to do
for a robust CMS. So this leads me to think there should be three
distinct link rewriting events:
1) when a document is saved: rewrite all internal links (to both
documents and assets) be in the Lenya-standard form.
2) when a document is moved: rewrite all document-relative links to
be relative to the new location
3) when a document is displayed: verify the existance of each document
link's target and then specially style or erase those links that are
broken.
The first two seem to call for a more general version of
LinkRewritingTransformer that can look at URL's in any of the several
forms and convert them to any one of the other forms, with a parameter
specifying which form to output. The third might be unneeded when we
have a link management capability.
> [...]
>
> >> <img src="foo">
> >> <script src="foo">
> >> <object data="foo">
> >> <meta http-equiv="refresh" content="2;url=foo">
> >> <link href="foo">
> >> <embed src="foo">
> >> <form action="foo">
> >> ...and maybe a few others
> >> (In fact, all href attributes of *any* element probably ought to be
> >> rewritten, if we want to be forward-looking).
>
> How is this ideally declared? At the moment, there's the
> link-attribute XPath property of the resource type. Is this
> sufficient? Or should we use something like i18n:
>
> <a href="..." link:attr="href"/>
> <img src="..." link:attr="src"/>
>
> I don't like this option that much, because it requires adding
> special declarations to the XML schema.
>
> I guess we can't just look for a protocol in all attributes
> (e.g., <a href="link://{uuid}"/>), can we?
>
>
> > Basically, I agree here.
> > But since Lenya knows only about document urls, it's not so easy to
> > implement.
> > The way I wanted to handle this is to pass the correct base url to the
> > xsl instead of the current $root parameter.
>
> +1
>
> -- Andreas
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
