cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stephen McConnell <mcconn...@apache.org>
Subject Re: Fortress Migration Strategy
Date Thu, 16 Oct 2003 02:27:58 GMT


Carsten Ziegeler wrote:

>Berin Loritsch wrote:
>  
>
>>Initial comments about CocoonComponentManager--to make sure I don't forget
>>anything it is currently doing:
>>
>>The CocoonComponentManager handles several aspects including:
>>
>>* Request scoped components
>>* Source Resolver specifics for a processor/request
>>* SitemapConfigurable components
>>
>>    
>>
>Yes, I think this is basically our extension together with the ParentAware
>support.
>
>* ParentAware
>  A selector (or any other component) can declare that it is 
>ParentAware, which means if you have a hierarchy of component 
>managers and a component is looked up in a child CM it get's a 
>reference to a component looked up in the parent CM.
>This is useful for nested selector e.g.
>

Some questions:

1. Based on the current implementation - how do you declare a 
ParentAware strategy?
2. How do you seperate functional service dependency from the 
implementation aware hierarchy solution?


>
>  
>
>>I believe I can solve these in the following manner:
>>
>>Request Scoped Components:  Create a new lifestyle handler for Fortress.
>>    
>>
>
>Yes, should work, but we currently have this in two flavors:
>The RequestLifeCycleComponent and the GlobalRequestLifeCycleComponent.
>The GlobalRequestLifeCycleComponent is one instance per global request
>comming into Cocoon. 
>

Am trying to translate "request-based" terminology into implementation 
based policy.  We have established a number of standard implementation 
policies.  Global verus Request suggests a request based policy - which 
is problamatic under the ServiceManager/ComponentManger interfaces. 
Could this  request policy be moved to comoponent space by delcare a 
service against which the component requests the flavour explicitly?


>Even if this request creates sub requests (using the
>cocoon protocol), 
>

What is the Cocoon protocol?

>it's still one instance.
>The RequestLifeCycleComponent is oen instance per request. So, each
>internal request gets its own set of RequestLifeCycleComponents.
>Example:
>a) main request looks up a component of role A
>b) main request invokes sub request (cocoon protocol)
>c) sub request looks up a component of role A
>d) main request looks up a component of role A again
>
>I) The component is a GlobalRequestLifecycleComponent
>a) main request gets instance ONE
>c) sub request gets instance ONE
>d) main request gets instance ONE
>
>II) The component is a RequestLifecycleCOmponent
>a) main request gets instance ONE
>c) sub request gets instance TWO
>

Why, how?
Presumably you are supplying an identifier that influences a factory 
option.  Can you do this via a service?

>d) main request gets instance ONE
>
>
>  
>
>>SourceResolver specifics:  I need some input on how exactly you
>>are extending
>>                            this.  I might be able to handle it with an
>>                            Accessor lifecycle extension.
>>    
>>
>The SourceResolver component uses a base directory to resolve relative
>URIs.
>The SourceResolver in Cocoon always resolves relative URIs to the
>current sitemap, so during the processing of a request this information
>changes. 
>

I.e. its a runtime component driven request - should be handled by a 
service - not extension.
 

>But the component itself is e.g. looked up at the initialization
>phase of the action etc.
>
>  
>


>  
>
>>SitemapConfigurable components:  I can address this with an
>>Accessor extension.
>>
>>    
>>
>Yes, I guess so as well.
>

Is SitemapConfigurable basically the overriding of a configuration based 
on sitemap data or are your qualifying/extending a componet configuration?

Stephen.


>
>Carsten
>
>
>  
>

-- 

Stephen J. McConnell
mailto:mcconnell@apache.org




Mime
View raw message