cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <>
Subject Re: Sitemap scope
Date Tue, 31 Jul 2007 08:01:20 GMT
Daniel Fagerstrom wrote:

> Now, I understand if you feel that what I write above seem overly
> pedantic and that ProcessorInfoProvider should be a good enough solution
> to the environment handling problems. I have spent so much times
> fighting the internals of Cocoon, and IMO one of the main reasons that
> the code is so hard to follow is that the handling of the current
> context is based on a patchwork of "good enough" hacks, rather than a
> overall design. So I am strongly convinced that we should spend some
> effort on getting it right. The greatest advantage with the "sitemap
> scope" idea, is that it is non intrusive and isolates the user
> components from the environment handling subtleness.
I think we are mixing things a little bit - one is the interface and the
other one is the implementation. The sitemap scope is definitly an
implementation detail which is irrelevant for the user of the interface.

The main idea of the ProcessInfoProvider was to have one single
interface to get all relevant information. If we forget about the object
model for a moment, I think it makes sense to have one interface for
getting the request, the response and the context. Instead of having to
implement three setter methods to get all pieces of information.

Today, the object model is still of great value as we messed up the
implementation and the semantics of internal pipeline calls: request
attributes are shared between the original request and all child
requests - therefore setting one in a child request overwrites it in all
related requests. This is something we can't change for compatibility.
The object model, however, is a per request map which inherits values
from the parent request. So some components rely on this behaviour.

We should therefore define what the behaviour of the request/response is
that you get from the ProcessInfoProvider. If it's similar to the
current object model and if I get a request object for the current
request (being it interal or the original one) than we can remove this
method from the interface. We can even rename the interface in need of a
better name. (For implementing this behaviour) we might need the sitemap
scope :)

But let's define the interfaces and contracts first.

Carsten Ziegeler

View raw message