cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Link view goodness (Re: residuals of MIME type bug ?)
Date Sat, 28 Jun 2003 01:59:43 GMT
On Thu, Jun 26, 2003 at 03:08:09PM +0100, Upayavira wrote:
> > But I like the link-views! ;)  It's one of those design elegancies
> > that makes Cocoon unique.  Adding a don't-crawl-these-links option to
> > the new CLI may solve the same problem, but IMHO it's a hack in
> > comparison.
> What specifically is it that you like about link views? Cos at the
> moment, the alternative way of gathering links is with an invisible
> (automatically inserted) LinkGatherer transformer stage right before
> the serializer.

Conceptually, I link the link-view because:

1) Links are URIs
2) The sitemap is 100% in control of the URI space


3) The sitemap ought to be in control of link URI manipulation, not
some external cli.xconf file.

Now for practicalities:

I like the fact that the sitemap writer has full control over what is
considered a link, and what those links look like.  An invisible linkgatherer
transformer effectively hardcodes:

<map:serializer name="links" src="org.apache.cocoon.serialization.LinkSerializer">
<map:view name="links" from-position="last">
  <map:serialize type="links"/>

There are various points of flexibility that the links view allows:

Alternative Link schemes

If the user's XML doesn't happen to use XLink or @href for linking, they would
implement an alternative to LinkSerializer.

For example, imagine we want to render only PDFs.  The last XSLT in
our pipeline would produce xsl:fo.  The standard LinkSerializer
doesn't know about fo:external-link elements.  Even if it did, we'd
want to filter out links to images, since PDFs have images inlined.
What is an image?  That's up to the sitemap writer.

When serializing links in Japanese or something, wouldn't tweaking the
<encoding> tag be necessary?

Filtering unwanted links
We can filter out unwanted links, with arbitrary precision (eg using
XPath expressions to determine what to throw out).  In Forrest we use
<xsl:when test="contains(., 'api/')"> to filter out javadoc links.
Eventually, 'api/' will be determined at runtime, by querying an input
module that reads a forrest.xml config file.

I hope I've convinced you :)  Certainly for simpler needs, hardcoding
a LinkGathererTransformer is fine, but in general (and I hope where
Forrest is going) we need the full power of a link view.


> Upayavira

View raw message