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 10:01:21 GMT
Grzegorz Kossakowski wrote:
> Do you think all three pieces are always needed? My answer would be: no,
> usually they are not.
:) In my use cases, I often need all three of them and sometimes request
and context.

> 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.
Well, fine - although I hate to write to much code, we could remove the
interface all together.

>> 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.
The object model map which is passed to each and every sitemap component
in the setup() method. This is the only way of storing per request

> 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.
Yes, let's use HttpServletRequest etc. - this makes the code usable
"outside" of Cocoon without any problems.

Carsten Ziegeler

View raw message