cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: [design] Cocoon Blocks 1.1
Date Mon, 11 Nov 2002 14:05:44 GMT

Sylvain Wallez wrote:
> 
> 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"/>
>   <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.
> 

I absolutely agree with this, but I have two comments:

a) I think a block should also be able to expose resources directly, e.g.
   images.
b) Is it possible to unify map:call and map:transform? Does it make sense?
   Or is it better to have a different notation to emphasize the different
   usage?

Carsten

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message