so in fact, you have a kind of ThreadLocalContext (aka Container) containing
the local variables (automatically injected etc...) and an ExecutionContext
containing "general" variables specific to the execution environment...
Am I right?
br
Pascal
On Mon, Jun 2, 2008 at 6:08 PM, Vincent Massol <vincent(a)massol.net> wrote:
Hi,
I've been thinking a lot about the Container component I introduced
and while writing unit tests for some of the new rendering classes I
realized there was something not right: it's not normal that the HTML
exporter or the rendering module depend on the Container object, and
especially on the Request.
Thus I'd like to introduce the notion of Execution Context (EC in
short).
The idea is that the xwiki entry points depend on the environment
(Servlet, Portlet, etc) but those entry points create an Execution
Context which is then used by the core components, independently of
the environment. For example the VelocityContext is now put in the EC
and not in the Request object.
The Container objects still exist and can be used where required but
it's expected that they should not be used since that makes the code
dependent on the environment.
This solves issue I had with code that don't have a request.
I have it done on my machine. WDYT? Ok to commit?
Thanks
-Vincent
PS: BTW this makes it very similar to the current XWikiContext (which
is good) with the exception that the Container objects are not located
inside the EC but as separate threadsafe variables.
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs