Hi
> Is it the programmers responsibility to react? E.g. sending a page to the
> WOUser telling: Sorry. The request could not be performed. Data has changed
> meanwhile. It looks like that now: (showing fresh data). Try again?
> (Button, that displays the submit page again with the former WOUser data
> reentered).
Well if you want. Maybe its OK by you for a users updates to succeed
even IF the state changed underneath. If that's the case, then remove
the lock icons from the attributes in the associated entity. (Take a
look at the SQL EOF gens with and w/o these locks.) I'll bet in most
cases this IS what developers want (or think they want) since it is the
mode of updating one is used to.
If you want to *disallow* updates when state changes under you, then
leave those lock icons on and catch the exception that will get thrown
(you can catch exceptions even in WebScript BTW). Your handling might
refresh the object with the latest values from the DB and/or apply the
changes to that object the given user made and then return the page with
message like ("Jane Doe's firstName and gender changed; try updating
again" ).
d
