Re: WODisplayGroup, ERXWORepetition and object deletion
Re: WODisplayGroup, ERXWORepetition and object deletion
- Subject: Re: WODisplayGroup, ERXWORepetition and object deletion
- From: Paul Hoadley <email@hidden>
- Date: Fri, 04 Dec 2015 09:42:03 +1030
Hi Ted,
On 4 Dec 2015, at 3:39 am, Theodore Petrosky <email@hidden> 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.
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden