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. > 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. Even if this request creates sub requests (using 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 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. 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. Carsten
