Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Message-ID: <46ADABFA.5090204@nada.kth.se>
Date: Mon, 30 Jul 2007 11:14:34 +0200
From: Daniel Fagerstrom <danielf@nada.kth.se>
User-Agent: Thunderbird 1.5.0.12 (Windows/20070509)
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Sitemap scope
References: <46A5CBBC.8040604@tuffmail.com>
In-Reply-To: <46A5CBBC.8040604@tuffmail.com>
Content-Type: text/plain; charset=ISO-8859-2; format=flowed
Content-Transfer-Encoding: 7bit

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