On 28 Jun 2003 at 11:59, Jeff Turner wrote: > 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.
Okay. For the CLI, the cli.xconf file is the equivalent of the web.xml and the user agent. Now, normally the user agent requests a URI, and that's it. It is up to the user agent as to what to do with that URI. Are you saying that you want to put the configuration as to where pages should be placed into the sitemap? And which URIs should be rendered? If so, how would you do this? Thing is, for me, that means hardwiring the URIs you want to render into your site, and doesn't allow for a dynamic regeneration of different parts of the site. > 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> Yup. The primary aim was to reduce the number of page generations. And there was an element of hack here - particularly in the 'hard-wired'ness of the LinkGatherer. It has to be said that the link gatherer uses the same approach as the LinkTranslator, which is used by the 'mime-type checking' code. That's where I got the idea. > 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 can (and already could) see these benefits. I would like to see a way to meet both of our requirements (a link view and single pass generation). Now, caching might be the simplest way. Or an alternative would be to ask: can you always do your link view with a single XSLT stage? If so: <map:match pattern="page.html"> <map:generate src="page.xml"/> <map:transform src="before-links.xsl"/> <map:transform type="gather-links" src="identify-links.xsl"/> <map:transform src="after-links.xsl"/> <map:serialize/> </map:match> So there's no hidden link gatherer. And you've got a single xslt to filter, etc. Not specifying src="xxx" skips the xsl stage. The output of this xsl would be xml conforming to a predefined namespace. > 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. I've always been convinced - just don't like the double pass. Regards, Upayavira I think there's a place for both, but I'd like to get it
