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
