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.
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.
2) Implement the control flow with our new super-sitemap. (which I still
don't quite understand :)
3) Implement Form handling.
4) Add a few simple interactive calls to external web services. (like
current time service for the user selected time zone)
I don't think we need to worry about keeping the original code intact. (M$
didn't anyway :)
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?
Cheers,
Ivelin
----- 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");
> }
>
> 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 <[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]
