Re: Fortress Migration Strategy

[Stephen McConnell]

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:[EMAIL PROTECTED]