Hi,
I'll add my 2ec regarding the topic:
I agree what it has been said here about each page being modeless and
that you have to be careful in case some users get out of the "normal
application path" through the back button, shift click... My approach in
such systems has been not to trust the user and not to presuppose what
will be the next action requested by him. That means that you model the
kernel of your flow control as a state machine which might based in
something like that:
Current State | Request Type | Action to Perform | Next State
-----------------------------------------------------------------------
VOID OpenBasket openUserBasket BASKET_OPENED
VOID OTHERS showError VOID
BASKET_OPENED AddItem addItemToUserBasket BASKET_OPENED
BASKET_OPENED RemoveItem removeItemFromUserBasket BASKET_OPENED
BASKET_OPENED closeBasket closeBasketAndCharge CONFIRM_PENDING
BASKET_OPENED OTHERS showError BASKET_OPENED
...
Then if the user get's out of sync, he'll get an error because the state
machine specifies which are the acceptable inputs on each state and the
appropriate answer in each case. After getting 20-30 error pages,
they'll stop fooling around with the application and they'll learn how
to use it appropriately ;).
Just my 2ec (less than 2 cents right now :))
Dan
-------------------------------------------
Daniel Lopez Janariz ([EMAIL PROTECTED])
Web Services
Computer Center
Balearic Islands University
-------------------------------------------
Andrew S Tomlinson wrote:
>
> Well broadly yes.
> Just make sure we do not confuse workflow with transaction.
> A *multi-page form* is in my context a workflow; each page in the flow
> submits to an action that performs a discrete transaction. As David points
> out each page needs to be self-contained. We have both concluded the
> critical need for concurrency rules for each discrete transaction.
>
> Now, to David's point each page is modeless and valid in of itself.
> What I want do in my apps is to "thread" them together via the workflow that
> I implement as a *state-machine* for want of a better term.
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
