You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruno Dumon <br...@outerthought.org> on 2003/07/18 00:04:56 UTC
Woody-flow to FOM migration question
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?
And that brings up a more essential point: the reason for not using
sendPageAndWait? I guess it's because of the tricks with the
lastWebContinuation thing, but I don't understand the purpose of that.
If my intuition is right it forces the parent continuation of the new
continuation to be the last created continuation for this form, rather
than the current continuation. There's a note that this will be used to
implement automated back navigation, but I don't get it yet. Could you
give some more explanation?
Thanks,
Bruno
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Woody-flow to FOM migration question
Posted by Bruno Dumon <br...@outerthought.org>.
On Sat, 2003-07-19 at 06:00, Christopher Oliver wrote:
<snip>
> >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...
>
Actually, I've become used to the idea now (JS allows limited access --
if you need to do more you can go via Java). It was suprising at first
that a Java class created and called from the flowscript was able to
access stuff that the flow itself didn't have access to.
<snip>
>
> >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.
ok. Is getURIPrefix() really needed? It seems like this is added always
when forwardTo() is called, so maybe it can be hidden in the
implementation of forwardTo?
Regards,
Bruno
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
RE: Woody-flow to FOM migration question
Posted by Reinhard Pötz <re...@gmx.net>.
> 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.
I don't think it is the best idea to make the object model available in
the flow. It would be better to provide it in the Context. IIRC it was
Sylvain and Carsten who told me that we already agreed on this but it
has not been implemented yet. Maybe this is a good reason ... ;-)
Cheers,
Reinhard
Re: Woody-flow to FOM migration question
Posted by Christopher Oliver <re...@verizon.net>.
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
Re: Woody-flow to FOM migration question
Posted by Bruno Dumon <br...@outerthought.org>.
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?
> >
> >
> Yes.
>
> >And that brings up a more essential point: the reason for not using
> >sendPageAndWait? I guess it's because of the tricks with the
> >lastWebContinuation thing,
> >
> Yep.
>
> > but I don't understand the purpose of that.
> >If my intuition is right it forces the parent continuation of the new
> >continuation to be the last created continuation for this form, rather
> >than the current continuation. There's a note that this will be used to
> >implement automated back navigation, but I don't get it yet. Could you
> >give some more explanation?
> >
> >
> >
> The way it works is that a continuation is created immediately before a
> page is sent and immediately after it is sent (the latter is just like
> what sendPageAndWait does).
>
> To go "forward" in the form you invoke the latter continuation, again
> just like sendPageAndWait().
>
> But to go "back" you invoke the continuation 3 levels higher in the tree:
>
> level 0) causes the actions after the current page is submitted to be
> performed (this is "forward", as above)
> level 1) causes the current page to be resent
> level 2) causes the actions after the previous page was submitted to
> be performed
> level 3) causes the previous page to be resent (this is "back")
>
> So to implement automated back/forward navigation you simply encode the
> continuation id and the desired action ("back" or "forward") somehow in
> the form. Then when the form is submitted you invoke the appropriate
> continuation.
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?
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)
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?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org bruno@apache.org
Re: Woody-flow to FOM migration question
Posted by Christopher Oliver <re...@verizon.net>.
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?
>
>
Yes.
>And that brings up a more essential point: the reason for not using
>sendPageAndWait? I guess it's because of the tricks with the
>lastWebContinuation thing,
>
Yep.
> but I don't understand the purpose of that.
>If my intuition is right it forces the parent continuation of the new
>continuation to be the last created continuation for this form, rather
>than the current continuation. There's a note that this will be used to
>implement automated back navigation, but I don't get it yet. Could you
>give some more explanation?
>
>
>
The way it works is that a continuation is created immediately before a
page is sent and immediately after it is sent (the latter is just like
what sendPageAndWait does).
To go "forward" in the form you invoke the latter continuation, again
just like sendPageAndWait().
But to go "back" you invoke the continuation 3 levels higher in the tree:
level 0) causes the actions after the current page is submitted to be
performed (this is "forward", as above)
level 1) causes the current page to be resent
level 2) causes the actions after the previous page was submitted to
be performed
level 3) causes the previous page to be resent (this is "back")
So to implement automated back/forward navigation you simply encode the
continuation id and the desired action ("back" or "forward") somehow in
the form. Then when the form is submitted you invoke the appropriate
continuation.
Regards,
Chris