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.
--- o0o ---
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.
WDYT?
/Daniel
