cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sylvain Wallez <sylv...@apache.org>
Subject Re: Problems with lazy loading components
Date Tue, 18 Oct 2005 21:27:31 GMT
Carsten Ziegeler wrote:
> Daniel Fagerstrom wrote:
>
>   
>> The current behaviour is flawed as we already know from e.g. the case 
>> with the I18N transformer where dynamic resolution is used when static 
>> is what would have been expected. With lazy loading things get even 
>> worse as resolution during the setup phase also can become dynamic.
>>
>> It is time that we solve this problem once and for all.
>>
>>     
> Yeah, sure, I totally agree. But providing two different source
> resolvers creates imho more confusion than it really helps.
>   

And actually 3 resolvers, as we also have the one in setup() of sitemap 
components :-)

Here's another suggestion that doesn't need a new component.

First of all, when a component is setup (i.e. Avalon lifecycle 
interfaces), the relative path must *always* be the one where the 
component is declared, whatever the current environment is. This solves 
the issues with lazy loading and poolable components that are created on 
demand.

Outside of the component setup, we have the current behaviour where the 
relative path depends on the current sitemap.

Now if a component needs to access some resources relative to the place 
where it was declared, then it *must* resolve that URI during its setup 
phase.

Example:

class FooTransfomer extends... {
    ServiceManager manager;
    String baseURI;
    SourceResolver resolver;

    public void service(ServiceManager sm) {
        this.manager = sm;
        this.resolver = (SourceResolver)sm.lookup(SourceResolver.ROLE);
        this.baseURI = resolver.resolve("").getURI();
        // yeah, we must also release the source...
    }

    public void doSomething(String sitemapURI, String configURI) {
        // Access data relative to the current sitamep
        Source sitemapSrc = resolver.resolveURI(sitemapURI);

        // Access data relative to the place where the component was defined
        Source configSrc = resolver.resolveURI(configURI, baseURI, null);
        ....
    }
}


> You say that it's the developer who decides how sources are resolved
> (what the base for relative resolving is). Now, what about having an
> i18n transformer configured in the main sitemap once with all the
> configuration and then the transformer is used in several sub sitemaps.
> Each sub sitemaps has the same set of catalogs. So in this case, the
> transformer is configured once in the main sitemap with relative paths
> and the paths are resolved in a sub sitemap relative to the sub sitemap.
>   

Hmm... although nothing requires it, URLs specified in a configuration 
should always be interpreted as being relative to this configuration. 
Otherwise you don't really know what data you're pointing to.

> Ok, this might be a constructed case, but I think the point is, the
> developer can't always decide.
> So, again why not using the following:
>  <map:transform src="my-class">
>    <map:parameter name="config-file"
> value="static://relativ_to_this_sitemap"/>
>
> and
>  <map:transform src="my-class">
>    <map:parameter name="config-file" value="relativ_to_the_usage_sitemap"/>
>
> Everything stays the way it is and you can force source resolving to be
> relative to the defining sitemap by using the protocol.
>   

Hmm... adding yet another protocol whose base URI depends on the context 
doesn't go towards more simplicity. IMO the "keep the baseURI" pattern 
explained above actually solves all problems *if* the relative path is 
always set to the component's declaring sitemap during component setup.

Sylvain

-- 
Sylvain Wallez                        Anyware Technologies
http://people.apache.org/~sylvain     http://www.anyware-tech.com
Apache Software Foundation Member     Research & Technology Director


Mime
View raw message