cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: [design] Cocoon Blocks 1.1
Date Mon, 11 Nov 2002 22:31:07 GMT


Carsten Ziegeler wrote:

>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.
>
Carsten:

Do you think it would be reasonable for access to a resource to be 
expressed as a service. I.e. the client goes though an interface exposed 
as a service to access the resource.  This present the benefit that the 
block (as the resource repository) does not need to be exposed to the 
client.  It also means that we are always dealing with the same 
conceptual service access model.

Cheers, Steve.

>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
>
>
>
>  
>

-- 

Stephen J. McConnell

OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net




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


Mime
View raw message