Ovidiu,
Is there a way to generate an URI with the current continuation to the
sitemap?
Let´s say that I have defined a simplistic sitemap like this:
<map:pipeline>
<map:match pattern="start">
<map:call function="startFunction"/>
</map:match>
<map:match pattern="doAction/*">
<map:act type="action"/>
<map:continue with="{1}"/>
<map:match>
</pipeline>
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
scratchpad?
Keep up the good work!
Regards,
Mats
----- Original Message -----
From: "Ovidiu Predescu" <[EMAIL PROTECTED]>
To: "Mats Norén" <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other
stuff)
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
