cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carsten Ziegeler" <>
Subject [RT] The future of our lifecycle extensions in 2.2
Date Thu, 08 Jan 2004 10:16:47 GMT
We added in 2.1 several lifecycle extensions to the ones already provided by
The request lifecycle, the global request lifecycle and parent aware.

While it seems to be possible to support the two request lifecycles in 2.2
fortress), I currently see no real way to support parent aware (but perhaps
is a way).
However, I think we should avoid adding our own lifecycle interfaces

So, let's think about them:

Has been introduced to have a cleaner implementation for the selectors used
in the
sitemaps. I think/hope this is not an issue with fortress anymore. So,
ParentAware is needed somewhere else, we could remove it. The implementation
is always tied to a specific container which makes moving to another one
more difficult.

I'm really thinking more and more that we simply should drop
RequestLifecycle and GlobalRequestLifecycle. Why?

In most cases they are not used for the lifecycle of the component
but for the lifecycle of the data the component acts on. This was basically
the initial use case. In fact, the implementation is a little bit tricky
or someone might call it even hacky. The implementation is tied
to a specific container.

You can achieve the same thing now by using the
o.a.c.components.persistence.RequestDataStore which is imho a cleaner
solution as it doesn't require to change the container. So with
this solution we are container independent.

Currently, you look up during the request the RequestLifecycleComponent
whereever you need it and get the data from this component. So, this
is one lookup per data access.

With the RequestDataStore it's basically the same. You lookup the
store once (it's thread safe) and look up during the request the data
object from the store. So again, this is one lookup per data access.

So, I'm in favour of deprecating this in 2.1 now and removing it in 2.2.



Carsten Ziegeler
Open Source Group, S&N AG

View raw message