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: RFC-2396 (Was: Re: [RT] composition vs. inheritance in blocks)
Date Mon, 04 Apr 2005 17:07:52 GMT
Pier Fumagalli wrote:

>
> On 4 Apr 2005, at 16:26, Daniel Fagerstrom wrote:
>
>> Pier Fumagalli wrote:
>>
>>> On 31 Mar 2005, at 01:26, Stefano Mazzocchi wrote:
>>>
>>>>
>>>>  block:super://blah.xml
>>>
>>>
>>>
>>> A very simple remark, I don't want to criticise...
>>>
>>> I'm already slightly "upset" about the "cocoon://" protocol, as it 
>>> does not follow the URI RFC properly, I'd like to address the 
>>> problem as early as possible...
>>>
>>> http://www.ietf.org/rfc/rfc2396.txt
>>
>>
>>>
>>> I wrote a small "rant" while on the plane, just to explain my 
>>> reasoning, with a couple of code examples, as it's (I don't think) 
>>> mailing-list material, I've stored it on my WIKI...
>>>
>>> http://www.betaversion.org/~pier/wiki/display/pier/Cocoon+and+URIs
>>>
>>> Anyhow, feel free to discuss it here...
>>
>>
>> I read your rant and agree with it, it seem benefical to take 
>> advantage of java.net.URI. I'm not completely happy with letting 
>> relative sitemap paths be opaque and absolute be hierarchical, but I 
>> don't see any better alternatives.
>
>
> The thing is that the scheme specific part of the opaque URI, is 
> actually a relative URI which can be resolved against an absolute one...
>
> URI relative_uri = 
> absolute_uri.resolve(opaque_uri.getSchemeSpecificPart());
>
> As simple as that...
>
>>
>> Concerning:
>>
>>  block:super://blah.xml
>>
>> it is AFAICS a correct opaque URI. But we could make better use of 
>> java.net.URI if we considered a hierarchial URI scheme for blocks 
>> instead. From this perspective the scheme that Reinhard suggested 
>> makes sense
>>
>>  block://portal/foo
>>
>> for refering to the absoute path "/foo" within the portal block,
>>
>>  block:/foo
>>
>> for refering to the absolute path "/foo" within the current block and
>>
>>  block:./bar
>>
>> for refering to the relative path "bar" relative to the current 
>> (sub)sitemap within the current block and
>>
>>  block:super:/foo
>>
>> for refering to the absolute path "foo" whithin the super block of 
>> the current and possibly
>>
>>  block:super:./bar
>>
>> for refering to the relative path "bar" relative to the current 
>> (sub)sitemap within the super block of the current.
>>
>> The last three URIs are opaque and could be resolved to absolute 
>> hierarchical URIs with a similar algorithm as you proposed for 
>> "cocoon:./" resolution.
>>
>> Maybe using "//portal" as an authority is stretching the 
>> intepretation to far.
>
>
> Exactly... That's why I'm thinking that the URI should be this:
>
> block:portal:/foo
>
> block is an opaque URI, whose scheme specific part _is_ a valid URI by 
> itself.
>
> portal:/foo is a valid URI, but if (for example) you think about other 
> cases, this URI could be
>
> block:xmlrpc://www.myrpcserver.dom/entry/point
>
> block: opaque URI
> xmlrpc: valid URI whose scheme specific part (whether it's opaque, 
> absolute, relative, blah) is only known by the "xmlrpc" handler...
>
> block:portal:/foo
>
> What's "/foo"? Only the portal block knows it...

Ok, that makes sense. The specific blocks handler resolve the scheme 
specific part. If we follow this path the blocks descriptor 
(http://wiki.apache.org/cocoon/BlocksCob) must be extended with a 
declaration about what source resolver to use.

It would still be good to have a default resolver for all blocks that 
doesn't have specific needs, so that we get some coherence for our 
blocks. And there we could use hierarchical URIs like those you propsed 
in your wiki for the cocoon: protocol.

Question is how i.e. the portal block refers to its own pipes. If you 
take a look at http://wiki.apache.org/cocoon/BlocksCob a block doesn't 
have a short name for it self that can be used as scheme, it only 
declares such names for the blocks it requires, so portal: doesn't make 
any sense within the portal block. So within the specific block we could 
maybe use:

  block:/foo, block:./bar, block:super:/foo, block:super:./bar

whith the same intepretation as I suggested above (for the default 
resolver).

This could be done in the way that each block define its own resolver 
and bind it to the scheme block:, then when  a block, portal e.g. use an 
URI to another block, the block manager (for portal) will get an URI like:

  block:skin:/foo

it will then find the block manager for the skin block and ask it to resolve

  block:/foo

Which will use the resolver from the skin block.

/Daniel


Mime
View raw message