Difference between FOM_Session and REal Session?

[oceatoon <t....@systheo.com>]

HI everyone 

We are having weird effects poping up some structure questions about FOM and
more precisly about FOM_session. I use Flow to put some data into
cocoon.session.setAttribute("data",data) and retreive this easily from my
jx file coming from flow. 
Thinking this is part of a global session object, in this same JX page, I
have a link calling a pipeline that opens another JX file this time coming
from the pipeline my ${cocoo.session.data} doesn't work???  hmmm

so I realise that the first cocoon.session isn't the global session I am
looking for (that could be used from anywhere) but a FOM_session?? Is this
correct?  
I have a feeling this was made so that Flow(Rhino Flow Continuation) could
work in it's own little context, the same for JX, but regular pipelines
don't go that way ?? So I ask myself now, how am I going to be able to
access my FOM_session(like a global session) data coming from pipeline
calls, or how to set what I put into FOM-session into global session??

I don't know much about the backend of FOM or Flow, so please excuse me if
this is a bit pulled out of the hat;), but I'd like to understand the
session structural difference between coming from Pipeline and from Flow.
Could there be a link with another recently posted problem about
cocoon.request in JX???

Thanks for the thoughts
Tibor

Re: Difference between FOM_Session and REal Session?

[Daniel Fagerstrom <da...@nada.kth.se>]

oceatoon wrote:
> Daniel Fagerstrom wrote:
<snip/>
>>In the refactored JXTG I use o.a.c.environment.FlowObjectModelHelper,
>>that Carsten wrote. It gets the objects from the normal places in the
>>objectmodel and does the dynamic map embeding and puts everything in
>>$cocoon. By using this we get the same behaviour booth in the flow and
>>non flow context.
> 
> is this allready functionnal in JXTG2 ?
Yes.

/Daniel

Re: Difference between FOM_Session and REal Session?

[oceatoon <t....@systheo.com>]

Daniel Fagerstrom wrote:

> I agree with that the behaviour is weird, but it is designed to be that
> way. What happens is that your data is always placed in the session data
>   in the servlet. But then the request object, session objects etc are
> placed in a different place if you use them from flow, comperd with how
> it is done in the rest of Cocoon. If you want to know all the details
> you can take a look at the setupView method in
> o.a.c.components.flow.javascript.fom.FOM_JavaScriptInterpreter and
> o.a.c.components.flow.javascript.fom.FOM_JavaScriptFlowHelper.
OK Thanks
> 
> The flow embeds the request object etc in some kind of dynaic map which
> makes them more convinient to use from flow and from expression
> languages. Then the object are placed in special places in the object
> model. I.e. not the same as all other Cocoon components use. JXTG gets
> the objects that are used in $cocoon from these places, check the setup
> and setContext methods in the original JXTG for details.
> 
> The result of this is that when you use JXTG without flow, the $cocoon
> object is empty except for $cocoon.parameters. For back compatibility
> and for making it possible to use whithout flow there are some
> deprecated variables $request, $session etc that uses the non emebeded
> object from the objectmodel. You have to use these if you don't use flow.
> 
> In the refactored JXTG I use o.a.c.environment.FlowObjectModelHelper,
> that Carsten wrote. It gets the objects from the normal places in the
> objectmodel and does the dynamic map embeding and puts everything in
> $cocoon. By using this we get the same behaviour booth in the flow and
> non flow context.
is this allready functionnal in JXTG2 ?

Re: Difference between FOM_Session and REal Session?

[Daniel Fagerstrom <da...@nada.kth.se>]

Vadim Gritsenko wrote:

> Daniel Fagerstrom wrote:
>
>> 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.

Thanks for reminding.

> IIRC, see archives for thread "less is more".
>
I searched the archives and found lots of discussions about it but not 
any summary of the actual decision.

The goal is to have the FOM view from JXTG available in other places in 
Cocoon, e.g. in an ExpressionModule. To achive this I used Carsten's 
TemplateObjectModelHelper, that makes the same object available as the 
FOM in flowscript. But it does that through a reflection based "dynamic 
map" instead of by implementing the interface in a JS friendly way as in 
the flowscript implementation.This makes, if I understand you right more 
methods available than it should. Is that important? What do yo think we 
should do about it?

/Daniel

Re: Difference between FOM_Session and REal Session?

[Vadim Gritsenko <va...@reverycodes.com>]

Daniel Fagerstrom wrote:
> 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/>

Re: Difference between FOM_Session and REal Session?

[Daniel Fagerstrom <da...@nada.kth.se>]

oceatoon wrote:
> Daniel Fagerstrom wrote:
> 
>>I agree with that the behaviour is weird, but it is designed to be that
>>way. What happens is that your data is always placed in the session data
>>  in the servlet. But then the request object, session objects etc are
>>placed in a different place if you use them from flow, comperd with how
>>it is done in the rest of Cocoon.
> 
> I am known to be stuburn but 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, 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.

>  I tried to look through the structure but I
> don't get it?

Its quite complicated I'm not certain that I get all the details yet either.

>>If you want to know all the details 
>>you can take a look at the setupView method in
>>o.a.c.components.flow.javascript.fom.FOM_JavaScriptInterpreter and
>>o.a.c.components.flow.javascript.fom.FOM_JavaScriptFlowHelper.
> 
> Everything seems to be based on objectModel Maps , I don't quite understand
> what are these objectModels?? I seem to understand they are references to
> objects that can be accessed from anywhere(sitemap, flow...)? 

Yes, that is the idea, they contain the request object and other data 
that is needed in the sitemap and flow and all sitemap components and 
flow take an object model as argument. Take a look at 
o.a.c.environment.ObjectModelHelper.

>>The flow embeds the request object etc in some kind of dynaic map which
>>makes them more convinient to use from flow and from expression
>>languages. Then the object are placed in special places in the object
>>model. I.e. not the same as all other Cocoon components use. JXTG gets
>>the objects that are used in $cocoon from these places, check the setup
>>and setContext methods in the original JXTG for details.
>>
>>The result of this is that when you use JXTG without flow, the $cocoon
>>object is empty except for $cocoon.parameters. For back compatibility
>>and for making it possible to use whithout flow there are some
>>deprecated variables $request, $session etc that uses the non emebeded
>>object from the objectmodel. You have to use these if you don't use flow.
>>
>>In the refactored JXTG I use o.a.c.environment.FlowObjectModelHelper,
>>that Carsten wrote. It gets the objects from the normal places in the
>>objectmodel and does the dynamic map embeding and puts everything in
>>$cocoon. By using this we get the same behaviour booth in the flow and
>>non flow context.
> 
> sounds good and on top of that it's allready created :D , days like these
> amaze me about this community, from one problem the solution smiles in my
> face.
> 
> back to $cocoon, this will have the functionalities promissed by the JX
> docs ;) $cocoon.session $cocoon.request but from both cases, right?
> so will they both hit the FOM_session then? (which is fine for my use case)

Yes as soon as we have extermined some bugs.

/Daniel

Re: Difference between FOM_Session and REal Session?

[oceatoon <t....@systheo.com>]

Daniel Fagerstrom wrote:

> I agree with that the behaviour is weird, but it is designed to be that
> way. What happens is that your data is always placed in the session data
>   in the servlet. But then the request object, session objects etc are
> placed in a different place if you use them from flow, comperd with how
> it is done in the rest of Cocoon.
I am known to be stuburn but 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 ? I tried to look through the structure but I
don't get it?

> If you want to know all the details 
> you can take a look at the setupView method in
> o.a.c.components.flow.javascript.fom.FOM_JavaScriptInterpreter and
> o.a.c.components.flow.javascript.fom.FOM_JavaScriptFlowHelper.
Everything seems to be based on objectModel Maps , I don't quite understand
what are these objectModels?? I seem to understand they are references to
objects that can be accessed from anywhere(sitemap, flow...)? 

> 
> The flow embeds the request object etc in some kind of dynaic map which
> makes them more convinient to use from flow and from expression
> languages. Then the object are placed in special places in the object
> model. I.e. not the same as all other Cocoon components use. JXTG gets
> the objects that are used in $cocoon from these places, check the setup
> and setContext methods in the original JXTG for details.
> 
> The result of this is that when you use JXTG without flow, the $cocoon
> object is empty except for $cocoon.parameters. For back compatibility
> and for making it possible to use whithout flow there are some
> deprecated variables $request, $session etc that uses the non emebeded
> object from the objectmodel. You have to use these if you don't use flow.
> 
> In the refactored JXTG I use o.a.c.environment.FlowObjectModelHelper,
> that Carsten wrote. It gets the objects from the normal places in the
> objectmodel and does the dynamic map embeding and puts everything in
> $cocoon. By using this we get the same behaviour booth in the flow and
> non flow context.
sounds good and on top of that it's allready created :D , days like these
amaze me about this community, from one problem the solution smiles in my
face.

back to $cocoon, this will have the functionalities promissed by the JX
docs ;) $cocoon.session $cocoon.request but from both cases, right?
so will they both hit the FOM_session then? (which is fine for my use case)

Thanks for the help
Tibor

Re: Difference between FOM_Session and REal Session?

[Daniel Fagerstrom <da...@nada.kth.se>]

I agree with that the behaviour is weird, but it is designed to be that 
way. What happens is that your data is always placed in the session data 
  in the servlet. But then the request object, session objects etc are 
placed in a different place if you use them from flow, comperd with how 
it is done in the rest of Cocoon. If you want to know all the details 
you can take a look at the setupView method in 
o.a.c.components.flow.javascript.fom.FOM_JavaScriptInterpreter and 
o.a.c.components.flow.javascript.fom.FOM_JavaScriptFlowHelper.

The flow embeds the request object etc in some kind of dynaic map which 
makes them more convinient to use from flow and from expression 
languages. Then the object are placed in special places in the object 
model. I.e. not the same as all other Cocoon components use. JXTG gets 
the objects that are used in $cocoon from these places, check the setup 
and setContext methods in the original JXTG for details.

The result of this is that when you use JXTG without flow, the $cocoon 
object is empty except for $cocoon.parameters. For back compatibility 
and for making it possible to use whithout flow there are some 
deprecated variables $request, $session etc that uses the non emebeded 
object from the objectmodel. You have to use these if you don't use flow.

In the refactored JXTG I use o.a.c.environment.FlowObjectModelHelper, 
that Carsten wrote. It gets the objects from the normal places in the 
objectmodel and does the dynamic map embeding and puts everything in 
$cocoon. By using this we get the same behaviour booth in the flow and 
non flow context.

/Daniel

oceatoon wrote:
> HI everyone 
> 
> We are having weird effects poping up some structure questions about FOM and
> more precisly about FOM_session. I use Flow to put some data into
> cocoon.session.setAttribute("data",data) and retreive this easily from my
> jx file coming from flow. 
> Thinking this is part of a global session object, in this same JX page, I
> have a link calling a pipeline that opens another JX file this time coming
> from the pipeline my ${cocoo.session.data} doesn't work???  hmmm
> 
> so I realise that the first cocoon.session isn't the global session I am
> looking for (that could be used from anywhere) but a FOM_session?? Is this
> correct?  
> I have a feeling this was made so that Flow(Rhino Flow Continuation) could
> work in it's own little context, the same for JX, but regular pipelines
> don't go that way ?? So I ask myself now, how am I going to be able to
> access my FOM_session(like a global session) data coming from pipeline
> calls, or how to set what I put into FOM-session into global session??
> 
> I don't know much about the backend of FOM or Flow, so please excuse me if
> this is a bit pulled out of the hat;), but I'd like to understand the
> session structural difference between coming from Pipeline and from Flow.
> Could there be a link with another recently posted problem about
> cocoon.request in JX???
> 
> Thanks for the thoughts
> Tibor
>