As briefly discussed on the user list recently (subject: "Losing hyperlinks - what xsl removes them?"), the LinkRewritingTransformer seems to need some improvements so that it can rewrite all types of links. It currently only rewrites <a href="foo"> where foo is a document-relative URI. I'm sure I'm NOT the best person to do so (being much less familiar with 1.4 than 1.2.x), but I've been looking over the code and humbly offer the following initial thoughts. Your advise and guidance is eagerly sought...
1) <editorial>We have really overloaded the word "resource" in Lenya & Cocoon, haven't we? Sometimes it means "an asset or a CMS document" (per http://wiki.apache.org/lenya/ProposalArchitecture), or sometimes it specifically just an asset (per Resource.java). The word is also used in sitemap files to refer to a reusable part of a pipeline. Elsewhere it refers vaguely to a "miscellaneous relate file" (the lenya/resources dir). Sometimes it means the amount of memory, hard drive space, and CPU cycles available. And Document Types are now officially Resource Types. This overloading of terminology makes it harder to learn Lenya. I think "Content", "Content Item", and "Content Type" are probably much better terms for a CMS to use. Precise and unambiguous terminology always a good thing.</editorial> 2) As Andreas said a couple weeks ago, "It's about time to handle documents and assets in the same way". I think there is a need for a comon interface shared by both CMS documents and assets, so both can be handled uniformly -- particulary for link rewriting, where the URI's of both CMS documents and assets need to be rewritten in the same way. This would be, perhaps, "ContentItem". And both Document and Resource (which maybe should be named Asset?) should implement this interface and DefaultDocument and Resource should extend a DefaultContentItem class. Or is there a better idea? 3) I think maybe the link rewriting should be done when a CMS document is published, deactivated, or exported, rather than every time it is displayed. This change would be a performance boost for every page. Or am I missing something in why it needs to be done at display time? 4) LinkRewritingTransformer relies heavily on the DefaultDocumentBuilder class, whose isDocument() method simplistically returns true for any URL's starting like "/lenya/mypub/authoring/" even if the URL points to an asset, not a CMS document. In contrast, note that the sitemaps verify that the URL ends in ".html" before assuming that a URL is really a CMS document. Should DefaultDocumentBuilder's isDocument() method be changed to look for the ".html" ending? (But do CMS documents *always* have an ".html" ending?) I believe I'll need some enlightenment on these issues before any LinkRewritingTransformer improvements can be made, at least by me. Thanks! ---------- Forwarded message ---------- From: Bob Harner <[EMAIL PROTECTED]> Date: Jan 28, 2006 7:42 AM Subject: Re: Losing hyperlinks - what xsl removes them? To: [email protected] On 1/27/06, Michael Wechner <[EMAIL PROTECTED]> wrote: > Bob Harner wrote: > > > Are links handled any better in 1.4? > > I am not sure, but I don't think so. It could definitely need > improvement and patches are always very welcome ;-) > > Michi Somehow I knew that would be the answer :-) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
