cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <je...@apache.org>
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

implying:

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">
  <encoding>ISO-8859-1</encoding>
</map:serializer>
<map:view name="links" from-position="last">
  <map:serialize type="links"/>
</map:view>

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.

Encoding
--------
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.


--Jeff


> 
> Upayavira
> 

Mime
View raw message