I have used identifiers + timestamps (the timestamp can be just a random String) with my form tokens, so that I know if a submitted form is the one I expect, not only in terms of chronological ordering, but with respect to *the relevent actor*. If a user "checks out" a FooEdit form, then a BarEdit form, then submits the BarEdit Form, then tries to submit the FooEdit form, he will violate what the simplest of token-checking schemes would allow (the FooEdit token in the user's session would have been replaced by the BarEdit token at form checkout time). But obviously, he has followed proper workflow when you consider that two different *actors* were involved.
I don't know if Struts has any support for "complex" form timestamps, or in other words, multiple form tokens as simultaneous session attributes.
Hope that helps.
Erik
Varley, Roger wrote:
Hi
I'm trying to write what is esentially a web based data entry program using struts. I obviously can't use pessimistic database locking and optimistic locking becomes a nightmare when the client is able to open multiple edit windows across multiple records at the same time - so I'd like to simplify by treating the "edit" jsp as a modal dialog (i.e once the edit jsp is in use the client can't do anything else in the application until the "edit" is closed. Code samples or pointers to same would be useful. If trying to force a modal dialog is a really bad idea I would welcome suggestions on how to handle this scenario.
Regards Roger
__________________________________________________________________________
This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it.
As its integrity cannot be secured on the Internet, the Atos Origin group liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted.
__________________________________________________________________________
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
