On Fri, 2003-07-18 at 06:37, Christopher Oliver wrote:<snip>
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?=
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.
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?
The Request and other such objects are made available to Java code, but not to JS. I don't know if that's unnatural...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...
(I didn't follow the early FOM discussions so please excuse my ignorance
about all this)
No problem.
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.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?
Chris
