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 -- Carsten Ziegeler [EMAIL PROTECTED]
