2008/8/25 Jerome Laheurte <[EMAIL PROTECTED]>: > Let me rephrase that: allowing anything in the main window while > editing an object breaks undo/redo. Here is what I came up with so > far. > > * So, top-level dialogs should not be modal.
Right. > * "children" dialogs should be. I'd prefer them not to be, but can live with it if we can't find another way around this issue. > * In order to avoid the command history mixup when the user works with > 2 editor dialogs at once, the only sane thing I can think of is having > a command history for each top-level dialog. Commands done in this > context (and in children dialogs) are stored in the top-level dialog > history. If the user clicks cancel, all commands in this history are > undone; if he clicks OK, the history is converted to an > AggregateCommand and appended to the global history. Let's call this > the "what happens in Vegas stays in Vegas" strategy. LOL > * Users should not be able to delete/cut/etc an object being edited. > This is simple; put a 'locked' attribute on domain.base.Object and use > a NeedsUnlockedSelection mixin for 'critical' UICommands. > > * Objects may also be deleted by undoing their creation; so undo/redo > should be disabled when editing an object. > > This covers most problems but not all of them. For instance, consider > the following: create a category; create a task; in the task editor, > edit the category, modify it, click OK (in the category editor). Now > in the main window, delete the category (which isn't locked anymore). > Click OK in the task editor. > > What happens is that now the global command history contains a command > for the category deletion, and then an AggregateCommand that includes > a command for the category editing. I'm pretty sure clicking 'undo' in > this situation will raise an exception, trying to undo the edition of > a non-existent category... > > Still thinking... 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) Both would work. Here's the scenario you mention above: NewCategoryCommand (user clicks new category on the toolbar) EditCategoryCommand (user clicks ok in the category editor) NewTaskCommand (user clicks new task on the toolbar) EditCategoryCommand (user clicks edit category in the category viewer of the task editor, edits it and clicks ok) DeleteCategoryCommand (user deletes category in mainwindow; categoryviewer in the task editor is updated) EditTaskCommand (user clicks ok in the task editor dialog) That should work too. This way, all dialogs always edit objects that already exist. To deal with the situation where a user deletes an object that is opened in an edit dialog, the edit dialog needs to observe the domain model for deletions. That shouldn't be too hard to implement. In the case of notes that are not part of the global notes container, but only part of a noteowner, the dialog has to observe the noteowner for deletion too. I think this solves all problems we currently have. Moreover, it doesn't need layered command history, it doesn't need locking of objects and it doesn't need modal dialogs at all. Am I missing something? Cheers, Frank
