Remove proposed features and planned enhancement #6

Planned enhancement #6: Disable the refreshing of the list after all commands except list.
AY2324S1-CS2103T-F12-1 · Nov 12, 2023 · 28edba2 · 28edba2
1 parent 538336d
commit 28edba2
Show file tree

Hide file tree

Showing 16 changed files with 2 additions and 297 deletions.
diff --git a/docs/DeveloperGuide.md b/docs/DeveloperGuide.md
@@ -467,114 +467,6 @@ The `setAppointmentList()` method checks against `filteredPersons` to look for u
     * Cons: `filteredPersons` and `sortedAppointments` might not correspond since `sortedAppointments` is no longer
     dependent on `filteredPersons`.
 
-### \[Proposed\] Undo/redo feature
-
-### \[Proposed\] Undo/redo feature
-#### Proposed Implementation
-
-The proposed undo/redo mechanism is facilitated by `VersionedAddressBook`. It extends `AddressBook` with an undo/redo
-history, stored internally as an `addressBookStateList` and `currentStatePointer`. Additionally, it implements the
-following operations:
-
-* `VersionedAddressBook#commit()` — Saves the current address book state in its history.
-* `VersionedAddressBook#undo()` — Restores the previous address book state from its history.
-* `VersionedAddressBook#redo()` — Restores a previously undone address book state from its history.
-
-These operations are exposed in the `Model` interface as `Model#commitAddressBook()`, `Model#undoAddressBook()` and
-`Model#redoAddressBook()` respectively.
-
-Given below is an example usage scenario and how the undo/redo mechanism behaves at each step.
-
-Step 1. The user launches the application for the first time. The `VersionedAddressBook` will be initialized with the
-initial address book state, and the `currentStatePointer` pointing to that single address book state.
-
-![UndoRedoState0](images/UndoRedoState0.png)
-
-Step 2. The user executes `delete 5` command to delete the 5th person in the address book. The `delete` command calls
-`Model#commitAddressBook()`, causing the modified state of the address book after the `delete 5` command executes to be
-saved in the `addressBookStateList`, and the `currentStatePointer` is shifted to the newly inserted address book state.
-
-![UndoRedoState1](images/UndoRedoState1.png)
-
-Step 3. The user executes `add n/David …` to add a new person. The `add` command also calls
-`Model#commitAddressBook()`, causing another modified address book state to be saved into the `addressBookStateList`.
-
-![UndoRedoState2](images/UndoRedoState2.png)
-
-<div markdown="span" class="alert alert-info">:information_source: **Note:** If a command fails its execution, it
-will not call `Model#commitAddressBook()`, so the address book state will not be saved into the `addressBookStateList`.
-
-</div>
-
-Step 4. The user now decides that adding the person was a mistake, and decides to undo that action by executing the
-`undo` command. The `undo` command will call `Model#undoAddressBook()`, which will shift the `currentStatePointer` once
-to the left, pointing it to the previous address book state, and restores the address book to that state.
-
-![UndoRedoState3](images/UndoRedoState3.png)
-
-<div markdown="span" class="alert alert-info">:information_source: **Note:** If the `currentStatePointer` is at index
-0, pointing to the initial AddressBook state, then there are no previous AddressBook states to restore. The `undo`
-command uses `Model#canUndoAddressBook()` to check if this is the case. If so, it will return an error to the user
-rather than attempting to perform the undo.
-
-</div>
-
-The following sequence diagram shows how the undo operation works:
-
-![UndoSequenceDiagram](images/UndoSequenceDiagram.png)
-
-<div markdown="span" class="alert alert-info">:information_source: **Note:** The lifeline for `UndoCommand` should end
-at the destroy marker (X) but due to a limitation of PlantUML, the lifeline reaches the end of diagram.
-
-</div>
-
-The `redo` command does the opposite — it calls `Model#redoAddressBook()`, which shifts the `currentStatePointer`
-once to the right, pointing to the previously undone state, and restores the address book to that state.
-
-<div markdown="span" class="alert alert-info">:information_source: **Note:** If the `currentStatePointer` is at index
-`addressBookStateList.size() - 1`, pointing to the latest address book state, then there are no undone AddressBook
-states to restore. The `redo` command uses `Model#canRedoAddressBook()` to check if this is the case. If so, it will
-return an error to the user rather than attempting to perform the redo.
-
-</div>
-
-Step 5. The user then decides to execute the command `list`. Commands that do not modify the address book, such as
-`list`, will usually not call `Model#commitAddressBook()`, `Model#undoAddressBook()` or `Model#redoAddressBook()`.
-Thus, the `addressBookStateList` remains unchanged.
-
-![UndoRedoState4](images/UndoRedoState4.png)
-
-Step 6. The user executes `clear`, which calls `Model#commitAddressBook()`. Since the `currentStatePointer` is not
-pointing at the end of the `addressBookStateList`, all address book states after the `currentStatePointer` will be
-purged. Reason: It no longer makes sense to redo the `add n/David …` command. This is the behavior that most modern
-desktop applications follow.
-
-![UndoRedoState5](images/UndoRedoState5.png)
-
-The following activity diagram summarizes what happens when a user executes a new command:
-
-<img src="images/CommitActivityDiagram.png" width="400" />
-
-#### Design considerations:
-
-**Aspect: How undo & redo executes:**
-
-* **Alternative 1 (current choice):** Saves the entire address book.
-  * Pros: Easy to implement.
-  * Cons: May have performance issues in terms of memory usage.
-
-* **Alternative 2:** Individual command knows how to undo/redo by
-  itself.
-  * Pros: Will use less memory (e.g. for `delete`, just save the person being deleted).
-  * Cons: We must ensure that the implementation of each individual command are correct.
-
-_{more aspects and alternatives to be added}_
-
-### \[Proposed\] Data archiving
-
-_{Explain here how the data archiving feature will be implemented}_
-
-
 --------------------------------------------------------------------------------------------------------------------
 
 ## **Documentation, logging, testing, configuration, dev-ops**
@@ -864,16 +756,12 @@ validity checker for both fields.
 at once. To allow the gathering of all the persons emails using `gather all` command, we plan create another
 `GatherEmailPrompt` class, with a method that will call the Person `getEmail()` method. To allow gathering emails by multiple fields, for example using the `fp/` and `t/` prefixes at once, we plan to use a similar approach
 to `find` but return the person's email instead.
-6. The `complete`, `add`, `edit` and `schedule` commands currently display the whole list (i.e. undoes the result of
-any `find` command) after being executed, which might cause users to become disoriented. We plan to disable this
-interaction between these commands and `find`.
-7. The `clear` command confirmation window can be manipulated using the arrow and 'Enter' keys. The window is
+6. The `clear` command confirmation window can be manipulated using the arrow and 'Enter' keys. The window is
 initialised with the focus on the `confirm` button. This makes it possible for a user to accidentally press 'Enter'
 twice and wipe the contact book anyway, bypassing the defence mechanism entirely. We plan to make the command more
 resistant to mistakes by having the user key in a specific phrase, or to initialise the window with the focus on the
 `cancel` button instead.
 
-*{More to be added}*
 
 ### Glossary
 

diff --git a/docs/diagrams/UndoRedoState0.puml b/docs/diagrams/UndoRedoState0.puml
diff --git a/docs/diagrams/UndoRedoState1.puml b/docs/diagrams/UndoRedoState1.puml
diff --git a/docs/diagrams/UndoRedoState2.puml b/docs/diagrams/UndoRedoState2.puml
diff --git a/docs/diagrams/UndoRedoState3.puml b/docs/diagrams/UndoRedoState3.puml
diff --git a/docs/diagrams/UndoRedoState4.puml b/docs/diagrams/UndoRedoState4.puml
diff --git a/docs/diagrams/UndoRedoState5.puml b/docs/diagrams/UndoRedoState5.puml
diff --git a/docs/diagrams/UndoSequenceDiagram.puml b/docs/diagrams/UndoSequenceDiagram.puml
diff --git a/docs/images/UndoRedoState0.png b/docs/images/UndoRedoState0.png
diff --git a/docs/images/UndoRedoState1.png b/docs/images/UndoRedoState1.png
diff --git a/docs/images/UndoRedoState2.png b/docs/images/UndoRedoState2.png
diff --git a/docs/images/UndoRedoState3.png b/docs/images/UndoRedoState3.png
diff --git a/docs/images/UndoRedoState4.png b/docs/images/UndoRedoState4.png
diff --git a/docs/images/UndoRedoState5.png b/docs/images/UndoRedoState5.png
diff --git a/docs/images/UndoSequenceDiagram.png b/docs/images/UndoSequenceDiagram.png
diff --git a/docs/team/sopa301.md b/docs/team/sopa301.md
@@ -40,7 +40,7 @@ Given below are my contributions to the project.
   * Updated references to code files in the `Design` section.
   * Added implementation details for enhanced `find` command.
   * Drafted Planned Enhancements section.
-  * Contributed to `Instructions for Manual Testing` in DG.
+  * Contributed to `Instructions for manual testing` in DG.
 
 * **Contributions to team-based tasks**:
   * Maintained issue tracker.