cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mats Norén <>
Subject Re: [RT] Forms and wizards (was: RE: HEADS UP - cocoon form handling (long!!))
Date Fri, 26 Apr 2002 13:02:55 GMT
Is there a way to generate an URI with the current continuation to the
Let´s say that I have defined a simplistic sitemap like this:

    <map:match pattern="start">
        <map:call function="startFunction"/>

    <map:match pattern="doAction/*">
        <map:act type="action"/>
        <map:continue with="{1}"/>

I would like from within the current flowmap to call:

    sendPage("doAction/" + continuation, bizdata);

This would make it possible for me to use a pipeline for storing data to a
database with the esql or maybe the sql-transfomer from within the
flowscript and without returning anything to the client but instead return
to processing of the next scriptline.
So the question I always ask you is:  Is this possible? :)
If so, how do I get the value of the continuation beforehand so to speak?
By looking at the system.js I figured that the continuation id isn´t
available when I call the sendPage function, or am I missing something?
Are there any plans of using the flowscript to assemble pipelines
dynamically? Or I should say doing aggregation dynamically?
The contract with the user is the uri and by cleverly designing your sitemap
you shouldn´t have to assemble your pipelines dynamically...I think stefano
once said something along those lines. This may very well be the case but it
would simplify the development of our webapplications a great deal if there
was a way the aggregate pipelines from within the flowscript and then call
sendPage on them as a sort of "commit".

function showPortal() {
var aggregation = new Aggregation();
...some logic...
aggregation.add(pipelineURI, element, ns);
...some logic
aggregation.add(pipelineURI, element, ns);
sendPage(aggregation, bizdata);

The way we try do it now is by doing a sendPage with pipelineURI:s as
bizdata to an XSP-page wich in turn generates include statements which are
then processed by the include transformer which in turn calls the pipelines.
This seems like a waste of  cycles if it is possible to do it from within
the flowscript. :)
Another sideeffect is that the logic of which components to show ends up in
the XSP:page. Note that we are not trying to do all the application logic
inside the flowscript just some rendering decisions.

One final question, the sendPageContinue-function mentioned in an earlier
mail is that something that will eventually make its way into the

Keep up the good work!


----- Original Message -----
From: "Ovidiu Predescu" <>
To: "Mats Norén" <>
Cc: <>
Sent: Tuesday, April 16, 2002 9:23 PM
Subject: Re: [RT] Forms and wizards (was: RE: HEADS UP - cocoon form
handling (long!!))

> On Tue, 16 Apr 2002 20:01:28 +0200, Mats Norén <> wrote:
> > Ovidiu,
> >
> > > I think actions should work fine if you put them right before
> > > <map:call function="..."/> in a pipeline. Actions don't generate any
> > > SAX events on the pipeline, so they should not interfere with the
> > > later invocation of the sitemap via sendPage() or
> > > sendPageAndContinue() functions.
> >
> > I was more thinking about a way to dynamically plug them into the
> > flow-scripts.. :)
> > Since they don´t interfere with the pipelines...
> > DatabaseActions in perticular could prove useful.
> > I remember that there were some discussions about actions and their
> > whereabouts but I don´t remember the conclusions (if there were any) :)
> So how would you like to describe these actions? Have them be invoked
> without you coding an explicit function call to them?
> What you can do is call a trampoline function, which does the action
> first, and then calls your function. Something like this:
>   <map:match pattern="...">
>     <map:call function="doAction">
>       <map:parameter name="func" value="startFlow"/>
>       // Arguments for the 'startFlow' function if any should go here
>     </map:call>
>   </map:match>
> In your script you'd then have something like:
> function doAction(func, args)
> {
>   // Do your action here
>   ...
>   // Now call the function that executes the control flow
>   func.apply(this, args);
> }
> function startFlow(arg1, arg2, arg3 etc.)
> {
>   // Do your flow here
> }
> To also have the actions executed when continuations are restarted,
> I'll add the ability to specify a different function that handles
> them. You'll then be able to specify your own continuation restarting
> function (currently that's hard-coded to
> handleContinuation). Something like this:
> function myContinuationHandler(kont, args)
> {
>   doAction(kont.continuation, args);
> }
> Is this the same thing you were looking for?
> Greetings,
> --
> Ovidiu Predescu <>
> (GNU, Emacs, other
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, email:

To unsubscribe, e-mail:
For additional commands, email:

View raw message