On Fri, 26 Apr 2002 15:02:55 +0200, =?iso-8859-1?Q?Mats_Nor=E9n?= <[EMAIL PROTECTED]> wrote:
> 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.
Gosh, this becomes really crazy, doesn't it? ;-)
Why would you spend the CPU time to forward the request to the sitemap
to do an action, rather than calling the database from the flow script
directly? I think this is much easier to write and maintain later on.
> So the question I always ask you is: Is this possible? :)
Sure it's possible, but again this is not a good usage of the flow
layer. sendPage() forwards the request to the sitemap, and doesn't
care what the sitemap does with it further. So, at least in theory,
you should be able to have a matching pipeline that invokes the flow
layer again, to do some more processing.
You don't need to pass anything to sendPage(), this function will
create the continuation and put it in the Environment object, to be
accessed later from the pipeline. If you're using an XSP generator,
you can make use of the jpath logicsheet, and obtain the id of the
continuation using the <jpath:continue/> element.
> 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?
See above.
> Are there any plans of using the flowscript to assemble pipelines
> dynamically? Or I should say doing aggregation dynamically?
It should be possible, but I think it will break the separation of
concerns.
> 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);
> }
In theory you should be able to do this, the former Scheme-only
implementation of Schecoon transformed the sitemap into Scheme code
that did exactly this.
The current implementation however doesn't do it, but if you really
want, you can probably do it easily. This is not to say that it will
be a blessed thing to do ;-) For speeding up the development time the
interpreted sitemap is probably your best bet.
> 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. :)
What do you mean by the include statements and transformer? When you
use XSP, the markup page you write is translated into a Java class,
which is then simply executed. After the first page compilation, there
is no overhead associated with this.
> 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.
To continue the idea at the beginning of the message, I think the best
approach is to have the flow script call you Java business logic, and
when that's finished, to call the page generation. Putting application
logic in your XSP pages using logicsheets is IMO hard to reuse across
the application.
> One final question, the sendPageContinue-function mentioned in an earlier
> mail is that something that will eventually make its way into the
> scratchpad?
Yes, I've committed it last night, a one-liner function really ;-)
> Keep up the good work!
Yep, thanks!
Ovidiu
> 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]
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
