cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Grzegorz Kossakowski <gkossakow...@apache.org>
Subject Re: Sitemap scope
Date Tue, 31 Jul 2007 09:42:44 GMT
Carsten Ziegeler pisze:
> 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.

Do you think all three pieces are always needed? My answer would be: no, usually they are
not.

I have no strong preference on ProcessInfoProvider or on direct dependencies. Daniel's argument
that it is a less APIs to learn is right and 
I would add another one: it's easier to see what particular component really needs.

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

Which object model? I'm not sure what exactly you are talking about.

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

Despite things you have pointed out I'm wondering about the type returned by methods from
ProcessInfoProvider.

If we want ProcessInfoProvider to return request object aware of sitemap sub-calls I think
it makes sense to switch to our own Request 
interface just after we make it extending HttpServletRequest.
On the other hand, we want to get rid of extensive use of Request so it would make sense to
stay with HttpServletRequest but returned object 
would implement Request interface. This way it would be possible to cast where it's really
needed (there are only few such places) and we 
could stay with clean interfaces.

WDYT?

-- 
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/

Mime
View raw message