cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andreas Hochsteger <e9625...@student.tuwien.ac.at>
Subject Re: [RT] Finishing the first phase of block design
Date Thu, 09 Oct 2003 19:36:47 GMT

Stefano Mazzocchi wrote:

>> - Will not explicitly declaring which resources are meant to be public 
>> cause trouble for block implementors and extenders?
> 
> 
> ?? well, in the sitemap I can be very precise on what I want to expose. 
> and everything else is not exposed. the sitemap is like a virtual file 
> system description, powerful enough to describe all possible systems.
> 
> If you have
> 
> <pipeline block-access="public">
>  <match pattern="**">
>   <read src="public/{1}"/>
>  </match>
> </pipeline>
> 
> than the contract moves at the file system level, but that's up to you 
> to decide.... and a block extender can do
> 
> <pipeline block-access="public">
>  <match pattern="stylesheet/layout2page.xslt">
>   <generate type="sql" src="layout.xml"/>
>   <transform src="layout2stylesheet.xslt"/>
>   <serialize type="xml"/>
>  </match>
> </pipeline>
> 
> to provide extension that is procedural (but without exposing, for 
> example layout.xml and layout2stylesheet.xslt which are just used 
> internally)
> 
> With a single mechanism, it's much easier to do meaningful block extension.
> 
>> Of course the flexibility of decoupling the uri space from the 
>> filesystem is a benefit - but is it necessary?
> 
> 
> see above: I think so.
> 
>> How hard is it really to keep filenames and directory locations for a 
>> selected group of public resources?
> 
> 
> no, that's not the issue: the real issue is: if both resources and 
> pipeline outputs are streams, why make a difference?
> 

I agree with Stefano at this point.
The independence of the physical filesystem layout is one of the best 
features of Cocoon and it wouldn't be good to loose this great concept 
for blocks.

> -- 
> Stefano.
> 

Bye,
	Andreas



Mime
View raw message