cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Unico Hommes <un...@hippo.nl>
Subject Re: [RT] applying SoC on cocoon itself
Date Wed, 20 Oct 2004 14:29:54 GMT
Sylvain Wallez wrote:

> Stefano Mazzocchi wrote:
>
>> Sylvain Wallez wrote:
>>
>>> Stefano Mazzocchi wrote:
>>>
>>> <snip/>
>>>
>>>> and this solves *ALSO* the issue that was identified at the GT 
>>>> about "virtual pipeline components" resolving services locally or 
>>>> remotely (block-wise).
>>>
>>>
>>>
>>> The current problem with VPCs is the context in which relative URIs 
>>> must be resolved. We have not found a good solution for this as that 
>>> depends on the point of view that is considered. What we're missing 
>>> actually is the notion of "typed parameter" that would allow us to 
>>> absolutize a URI at the closest point where we can determine that it 
>>> is a URI and not a raw string.
>>
>>
>>
>> In the syntax I proposed, the uri="" becomes the identifier for the 
>> service (thru relative to the block that exposes the service) and the 
>> src="" becomes the identifier for the instructions for the service 
>> (thus relative to the block that requires the service).
>
>
>
> We already have this src="" attribute which currently is a raw string. 
> Does this mean that we will enforce the contract on this by 
> explicitely stating that it's a URI that will be resolved in the local 
> context where the instruction is written?
>
> We have to check if all of our current components use src as an URI.
>

I've often thought that the signature of the setup() method was wrong. 
The src parameter is passed as a String, the component is free to 
interpret it as anything it wishes. But I think this parameter was 
really only meant to ever be interpreted as a Source object. So instead 
of setup(SourceResolver resolver, Map om, String src, Parameters pars) 
the method should be setup(Source source, Map om, Parameters pars). That 
also unambiguously defines the meaning of the src attribute.

>> I think this solves the issue.
>
>
>
> Mmhh... what if other parameters are also URIs?
>

Easy. There is no way for a sitemap to interpret it as anything but a 
plain string. If a component wants to interpret it as a Source it uses 
its SourceResolver. We'll have a special Source protocol that allows to 
get FileSources relative to the calling sitemap.

--
Unico

Mime
View raw message