cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steinar Jonsson <sjons...@online.no>
Subject Re: Are nested flowscripts possible?
Date Mon, 01 Dec 2003 00:24:58 GMT
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

Mime
View raw message