On Tue, 9 Apr 2002, Ovidiu Predescu wrote: > I was looking at exactly the same application. One of my colleagues > here is in fact working in transforming some of the backend EJB > services with Web services, so it may be a good way to capitalize on > his work. > > One problem with this application however is that it's fairly complex > and difficult to understand, if you're not already familiar with > it. The easiest approach to implement it I believe is to not even look > at their code, but instead try to implement it from scratch using > Cocoon concepts. However this approach may miss the point, which in > the case of taking an existing app like PetStore would be to show how > Cocoon can be used to provide the front-end for J2EE services or Web > services. Also there are lots of politics already around this > application, which may be both good and bad for Cocoon to come up with > yet another implementation. > > What do others think?
More than one year ago we (Otego AG, Switzerland) had to write a shop similar to the "Pet Store" for demonstration purposes. Of course we would rewrite it now because many new cocoon features concerning web apps and especially db access/modification and form handling/validation have seen their light during the last year. The functionallity is not complete (no admin console at all) but it shows how a shop can look like (functionallity wise). Unfortunately it is in German and there is no i18n features integrated because it was not requested. But you should be able to play with it intuitively (or use http://dict.leo.org/ for translations :). You can have a look at it using http://fw.otego.com/demoshop/ Giacomo > > Ovidiu > > On Tue, 9 Apr 2002 21:47:37 -0500, "Ivelin Ivanov" <[EMAIL PROTECTED]> wrote: > > > > > 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] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, email: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
