On Thu, 28 Aug 2008, Frank Niessink wrote: > 2008/8/28 Jerome Laheurte <[EMAIL PROTECTED]>: >> Mmmh. Seems too good to be true :) What about create task/create >> note/click OK in the task editor/delete the task (or undo twice)/click >> OK in the note editor ? Wouldn't there be an Edit command related to >> a note that doesn't exist (since the containing task was deleted) ? > > Yes, but that edit command is only created (when the note edit dialog > is opened), not 'done', so it isn't on the history yet. The do() is > executed when the user clicks OK and that is the moment that the > command is added to the history. Also, the note edit dialog would be > observing the tasklist so it can close itself as soon as the task (the > noteowner of the note) is removed from the tasklist.
Seems right. Still, I'm wondering how many strange scenarios are lurking behind the curtain. Guess we'll see. >> I think the hardest part is the categories stuff, because they're >> "common" to all objects. Much failure scenarios would simply go away >> if createColumnUICommands() in LocalCategoryViewer just returned []. > > Uhm? A category viewer has no columns at the moment, so I'm not > following you here. Sorry, I fumbled. I meant createToolBarUICommands() of course. (on a side note, the category viewer should have columns, since now categories may have attachments and notes, but we'll take care of this later) >> People could still create/edit categories from the main window since >> the dialogs wouldn't be modal. This solves half of the problems. > > But creating a category from a task edit dialog is no problem: > 1. User clicks new task button on toolbar: NewTaskCommand is created > and ok()'ed; task edit dialog is opened to allow editing of the task > 2. User clicks new category from category viewer in task editor, a > NewCategoryCommand is created and ok()'ed, category is added to the > main category list and the category viewer in the task editor shows > the new category because it is observing the main category list. > 3. clicks OK in category edit dialog after e.g. editing the category > subject; the EditCategoryCommand is ok()'ed. > 4. User clicks cancel in task editor; the EditTaskCommand is simply discarded > 5. User clicks undo and the last command on the history, in this case > the EditCategoryCommand, is undone. > 6. User clicks undo again, the NewCategoryCommand is undone > 7 etc. Right, I was too quick on this one. >> For the remaining ones, I don't think we can go without locking. > > I really don't see where we need locking, can you please give an > example where we need it? Well, if the edit dialog observes the model and closes itself when the item it's editing is erased, we don't. We'll also have to close any dialog editing an item belonging to the one being deleted (a note for an attachment for a note for a task etc...), not that simple to implement IMHO, though I didn't really think about it. >> Besides, this locking idea isn't new for me, it popped up when I >> thought about multi-user support (a long way to go), we'll need it >> then. > > Careful, don't forget YAGNI :-) Well, I think we're gonna need it, but not right now, there's a nuance :) I've been thinking about multi-user mode for quite some time, and I think it's feasible. Actually, the multiple editor dialogs looks much like a multiple users use case, except that all users are, well, the same one. Still, it raises some interesting problems that won't get in the way later if we fix them right now. I may not be able to work on TC this week-end since a friend of mine is throwing a party to celebrate his PACS, but I'll fix all this stuff ASAP. Preferably when my satursday's hangover is cured. Hangover code is the worst :) Cheers Jérôme
