Vadim Gritsenko wrote:
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 (*).
Yes, gave some more details about in my answer to Sylvain.
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/
No, it was a try to find something that could work in both 2.2 and 2.1.x
without needing to back port to much of the blocks architecture from
2.2. But it probably becomes complicated without giving that much so we
should use the resource: solution instead.
(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.
Exactly.
<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,
You need to use block:foo: URIs to access resources in other blocks,
block: URIs to use URIs that you want polymorphic behaviour on, and
block:super: for geting an URI from the block that you extend. See
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=111791016006393&w=2 for
more details.
or construct absolute by
passing sitemap prefix into the xslt - same as we do in existing samples.
Using the LinkRewritingTransformer together with the block-path module
will be so much more convenient (see the cited mail above).
/Daniel
