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/
