cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <cziege...@s-und-n.de>
Subject RE: Fortress Migration Strategy
Date Wed, 15 Oct 2003 07:07:53 GMT
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


Mime
View raw message