Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: pass (hermes.apache.org: domain of ap-cocoon-dev@m.gmane.org
 designates 80.91.229.2 as permitted sender)
To: dev@cocoon.apache.org
From: oceatoon <t.katelbach@systheo.com>
Subject: Re: Difference between FOM_Session and REal Session?
Date: Sat, 22 Jan 2005 20:38:19 +0100
Organization: oceatoon
Lines: 49
Message-ID: <csua4u$qv5$1@sea.gmane.org>
References: <csrn7l$dmu$1@sea.gmane.org> <41F264CA.1060906@nada.kth.se>
Reply-To: t.katelbach@systheo.com
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7Bit
Mail-Copies-To: t.katelbach@systheo.com
User-Agent: KNode/0.8.2
Sender: news <news@sea.gmane.org>

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