On Thu, 28 Aug 2008, Frank Niessink wrote: > What would happen if we split the New<DomainObject>Command's in two > steps: creating a new domain object (with all default settings) and > then editing it? That way, if the user creates a new task and then > adds a note the command history would look like this (oldest first): > NewTaskCommand (because the user clicks new task on the toolbar) > NewNoteCommand (because the user clicks new note in the note viewer > toolbar of the task editor) > EditNoteCommand (because the user edits the note, e.g. the subject, > and clicks ok) > EditTaskCommand (because the user edits the task, e.g. the due date, > and clicks ok) > > If the user first clicks ok in the task editor, the history looks as follows: > NewTaskCommand (because the user clicks new task on the toolbar) > NewNoteCommand (because the user clicks new note in the note viewer > toolbar of the task editor) > EditTaskCommand (because the user edits the task, e.g. the due date, > and clicks ok) > EditNoteCommand (because the user edits the note, e.g. the subject, > and clicks ok)
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) ? 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 []. People could still create/edit categories from the main window since the dialogs wouldn't be modal. This solves half of the problems. For the remaining ones, I don't think we can go without locking. 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. I'll give it a try this week-end, on a separate branch so we can test it out. Cheers Jérôme
