On 2/2/06, Andreas Hartmann <[EMAIL PROTECTED]> wrote:
> Bob Harner wrote:
>
> [...]
>
> > 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.
>
> Yes, that would be the responsibility of the editor component or
> an import mechanism. But I wouldn't call it link rewriting.
>
>
> > 2) when a document is moved: rewrite all document-relative links to
> > be relative to the new location
>
> IMO no relative links should be supported, only UUIDs. Link rewriting
> when a document is moved requires parsing and locking all involved
> documents, which I'd try to avoid if possible.
>
>
> > 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.
>
> That should be the only place where link rewriting (or rather resolving)
> occurs. Performance issues should be solved by indexing, caching etc.
>
>
> > 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,
>
> No, it shouldn't be implemented in a centralized way. The editor
> component itself has to take care of it. This provides flexibility
> and extensibility without adding code to the core. You can't provide
> a core component which has the knowledge about the link syntax of
> various editors.
>
>
> > with a parameter
> > specifying which form to output. The third might be unneeded when we
> > have a link management capability.
>
> IMO the second becomes unneeded when we have a link management
> capability.
>
> [...]
>
> -- Andreas
I concede that you guys are right. It took a while for me to fully
realize what you were saying -- that by contract the content xml files
must contain only one very specific URl format for the <a href="foo">
links -- namely, "/pubid/area/docid.html", with the servlet context
(if any) REMOVED. (Is this *documented* anywhere? This is a rather
weird an unexpected behavior to be left undocumented, although I now
understand the thinking.)
I guess I need to adjust the FCKeditor implementation so that it
produces content xml files without the servlet context.
There is still a small issue with assets, though. As I understand it,
they must be document-relative URI's, right? Kupu seems to make image
tags like this:
<object data="foo.jpg" title="foo.jpg" type=""/>
BXE makes image tags like this:
<object href="" title="foo.jpg" type="image/jpeg" data="foo.jpg"/>
BXE makes asset hyperlinks like this:
<a href="foo.pdf" title="bar">a pdf file</a>
And what if a document with a link like "../foo.pdf" moves? That
would make a broken link. So I guess I still see a need for a
generalized link rewriter. Links have to be rewritten multiple places
(e.g. in StaticHTMLExporter, and when moving a file). One would think
somebody has already written something like that somewhere in the
world. Maybe Forest has such a capability?
BTW, Josias, in the LinkRewritingTransformer.java that you checked in
a couple hours ago, you forgot to update the header documentation.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
