Hi Ted, On 4 Dec 2015, at 3:39 am, Theodore Petrosky <tedp...@yahoo.com> wrote:
>>> Would it be better to not delete the Job, but instead mark it >>> isDeleted=true. then you have the best of both worlds? >> >> Say that we did that. >> >>> You could also ask the system, Show me all the deleted Jobs. >> >> Then say that we did that—one display group for active Jobs, another for >> deleted Jobs. Now what we’ve got is a minimal variation on what I described: >> >>>> Is that the best I can do? In this slightly abridged scenario, the Job got >>>> deleted, and that was the only action available, so the informational >>>> message can say “The selected Job was already deleted”. But all I really >>>> know is that the Job is no longer where it once was in >>>> displayedObjects()—right? Say it just got moved by that action method >>>> above— >> >> Say, indeed, that user A caused J1.isDeleted to now be true. Assume that the >> display group of interest shows non-deleted Jobs (for which isDeleted() >> returns false), and B still sees J1 on it. We’re back to square one, because >> J1 has still been _moved out of_ that display group (because it no longer >> matches the qualifier on isDeleted). At this point, we’re back at the >> original question: > > User A caused J1 (PK=7654) to update isDeleted=true. J1 isn’t moved out of > the displayGroup. You’re changing the constraints I’ve set up. The situation is contrived so that we can talk about some behaviour of ERXWORepetition that really does occur. So J1 _is_ moved out of the display group, because in the situation I’m describing there’s a qualifier on it that excludes Jobs where isDeleted == true. > If you click the edit button, you can still ‘edit’ the job, but maybe you set > a message to say, “Sorry, this job has been marked completed so you can not > edit it unless you reopen it!” Let’s keep it really simple—there is no edit button. Just a delete button. And it doesn’t actually matter whether it deletes the object or sets isDeleted to true—the whole point of this is just that some action of user A causes the data backing what user B sees (that is, the repetition’s list—displayedObjects()) to go stale behind B’s back. > It shouldn’t matter if User B is looking at a displayGroup that is sorted > differently (stale data) and has this object. The object still exists. When I > click the delete button, the method that is fired sees that isDeleted=true on > the object. It really does matter, and it’s the whole point behind ERXWORepetition’s checkHashCodes feature—the action method doesn’t see _anything_ on the selected object because _it can’t find the selected object_. That’s the point. -- Paul Hoadley http://logicsquad.net/
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
