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. > 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. > 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. > 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? > 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 :-) Cheers, Frank
