cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pier Fumagalli <p...@betaversion.org>
Subject Re: [Kernel2.2] Source Resolving
Date Wed, 31 Mar 2004 12:06:17 GMT
On 31 Mar 2004, at 12:18, Carsten Ziegeler wrote:
> Pier Fumagalli wrote:
>> On 31 Mar 2004, at 10:56, Carsten Ziegeler wrote:
>>
>>> I just had some quick looks at the new kernel 2.2 and the
>> first topic
>>> to discuss is source resolving :)
>>>
>>> Cocoon uses the excalibur source resolving package to resolve any
>>> resources (file, http, cocoon pipelines etc.).
>>> The kernel currently uses a similar construct but with new
>> interfaces
>>> and implementations.
>>>
>>> In order to reuse what we already have and to be "more
>> compatible" to
>>> Cocoon 2.0/2.1, I would suggest to use the sourcer resolver package
>>> here as well.
>>> Another reason is that we need a Source Resolver for the sitemap
>>> components anyway. Most sitemap components get the source
>> resolver as
>>> a parameter in the setup (or act etc.) method.
>>>
>>> Now, I know that the original kernel should be as small as possible
>>> and if possible without references to any other projects
>> which is in
>>> general great and ok, but I think for Cocoon it's better to use
>>> existing parts whereever possible.
>>>
>>> Ah, and if you think that one problem is that the sourceresolver
>>> package is hosted at avalon, we can/should solve this as well.
>>>
>>> WDYT?
>>
>> Carsten, i think I introduced a little bit of confusion
>> calling a couple of things "Resource" and "Resolver"...
>> Careful, those are "resource" resolution for infra-block
>> wirings. What does it mean? That
>> Wirings.resolve(String) or Wire.resolve(String) will NEVER
>> resolve things like "http:...." or "ftp:...", not even
>> "cocoon:...." unless those names are names of wirings
>> specified in a block descriptor.
>>
>> A sourceresolver must be implemented on top of this
>> interface, providing resolution for "http:...", "ftp:...",
>> "cocoon:..." <and> a new protocol called "block:..." which
>> will fall back on the framework resource resolvers.
>>
>> As Stefano said in his original [RT] on blocks, any
>> source-resolved resource which need to fall back on blocks
>> resolution will have to be something like:
>>
>> block:wiringname:...
>>
>> The SourceResolver will have to look at the beginning
>> (block:) and understand that in needs to resolve the resource
>> on the block's resolver as "wiringname:...". If it begins
>> with something else (cocoon:
>> for example) it will have to resolve in a different way...
>>
>> The Resolver interface specifies that there's no contract
>> between name and the resource, maybe we could implement this
>> in the o.a.c.k.DeployedWirings class, change the interface,
>> or whatever! :-)
>>
> Ah, ok, I see. Good :)
> But couldn't the source resolver (the interfaces and the impl.)
> not also be used for this as well? I saw, you have an impl. for
> jars and one for files. This is more or less code duplication,
> I think. Of course, if there are only these two and not more
> than it might be ok. Hmmm :)

I don't think there are going to be more, as blocks libraries 
themselves can be represented as a directory (File) and a JAR archive 
(JarFile)... So, for resolution of sources _between_ block, nothing 
else should get in the way...

If we want to build the full resolver inside the framework itself, and 
therefore the "resolve" method in "Wirings" and "Wire" will accept 
"block:wiring:/path" instead of only "wiring:/path", then yes, I agree 
with you that source resolution should be closer (or same as) 
Excalibur's SourceResolver.

Only "issue" I might see with that is that Excalibur's Source doesn't 
have the "isDirectory()" and "children()" methods, so, well, I don't 
absolutely like it because it's prone to hacks.

Maybe a union of the two might be better?

	Pier

Mime
View raw message