On Friday 28 November 2003 09:32, Marc Portier wrote:
> Steinar Jonsson wrote:
> > On Thursday 27 November 2003 23:53, Marc Portier wrote:
> >>Steinar Jonsson wrote:
> >>>A flowscript does a sendPageAndWait( request ), and the
> >>>request happens to start a second flowscript.
> >>>
> >>>When that second flowscript has completed its work,
> >>>how does it get back to where the first one left off?
> >>>
> >>>I can't see how to get hold of that continuation id.
> >>>Am I just being blind, or is this a bad idea altogether?
> >>
> >>yep, it's not how you use this stuff
> >>
> >>
> >>what I think you try to do is this:
> >>
> >>uri-1 --> calls function1
> >>function1() {
> >> // do-stuff
> >> sendPageAndWait(nextPage-uri);
> >>}
> >>
> >>on the produced page there is NOT a link with the continuation, but
> >>rather a link to some uri-2 --> calls function2
> >>
> >>function2() {
> >> //do other stuff.
> >>
> >>}
> >>
> >>
> >>this creates completely separate trees of continuations (meaning they
> >>are not nested at all)
> >>
> >>
> >>
> >>rather one would go for this:
> >>
> >>uri-1 --> calls function1
> >>function1() {
> >> // do stuff
> >>
> >> function2(); //nested call to function 2
> >>
> >> // when function2 is finished, we continue here
> >> // do more...
> >>}
> >>
> >>function2() {
> >> sendPageAndWait(nextPage-uri);
> >> // do whatever with the return
> >>
> >>}
> >>
> >>and make sure that the return page _is_ just producing the link back to
> >>the generated continuation.
> >>
> >>you can still have some uri-2 that starts off with function2 immediately
> >>(not nested inside function1 I mean)
> >
> > Good analysis and explanation. Thanks.
> >
> > Your suggested pattern can certainly provide the functionality required,
> > but I also had this idea about a way of partitioning my application,
> > sort of a really poor man "real blocks".
> >
> > Let me try to explain:
> > Function 1 is a framework that serves status and navigation pages. From
> > config or a workflow component or whatever, it gets a list of uri's of
> > the "application parts" it can start.
>
> can? it functions like a menu?
Sort of. At each stage of a workflow there will be a number of possible
things to do, either for moving the process forward, or for using the results
available at that stage. And the whole process is periodic.
> or rather 'must' since it lists the sequence of parts in the flow?
>
> in any case:
> you could consider building a JavaScript object that has a Map of
> registered available functions:
>
> //start js-snippet
>
> registerOfAppParts["part2"]=function2;
> //and more
>
> //then later you could detect dynamically the part to execute
> var partName = "part2";
> registerOfAppParts[partName](); //this executes function2!!
>
> // those registered functions can receive arguments but then
> // need all to provide the same signature of course (think interface)
>
> // end js-snippet
I wasn't aware that I could load scripts and call functions like this. It
seems to do just what I need. Also keeps more of the application flow
logic clearly visible in javascript, which is good IMO.
>
> > Each "application part" is packaged in its own subdirectory, and parts
> > can be added or removed just by adding or removing subdirectories in sync
> > with the config / workflow setup.
>
> I can't say I completely understand
> but since the sync-ing needs to be done, you could also just update the
> list of methods to call in stead of the list of uri's ?
>
> > The framework script knows how to start a part using its uri. A part
> > knows how to return to the framework script by using the continuation id.
> > (There's more to it of course. Parameters, status, skins etc.)
>
> yeah, this would call for some Context-object as an argument to the
> various functions... you might even want to take two arguments for
> WorkFlowContext and WorkFlowReturn depending on what it all needs to do.
> (the latte is a bit modeled after the servlet.service(request, response))
>
> in any case you would just 'return' to the main branch by returning the
> function (as explained previously)
>
> > This scheme actually seems workable in those cases where the part being
> > called has access to the continuation id, like a JXTemplateGenerator.
> > I'd be surprised if it wasn't technically possible to pass continuation
> > id through sendPageAndWait() to a flowscript as well.
>
> dunno, I guess, but it sounds like serious hacking and thus dependecy on
> how continuations are identified... also sounds a bit like potential
> subversion of control
I'll chew on this a bit more, even if it seems you've pushed me in a
more productive direction.
>
> > I would be happy to have comments on this, even explanations of why this
> > can't or shouldn't be done.
>
> I think it can work, but you might be needing to turn around your
> thinking to get it more smoothly?
Well, I did, and it helped. Lots of work remaining before anything is
usable, but one less potential showstopper to worry about.
Thanks again for your input.
Regards
Steinar Jonsson
