danny wrote:
In article <Xn*******************************@130.133.1.4>,
eb******@earthlink.net says... danny <da*@ebji.org> wrote in
news:MP************************@news.newsreader.co m:
Actually, It's not for an internet application. I'm building a thin
client application. It's a call center application, and when a
contact is closed, they are supposed to enter data. Problem is,
because it's a browser, they can just click the X mark and close the
window, which leaves the contact waiting for data to move to another
state. If I could pop the window back up and request the data again,
that is acceptable, but I haven't yet figured that out.
You need to properly handle that on the server end since you also have to
deal with contingencies like the client machine crashing, the client
machine losing power, or a network outage, all of which could result in no
data being entered at a particular state in the application.
Yes, the server side needs to be addressed as well (as you note, clients
purposely closing the window isn't the only issue...) but the big
problem is call transfer. When there's an outage, the switch drops the
call, but when the client closes the window, the call is in limbo on the
switch...
So you make the transaction atomic. That is to say, you don't change the state
of the item in the database, then ask for additional information, because if
the additional information is not forthcoming, the item will be in the incorrect
state, with missing data.
So instead, you record that you want to change the state of the item, you
request the information, and then, only if all the data was received and
validated properly, you change the state and update the data in the database.
One way to do this might be to actually introduce a new "state" for the items,
which says "the user requested a state change on this item", then when you
recieve the additional data, you change it from that state to the completed
state. That way, if the user requests a state change, then don't supply the
additional data, you have a way of notifying them of items in a pending state
change the next time they log in.
1. User requests state change
2. Change state from "open" to "pending closed"
3. User supplies additional data
4. If additional data is valid, change state from "pending close" to "close"
The next time they log in, you query the database for items in "pending close"
state and display "You have XX item(s) in a 'pending close' state, do you want
to supply the additional data for these item(s) now?" If they chose not to do
this, the items will remain in the "pending close" state and will be displayed
the next time they log in, otherwise you execute the code path for #3 above,
which allows them to supply the additional information, which completes the
state change.
--
| Grant Wagner <gw*****@agricoreunited.com>
* Client-side Javascript and Netscape 4 DOM Reference available at:
*
http://devedge.netscape.com/library/...ce/frames.html
* Internet Explorer DOM Reference available at:
*
http://msdn.microsoft.com/workshop/a...ence_entry.asp
* Netscape 6/7 DOM Reference available at:
*
http://www.mozilla.org/docs/dom/domref/
* Tips for upgrading JavaScript for Netscape 7 / Mozilla
*
http://www.mozilla.org/docs/web-deve...upgrade_2.html 
