oceatoon wrote:
Why step away from the global session though,
and create a new FOM_session structure? your answer was "design decision
but I don't understand, why ?
Neither do I, it wasn't my decison but Chris Olivers. One reason might be that flow uses a special embedinging of the request object etc to make them easy to use in Java script,
FOM's FOM_Cocoon / FOM_Request / etc objects are results of conscious community effort to define FOM (Flow Object Model), all its objects, and all methods on those objects. You will notice that not all methods of underlying Cocoon Request / Response / etc API were exposed, and this was done for a reason.
IIRC, see archives for thread "less is more".
Vadim
and probably it made sense to reuse these embeded objects in JXTG. Now as there already are non embeded request objects etc in the object model Chris couldn't put the embeded objects in there place but had to put them in some new places.
In the new code the embeding is done in JXTG instead of reusing the embeding from flow.
<snip/>
