3 Jun
2008
3 Jun
'08
4:01 p.m.
Hi Pascal,
On Jun 2, 2008, at 6:43 PM, Pascal Voitot wrote:
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?
There are 2 Components:
- Container: contains container-related threadlocal variables
(request, session, response)
- Execution: contains non-container-related threadlocal Execution
Context variable.
Note that the Container init code is in charge of populating the
Execution Context with data coming from the request (like putting the
wiki, space, document for ex).
Thanks
-Vincent
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.