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: Problems with lazy loading components
Date Tue, 18 Oct 2005 19:40:42 GMT
Carsten Ziegeler wrote:

>Daniel Fagerstrom wrote:
>  
>
>>Ok, I guess that we have to go for your solution of having several 
>>variants of the source resolver:
>>
>>SourceResolver.ROLE + "/static" - resolve relative to the defining 
>>manager, and is implemented as I indicated above. We could modify 
>>CoreComponentManager so that it automatically creates static resolver 
>>for each manager.
>>
>>SourceResolver.ROLE + "/dynamic" - resolve relative the current sitemap 
>>and uses EnvironmentHelper.resolveURI (or something similar), undefined 
>>and throws an exception if used when there is no current processor.
>>
>>Then we should try to change all uses of the current source reolver to 
>>the new ones and in principle deprecate the CocoonSourceResolver, 
>>(although a warning in the documentation might be enough).
>>
>>WDYT?
>>
>>    
>>
>Why different components? What about using different protocols?
>  
>
The whole question is about what to resolve relative URLs against so I 
don't see how different protocols would help. Furthermore I think that 
it should be the component designers problem to decide what the 
behaviour should be for different uses of relative URLs for the 
component rather than the users problem.

>Without a protocol you have the same behaviour as currently and using
>"static:" (or a better name) it's resolved relative to the definition.
>So no changes of the existing components. Just a protocol switch where
>appropriate.
>  
>
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.

/Daniel


Mime
View raw message