Return-Path: 
 <dev-return-45206-apmail-cocoon-dev-archive=cocoon.apache.org@cocoon.apache.org>
Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org
Received: (qmail 22936 invoked by uid 500); 19 Jul 2003 04:00:13 -0000
Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@cocoon.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@cocoon.apache.org>
list-post: <mailto:dev@cocoon.apache.org>
Reply-To: dev@cocoon.apache.org
Delivered-To: mailing list dev@cocoon.apache.org
Received: (qmail 22922 invoked from network); 19 Jul 2003 04:00:12 -0000
Received: from pop016pub.verizon.net (HELO pop016.verizon.net)
 (206.46.170.173)
  by daedalus.apache.org with SMTP; 19 Jul 2003 04:00:12 -0000
Received: from verizon.net ([4.40.118.187]) by pop016.verizon.net
          (InterMail vM.5.01.05.33 201-253-122-126-133-20030313) with ESMTP
          id <20030719040022.NIA3199.pop016.verizon.net@verizon.net>
          for <dev@cocoon.apache.org>; Fri, 18 Jul 2003 23:00:22 -0500
Message-ID: <3F18C251.9000007@verizon.net>
Date: Fri, 18 Jul 2003 21:00:17 -0700
From: Christopher Oliver <res1cf5x@verizon.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US;
 rv:1.0.2) Gecko/20030208 Netscape/7.02
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@cocoon.apache.org
Subject: Re: Woody-flow to FOM migration question
References: <1058479466.30058.62.camel@yum.ot>	 <3F177994.3020706@verizon.net>
 <1058560893.6422.79.camel@yum.ot>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
X-Authentication-Info: Submitted using SMTP AUTH at pop016.verizon.net from
 [4.40.118.187] at Fri, 18 Jul 2003 23:00:22 -0500
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

Bruno Dumon wrote:

>On Fri, 2003-07-18 at 06:37, Christopher Oliver wrote:
>  
>
>>Bruno Dumon wrote:
>>
>>    
>>
>>>FOMmers, Chris mostly,
>>>
>>>I'm looking at porting the Woody-Flow integration to the FOM. This is
>>>all new stuff for me, but just to check that I'm on the right track: is
>>>it correct that things like new WebContinuation(...) and
>>>cocoon.forwardTo(...) can now only be done in Java code?=
>>>
<snip>

>>>      
>>>
>Ah, now I see. Woody doesn't support (yet?) multi-page forms like jxform
>does, so currently it serves only as a provision for the future.
>
>Looking further, I see that in the JXForm implementation you work around
>this by providing the methods makeWebContinuation() and forwardTo() as
>part of the JXForm object. These methods don't seem to be related to the
>JXForm object itself, but seem to be merely there to work around the
>limitations of the FOM, and in the end the flowscript again does have
>the same capability. Doesn't it make sense then to include them in the
>FOM?
>  
>
No. I think the idea is that we don't want to expose these directly to 
flow scripts. However, to implement JForm some of the work (creating 
continuations) has to be done in JavaScript, and can't be done in Java. 
That's why I had to expose those functions to JS. But they are intended 
to be internal implementation details of JXForm and not used by other 
scripts. You'll have to do the same for Woody.

>Another problem I stumbled onto: Woody needs to be passed the Request
>object (as part of the FormContext object but that doesn't matter now).
>As is well known, flowscript doesn't give access to this. Looking at
>JXForm again, I see again a similar workaround. I could do the same for
>Woody of course, but it all starts to feel a bit unnatural...
>
The Request and other such objects are made available to Java code, but 
not to JS. I don't know if that's unnatural...

>
>(I didn't follow the early FOM discussions so please excuse my ignorance
>about all this)
>  
>

No problem.

>Then on a less related note: I noticed that the JXForm class uses the
>Environment. Wasn't this interface supposed to be internal to Cocoon (I
>don't consider a block to be Cocoon internals)? Maybe we should limit
>the public interface of the FOM_Cocoon class?
>
>  
>
I wasn't aware of the status of Environment. It's there simply because 
it was in the original flow implementation. It should be easy enough to 
only expose the features of Environment that are needed ( getURIPrefix() 
and getObjectModel()) rather than the entire object. I don't think 
FOM_JavaScriptInterpreter should be exposed either. I'll try to make 
these changes.

Chris