You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Marc Portier <mp...@outerthought.org> on 2003/11/27 23:53:42 UTC
Re: Are nested flowscripts possible?
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)
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: Are nested flowscripts possible?
Posted by Steinar Jonsson <sj...@online.no>.
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
Re: Are nested flowscripts possible?
Posted by Marc Portier <mp...@outerthought.org>.
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?
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
> 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 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?
> Do not assume that I know what I'm talking about, because I don't. This
> is just part of my struggle to understand how to use cocoon efficiently.
>
that's the spot we are all in ;-)
you seem to have an interesting use case, talking about those generally
helps us all in the end
> Many thanks to you Marc and all you others that take the time to answer
> questions here. I've been lurking for some time, and have learned a lot.
>
quite welcome, looking forward to more activity from your side
(no need to be shy)
regards,
-marc=
--
Marc Portier http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://radio.weblogs.com/0116284/
mpo@outerthought.org mpo@apache.org
Re: Are nested flowscripts possible?
Posted by Steinar Jonsson <sj...@online.no>.
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.
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.
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.)
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.
I would be happy to have comments on this, even explanations of why this
can't or shouldn't be done.
Do not assume that I know what I'm talking about, because I don't. This
is just part of my struggle to understand how to use cocoon efficiently.
Many thanks to you Marc and all you others that take the time to answer
questions here. I've been lurking for some time, and have learned a lot.
Regards
Steinar Jonsson