cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Turner <>
Subject Re: Link view goodness (Re: residuals of MIME type bug ?)
Date Sun, 29 Jun 2003 06:56:56 GMT
On Sun, Jun 29, 2003 at 05:36:45PM +1200, Conal Tuohy wrote:
> Jeff Turner wrote:
> <snip/>
> > Also, it resolves another little dilemma I've had with link views.
> > It's all very well having the notion of a cross-cutting 'view', but
> > there's no way to override the 'view' for a specific pipeline.  With
> > an explicit gather-links transformer, one could have different link
> > analysis for each pipeline.  A *.css pipeline could list @import's as
> > links, for example.
> That's an issue I've come up against too - it seems that views are
> still too "tangled" up with labels and can't cut across pipelines
> properly. At least, that's how I understand it - maybe I'm missing
> something?

I think labels and Views are independent of each other.  You can have a
view defined with 'from-position', and not use labels.  Labels are just
generic markers, with nothing to say they're only useful for defining

> For instance I couldn't see how to have 2 pipelines share a view (i.e.
> both support a view) unless the 2 pipelines had a common stage
> somewhere.
> I've always wondered why views weren't implemented using a Selector?
> <map:select type="view">
> 	<map:when test="links">
> 		<map:transform src="convert-format-X-to-links.xsl"/>
> 		<map:serialize type="links"/>
> 	</map:when>
> 	<map:when test="content">
> 		<map:transform src="convert-format-X-to-HTML-xsl"/>
> 		<map:serialize type="html"/>
> 	</map:when>
> </map:select>

Views give _every_ public URL in a sitemap an alternative form.  If you
only need an alternative form of some URLs, then that can be done just as
you've described above, with a request-param selector.

The problem is that Views don't know the type of data they're getting.
If we have a view with from-label="content", we know it's content, but
what _type_ of content?  What schema?  What transformation can we apply
to create a links-view of this content?

That's why I'm looking forward to Cocoon 4.0, which will have strongly
typed pipelines.  Then the links view can see what kind of content its
getting (say *.css), and apply an appropriate transformation to extract
links (@import'ed files).  Given the current release rate, Cocoon 4.0 is
due in early 2030.


> In this way different pipelines could have quite different views,
> without sharing a commonly-labelled component. I guess this is more
> verbose than the current approach, where the view transformations are
> attached by name using a label, but for some reason the label approach
> reminds me powerfully of GOTO.
> Cheers
> Con

View raw message