Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-ID: <FDCEAB9D7DE70246A419ECF68553D10456B823@POSTMAN.flagship.ru>
From: Konstantin Piroumian <KPiroumian@protek.com>
To: "'cocoon-dev@xml.apache.org'" <cocoon-dev@xml.apache.org>
Subject: RE: continuation fear (was Re: [status & RT] design challenges) 
Date: Wed, 10 Apr 2002 14:19:50 +0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="koi8-r"

> -----Original Message-----
> From: Ivelin Ivanov [mailto:ivelin@apache.org] 
> Sent: Wednesday, April 10, 2002 6:48 AM
> To: cocoon-dev@xml.apache.org
> Subject: Re: continuation fear (was Re: [status & RT] design 
> challenges) 
> 
> 
> 
> I came across this article today.
> Real Java Pet Store:
> http://www.theserverside.com/resources/article.jsp?l=PetStore
> 
> It reminded me of the good ol' Java Pet Store.
> I thought that it may not be a bad idea if we
> implement the front end in Cocoon and use it as a primary demo.

Yes, it would promote Cocoon a lot.

> 
> Of course we may decide to write our own complex demo 
> applications, but why
> not follow
> the path which proved successful for others. Oracle, IBM, 
> WebLogic and even
> M$ built their
> customized versions of the Pet Store to show muscles.
> 
> This is what I think needs to happen:
> 1) Remove persistance or maybe just EJBs to allow the demo to run as a
> regular cocoon app under /mount, without requirements for EJB 
> container.

This will remove also the most important part of the original petStore ;)

> 2) Implement the control flow with our new super-sitemap. 
> (which I still
> don't quite understand :)

Do you mean Schecoon?

> 3) Implement Form handling.

We should do it anyway.

> 4) Add a few simple interactive calls to external web services. (like
> current time service for the user selected time zone)

This would be fine, but not required...

> 
> I don't think we need to worry about keeping the original 
> code intact. (M$
> didn't anyway :)

Did M$ implement simply their own version? Have to look at it...

> 
> People recognize the name and they know that the "Pet Store" 
> is the place to
> look for best practices and patterns ideas.
> 
> I am interested in providing impl for 3).
> 
> Any volunteers for the other parts?

I think that if we undertake this task then we should implement it in all,
including EJB stuff. We can simply use say the petStore demo from WebLogic
and create our own web-client application for it.

Regards,
  Konstantin

> 
> 
> Cheers,
> 
> Ivelin
> 
> 
> 
> ----- Original Message -----
> From: "Ovidiu Predescu" <ovidiu@cup.hp.com>
> To: "Konstantin Piroumian" <KPiroumian@protek.com>
> Cc: <cocoon-dev@xml.apache.org>
> 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
> <KPiroumian@protek.com> 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");
> > }
> >
> > The user can go back and forth to modify values in the forms from
> > page1, page2 and page3. As soon as the user is presented with the
> > "finish" page, you want to disallow the ability to go back in the
> > browser history and modify the values in page1, 2 or 3.
> >
> > The continuations are organized in a tree, with each node 
> in the tree
> > being a continuation. If the user doesn't hit the "back" 
> button in the
> > browser, and continues the computation with different 
> values, the tree
> > of continuations degenerates to a list. E.g. in the above case, the
> > tree would look like:
> >
> >  start -> page1 -> page2 -> page3
> >
> > If the user goes back to page1 for example, or creates a new browser
> > window which displays page1, then changes some values in 
> this page and
> > hits the submit button, the tree would look like this:
> >
> >  start -> page1 -> page2 -> page3
> >             \
> >              ----> page2
> >
> > This is a great way for the user to experiment with "what if"
> > scenarios. How many times you went to Amazon and played with the
> > shopping cart to see which items you can buy? This is a very good
> > example of such a scenario.
> >
> > Now suppose the user reaches clicks the submit button on page3. When
> > this happens the "finish" page is generated, and the associated
> > continuation added in the tree:
> >
> >  start -> page1 -> page2 -> page3 -> finish
> >             \
> >              ----> page2
> >
> > This will commit the transaction started right after the "start"
> > page. Now suppose you want to disallow the user to hit the "back"
> > button and restart the computation, in _all_ the browser windows the
> > user started.
> >
> > The only thing you need to do is invalidate the continuation
> > associated with the start page, which in turn will 
> invalidate all the
> > continuations in its subtree. Invalidation means that you remove the
> > association between the continuation id present in all the user's
> > pages. You can associate those ids with a function that displays and
> > error page, telling the user he/she cannot go back after the
> > transaction has been completed. The modified script would look like
> > this:
> >
> > function transaction()
> > {
> >   var kstart = sendPage("start");
> >   ...
> >   beginTransaction();
> >   ...
> >   sendPage("page1");
> >   ...
> >   sendPage("page2");
> >   ...
> >   sendPage("page3");
> >   ...
> >   commitTransaction();
> >
> >   // Invalidate all the continuations started from kstart, and
> >   // associate their id with the "errorPage" function, 
> which tells the
> >   // user he/she cannot go back anymore.
> >   kstart.invalidate(errorPage);
> >   ...
> >   sendPage("finish");
> > }
> >
> > function errorPage()
> > {
> >   sendPage("errorPage");
> > }
> >
> > You can also associate timeouts with the created 
> continuations, so if
> > the user doesn't access the page in a while, they automatically
> > expire. I'm still working on this feature.
> >
> > > > > Perhaps Ovidiu's proposed uses of continuations are 
> elegant > >
> > > > > enough, or the current scripting/continuation-capture 
> mechanism
> > > > > is > > efficient and minimal enough, to address both these
> > > > > concerns.
> > > >
> > > > The usage of the framework is fairly simple, and the notion of
> > > > continuation is not exposed explicitly when you're doing
> > > > programming as end user programmer.
> > >
> > > In some cases one would like to handle continuation 
> explicitly. Is it
> > > possible now?
> >
> > Yes, see the above example. I'm still working on finishing 
> up some of
> > the features, but I hope you get an idea of how continuations are
> > manipulated.
> >
> > > > I certainly hope Cocoon will change for the better in the very
> > > > near future.
> > >
> > > And we will do our best for that. One of the things that will make
> > > this happen is to develop more real world samples and
> > > applications. One of the reasons why Struts is more popular it's
> > > availabilty of good sample applications and best practices
> > > documents.
> >
> > I know, that's why I was thinking to start working on the simple Web
> > site shopping application.
> >
> > I hope this helps in understanding how continuations are used in
> > Schecoon. If not, please ask for more clarifications.
> >
> > Best regards,
> > --
> > Ovidiu Predescu <ovidiu@cup.hp.com>
> > http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, 
> Emacs, other
> stuff)
> >
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> > For additional commands, email: cocoon-dev-help@xml.apache.org
> >
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
> 

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