On Wed, 10 Apr 2002 20:54:19 -0500, "Ivelin Ivanov" <[EMAIL PROTECTED]> wrote:
> I'll keep asking dummy questions until I start to get the picture or you
> stop responding ;)
Please keep asking if you see I don't respond ;-) There was a lot of
traffic these days on the mailing list, and I know I forgot to answer
to few messages I wanted to.
> ----- Original Message -----
> From: "Ovidiu Predescu" <[EMAIL PROTECTED]>
> To: "Konstantin Piroumian" <[EMAIL PROTECTED]>
> Cc: <[EMAIL PROTECTED]>
> Sent: Tuesday, April 09, 2002 1:34 PM
> Subject: Re: continuation fear (was Re: [status & RT] design challenges)
>
>
> > On Tue, 9 Apr 2002 12:34:17 +0400 , Konstantin Piroumian
> <[EMAIL PROTECTED]> wrote:
> >
> > > > In Schecoon you don't deal with continuations directly,
> > > > they're hidden under the cover. The only thing you see is a
> > > > sendPage() function, which sends the response page and
> > > > interrupts the processing, only to resume it later when the
> > > > following request comes along.
> > >
> > > What if you don't need to continue processing from an old
> > > position? Say, the user passed several steps in wizard and that
> > > resulted in some business calls. Returning back to one of the
> > > previous state would require a > either an intelligent rollback
> > > of operations or an error message telling that the > user cannot
> > > go back. With our XML flow approach each of this situations can
> > > > be handled on developer's discretion.
> >
> > You have fine control over the lifetime of created
> > continuation. The sendPage() function returns a continuation
> > object, which can manipulate directly if you want to.
> >
> > Suppose the user has to complete a multipage form which is part of
> > a transaction. The script would look like this:
> >
> > function transaction()
> > {
> > sendPage("start");
> > ...
> > beginTransaction();
> > ...
> > sendPage("page1");
> > ...
> > sendPage("page2");
> > ...
> > sendPage("page3");
> > ...
> > commitTransaction();
> > ...
> > sendPage("finish");
> > }
>
> In this flow, how do you implement a jump from page1 to 2 or 3
> depending on the user selection. To reuse Konstantin's example, say
> on the first page the user checks a box whether s/he has a car or
> not. Then page 2 collects information about the car, but its
> optional depending on the selection in 1.
>
> Could you fill in the "..."s in the snippet above.
I thought this was obvious, sorry about this. Here it goes.
Say the checkbox could be obtained from the request using the "hasCar"
name. You can then write something like this:
function transaction()
{
...
sendPage("page1");
var hasCar = cocoon.request.getParameter("hasCar");
// do some other stuff to prepare page2, then send it
...
sendPage("page2");
// now if the user has a car we need to ask information on the car
if (hasCar) {
sendPage("getCarInfo");
var make = cocoon.request.getParameter("make");
var model = cocoon.request.getParameter("model");
var color = cocoon.request.getParameter("color");
// pass the above information to the Java business logic to insert
// it in a database
}
// now ask other questions
sendPage("restOfQuestions");
...
}
The idea is that since the flow control is a full programming
language, you can do pretty much everything in it.
As you notice the flow control is acting the Controller in the
Model-View-Controller paradigm (MVC). The Model is the business logic
behind, and the View is invoked using sendPage().
The above sendPage() is actually a simplification, what you pass to it
is not only the URL to be interpreted by the sitemap, but also an
object, an array of a dictionary containing information to be placed
into the generated output by the View, e.g. by the generator in the
matching pipeline. In this model, the generator no longer needs to do
any business logic, it just extracts the data from the object passed
to it. The jpath.xsl logicsheet does this for XSP, but this was only a
quick way to implement it. In the near future I'll come up with a
simple transformer which could be placed in the pipeline, that does
the same thing.
The above MVC programming model will render obsolete XSP and all the
other page centric approaches to Web programming. The MVC model I
propose will introduce a very clear separation between the layers of a
Web application.
Does this make sense?
Regards,
--
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]
