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 Mon, 30 Jul 2007 20:22:25 GMT
Daniel Fagerstrom pisze:
> was: How to register MockProcessInfoProvider?
> 
> Grzegorz Kossakowski skrev:
>> Hi,
>>
>> I'll give you some background to my problem. I use ProcessInfoProvider 
>> for accessing environmental data because I've read[1] that it is a 
>> proffered way to do this in Cocoon 2.2.
> ...
> 
> IMO, ProcessorInfoProvider shouldn't be the preferred way to access 
> environment info. For sure it is a much better way than using the static 
> methods of the EnvironmentHelper class directly. But if you think about 
> it, many user components (e.g. sitemap components) needs to access 
> environment info. So any "preferred" way of accessing environment info 
> will be heavily used and will be an important part of our API. Thus it 
> deserves some attention before we decide that it is "the preferred way".
> 
> So why am I not convinced about the ProcessorInfoProvider? First the 
> interface is somewhat "asymmetric". It has get methods for the http 
> servlet request, response and context which is fine, but then it also 
> makes the object model available that contains these objects as well as 
> some other ones. That is redundant and confusing. And I would prefer if 
> we could get rid of the need for users to access the object model. 
> Second and what is more important, we should minimize the set of APIs 
> that users needs to depend on. So it would IMO be much preferable if the 
> user could just depend on the http servlet request, response and 
> contexts objects directly through DI, than needing to depend on a 
> provider object. It i easier to test and less intrusive in the user code.
> 
> So how do we achieve this? This can be done by defining a special 
> "sitemap scope" as I actually suggested in the thread that you are 
> citing http://article.gmane.org/gmane.text.xml.cocoon.devel/68676. Back 
> then it was just an idea, but since then I have implemented the call 
> scope in the servlet service fw, so we know both that it works and how 
> to implement it.
> 
> A sitemap scope could be implemented similar to the call scope, but it 
> would use the EnvironmentHelper, EnvironmentStack and EnvironmentInfo as 
> underlying store instead of the CallStack and CallFrame. Also factory 
> beans similar to the ones in o.a.c.callstack.environment are needed for 
> accessing the various environment objects.
> 
> The implementation of the CallScope is rather straight forward 
> (considering that you understand Spring custom scopes 
> http://static.springframework.org/spring/docs/2.0.x/reference/beans.html#beans-factory-scopes-custom).

> One subtle thing is that the factory beans needs (AFAICS) to be stored 
> at the stack as well as the actual environment objects (see 
> CallScope.get and CallScope.remove). For a sitemap scope this could be 
> achieved by extending the StackInfo with a map that can contain the 
> factory beans. For the currently intended use, 
> Scope.registerDestructionCallBack could be a no op.

Thanks for all suggestions. I will comment implementation details as soon as I start implementing
sitemap scope because it will be the time 
I will have something valuable to say. :)

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

Daniel, I know that you have spent a lot of time in Cocoon's internals so I trust to your
opinion. Moreover, my little journey to the 
"banished code" that no one wants to look at resulted in the same feeling. I already created
an issue for this task:
http://issues.apache.org/jira/browse/COCOON-2099

Thanks for your suggestion.

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

Mime
View raw message