Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 84243 invoked from network); 23 Jan 2005 14:58:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur-2.apache.org with SMTP; 23 Jan 2005 14:58:29 -0000 Received: (qmail 58878 invoked by uid 500); 23 Jan 2005 14:58:28 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 58369 invoked by uid 500); 23 Jan 2005 14:58:26 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: dev@cocoon.apache.org Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 58341 invoked by uid 99); 23 Jan 2005 14:58:26 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from essemtepe.nada.kth.se (HELO smtp.nada.kth.se) (130.237.222.115) by apache.org (qpsmtpd/0.28) with ESMTP; Sun, 23 Jan 2005 06:58:25 -0800 X-Authentication-Info: The sender was authenticated as danielf using PLAIN at smtp.nada.kth.se Received: from [83.226.248.219] (localhost [127.0.0.1]) (authenticated bits=0) by smtp.nada.kth.se (8.12.10/8.12.11) with ESMTP id j0NEwKlu026340; Sun, 23 Jan 2005 15:58:21 +0100 (MET) Message-ID: <41F3BB9F.4080500@nada.kth.se> Date: Sun, 23 Jan 2005 15:58:39 +0100 From: Daniel Fagerstrom User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: dev@cocoon.apache.org Subject: Re: Difference between FOM_Session and REal Session? References: <41F264CA.1060906@nada.kth.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N 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