cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Date Wed, 17 Aug 2005 21:00:43 GMT
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

Mime
View raw message