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: <dev@cocoon.apache.org>
Subject: RE: RequestLifecycle components
Date: Wed, 22 Oct 2003 16:41:04 +0200
Message-ID: <LKENJPKDAIKAPKHEOCMMGEEOFMAA.cziegeler@s-und-n.de>
MIME-Version: 1.0
In-Reply-To: <3F96949A.3000908@apache.org>
Importance: Normal
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="us-ascii"

Berin Loritsch wrote:
>
> I'm running into an issue here with RequestLifecycle components.
> I want to
> write the handler and such, and we can assume one handler to one component
> definition (configuration, etc.).  Right now the helper classes
> assume we have
> access to a Role.  This is not the case.
>
> I believe we can simplify things a little, but we cannot assume
> we have acess
> to the role.  I will let you know when I am done with this issue,
> but if someone
> has any hints, help to offer, etc. let me know.
>
If you need help, just let me know.

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.
You can achieve the same thing now by using the
o.a.c.components.persistence.RequestDataStore which is imho a cleaner
solution.

Now, the advantage of the RequestLifecycleComponent is performance.
If you have several places during a request where this component is
used, only one instance of a RLC is used, which means the data
it acts on is only fetched once as well.

If you use a Poolable component with the RequestDataStore, this
component is retrieved several times and several times the
data is fetched from the store. And exactly this last point,
fetching the data from the request is a little bit more
costly. Hmm.

*If* someone would start a vote on deprecating RLC in 2.1 now
and removing them from 2.2, my vote would be above 0.

Carsten