Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Carsten Ziegeler" <cziegeler@s-und-n.de>
To: "Cocoon-Dev" <dev@cocoon.apache.org>
Subject: [RT] The future of our lifecycle extensions in 2.2
Date: Thu, 8 Jan 2004 11:16:47 +0100
Message-ID: <LKENJPKDAIKAPKHEOCMMCEBOHAAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="iso-8859-1"

We added in 2.1 several lifecycle extensions to the ones already provided by
Avalon:
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
(with
fortress), I currently see no real way to support parent aware (but perhaps
there
is a way).
However, I think we should avoid adding our own lifecycle interfaces
whereever
possible.

So, let's think about them:

ParentAware
-----------
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,
unless
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.


RequestLifecycle
----------------
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.

WDYT?

Carsten

Carsten Ziegeler
Open Source Group, S&N AG
http://www.osoco.net/weblogs/rael/