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
