On Sun, 3 Nov 2002, Sylvain Wallez wrote: > Stefano Mazzocchi wrote: > > > > > Cocoon Blocks > > ------------- > > > > author: Stefano Mazzocchi > > status: working draft > > version: 1.1 > > > > >please note the > > > > block:skin:/stylesheets/site2xhtml.xslt > > > > IMHO, this example goes strongly against the benefits that blocks want > to bring. The functionnality brought by the 'skin' block is... skinning. > It's not an XSL stylesheet at a particular location. What if someone has > written the killer skin for his site, but this skin requires a > multi-stage pipeline that cannot be represented by a single stylesheet ? > > The contract of a block should be services identified by their URI, and > not files at well-known locations (even if these 'files' are in fact > produced by a pipeline). > > So what about something like : > ... > </map:aggregate> > <map:call resource="block:skin:/site2xhtml"/> > </map:match> > > This call "jumps" to a service provided by the block and its URI is part > of the block's contract. We don't care (because we don't have to) if the > service is implemented by an XSL or by the next-generation transformer. > > What the "jump" does is feed a pipeline in the block with the result of > the current pipeline. The whole pipeline is terminated in the called block. > > But just as a pipeline can serialize or not depending on if it's an > internal request or not (see SitemapSource), the same service could be > used as a transformation. We could then write something like : > ... > </map:aggregate> > <map:transform type="pipeline" src="block:skin:/site2xhtml"/>
Hmmm...I have question about this... Why is the transfomer here of type "pipeline"? As far as I understand its not the "pipeline-service" thats doing the transformation, the "pipeline-service" simply builds the transformer src?? Shouldnt the transformer type be "xslt" or "xalan" in this case? Or have I missed something :) > <map:transform type="urlencoder"/> > <map:serialize/> > </map:match> > > By considering blocks as pipeline services, we really achieve true > polymorphism for blocks, because we totally abstract the way their > contracts are implemented. While I totally agree that, for example, "application" blocks should be considered as pipeline-services, its probably worth noting here (for the sake of completion) that this is not imply that Blocks must define "pipeline-sevices" Eg FOP Block. Regards, Michael Melhem > > [note that all the above isn't in fact block-specific and can be made > today inside a single sitemap] > > </old-post-quote> > > -- > Sylvain Wallez Anyware Technologies > http://www.apache.org/~sylvain http://www.anyware-tech.com > { XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects } > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
