cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mats Norén <m...@alma.nu>
Subject Re: [RT] Forms and wizards (was: RE: HEADS UP - cocoon form handling (long!!))
Date Mon, 29 Apr 2002 08:08:39 GMT

----- Original Message -----
From: "Ovidiu Predescu" <ovidiu@apache.org>
To: "Mats Norén" <mats@alma.nu>
Cc: <cocoon-dev@xml.apache.org>
Sent: Saturday, April 27, 2002 4:39 AM
Subject: Re: [RT] Forms and wizards (was: RE: HEADS UP - cocoon form
handling (long!!))


> On Fri, 26 Apr 2002 15:02:55 +0200, =?iso-8859-1?Q?Mats_Nor=E9n?=
<mats@alma.nu> 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? ;-)

:) Yes it does!
But there is a some use to it. The sitemap can be seen in this context to be
an XML processing framework for business data.

> 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.

Hmm..I tend to agree...but I really like the modular database actions... :)

>
> > 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.

I´ve tried this over the weekend and it works. I made a modified
sendPageAndReturn function in the system.js and it is possible to execute an
action and then call map:continue.

>
> 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.

I´ve been using that jpath logicscheet for the test application we built and
it works great.

<snip/>

>
> > 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.
>

By include statements I mean that we dynamically based on the information
from the flowscript adds one or several cincludes to the xml stream. These
includes in turn calls the pipelines from the sitemap, something like:

flowscript=>sitemap=>xsp=>cinlude=>sitemap again * nr of
components=>xsp=>xslt=>client

where it would be nice to do:

flowscript=>sitemap * nr of components=>xsp=>xslt=>client

<snip/>

> 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.
>

Again, it was more a point of reusing the already existing modular database
actions.
Since they are components I guess it wouldn´t be that much of a hassle to
integrate them into the flowscript?

> > 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 ;-)
>

:)

Regards Mats



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message