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 >
