Jeremy Quinn wrote: <snip/>
> I never liked map:resource, always having to be at the end, makes them > far less useful for pipeline reuse! > > It's like going to a plumber's merchant to buy some joints and they > say 'yes we have elbows and tee joints, but they are all pre-assembled > into special shapes, you cannot buy them individually'. :P What if resources didn't have to be terminated, thus being arbitrary pipeline snippets (teasing, see below) ? <snip/> > I think overloading is a grand idea in principal, though I fear it > will be confusing and difficult to understand in this context (unless > you are a Java architect ;) Same fear here, even if I'm a Java architect ;) <snip/> > I think the idea of having a pipeline snippet, that is able to be > 'called' from the middle of another pipeline is a great idea, it > allows much more effective componentisation and the ability to hide > complexity (in blocks or other pipelines/sitemaps). > > What I am not so happy about is being forced to put a component > (generator|serializer) into a pipeline, when it is obviously not going > to be used! > > IMHO calling a pipeline snippet (for whatever purpose) should be > equivalent to XIncluding that pipeline snippet into the calling > pipeline at Sitemap runtime. > > So: > <map:call pipeline="blah"/> includes pipeline components > > While: > <map:generate src="cocoon:/blah"/>, > <map:transform src="cocoon:/blah"/> and > <map:part src="cocoon:/blah"/> import pipeline output > > Anyway, I think this (general idea) will lead to great improvements! Jeremy, this resonates with what I proposed at http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=102564464204469&w=2 (see at the bottom, I forgot to snip...), and here are some additional inputs : A resource is a sitemap snippet, which is used locally in the current sitemap, and is only visible from this sitemap. The treeprocessor currently "silently" extends the resource definition by allowing a resource to be unterminated (i.e. no serializer). This wasn't done on purpose (this is in fact a bug if resources must be terminated), but we can make it official. Defined this way (a pipeline snippet, without mandatory serializer), a resource is equivalent (minus its additional parameters) to inlining its content at the location of the <map:call>. Using pipelines to define other pipelines came from a different need, which is to identify cross-sitemap/block services. I don't like named pipelines, since the current scope of resource names is limited to the sitemap that defines them. Using names to identify cross-sitemap/block services will add a new contract when we already have one : the sitemap environment, and mainly its request URI, as used by the "cocoon:" protocol. That's why I'm in favor of a more explicit semantic that both : - differenciates internal snippets (a writing facility) and pipeline services (inter-sitemap/block contracts), - clearly states what should be used in pipeline services, and not rely on implicit overloading. Sylvain -- Sylvain Wallez Anyware Technologies Apache Cocoon http://www.anyware-tech.com mailto:[EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
