Sylvain Wallez wrote:
Daniel Fagerstrom wrote:
Sylvain Wallez wrote:
<snip/>
So the "resource:" protocol will behave with OSGi just as it behaves
otherwise, with the restriction that the search path is restricted to
the bundle's dependencies.
Totally makes sense (*).
Maybe we could have an own bundle protocol
(through the source mechanism), that works like the OSGi bundle
protocol but have symbolic block names instead of bundle numbers.
Something like "block-resource://org.apache.cocoon.forms/..." ?
First problem: block name is missing. You probably meant:
block:myforms:resource://org.apache.cocoon.forms/
(resolve resource: in the context of the block). But...
This can be implemented today in 2.1.x by having this protocol
delegating to "resource:"
That would be one possibility, question is if we want direct access to
blocks.
Probably not. Above can be achieved using regualar block protocol, and an entry
in the block's sitemap to export resources:
block:myforms:resources/css/forms.css
Whereas myforms' sitemap will have match for resources/**/*.css
But...
<snip/>
In the meantime, we can consider the access through
"resource:" as an transition step between copy/paste in each application
and block-powered services.
Given the fact that resource: protocol still works as expected with 'real
blocks' (See (*) above), conclusion is that simple sitemap snippet:
<map:read src="resource://org/apache/cocoon/forms/resources/css/forms.css"/>
is enough, and no 'fancy' block protocol is necessary.
<snip/>
The idea for blocks is that blocks that contain public URLs are
mounted at deploy time at a some root URL, then the URL revriting
transformer translates internal use of symbolic block names to the
public exported ones.
Why would anyone internally use any block: URIs? This should be totally
unnecessary: you can either use relative URIs, or construct absolute by passing
sitemap prefix into the xslt - same as we do in existing samples.
Vadim
