cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Fagerstrom <dani...@nada.kth.se>
Subject Re: Difference between FOM_Session and REal Session?
Date Sun, 23 Jan 2005 14:58:39 GMT
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

Mime
View raw message