cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vadim Gritsenko <va...@reverycodes.com>
Subject Re: Standardizing resources in jars (was Re: [Proposal] Switch to Maven NOW)
Date Wed, 17 Aug 2005 15:46:24 GMT
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

Mime
View raw message