On Thu, 2006-02-02 at 13:49 -0500, Bob Harner wrote: > 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.
Yes, that would be good. All editors should use the same link format for the sake of consistency. > > 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? Well, assets in Lenya always belong to a specific document, and the links (href="foo.pdf") are always relative to that document. If you move the document, the assets are moved as well, so the links should be ok. Making a link to an asset of a different document is currently "not supported, that means the link will break in the following cases: 1. the link is relative and the document containing the link is moved. 2. the link is absolute or relative and the document with the asset is moved. I'm not sure what to do about that. Let's hope that we will have centralized asset management one day, which should also solve this problem. > > BTW, Josias, in the LinkRewritingTransformer.java that you checked in > a couple hours ago, you forgot to update the header documentation. Right, I forgot that. It's fixed now. Thanks a lot for spotting! Josias > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
