Merge pull request #392 from tze088/dg-updates

Dg updates

Author: tze088

docs/DeveloperGuide.md

@@ -178,6 +178,22 @@ A `Group` has:
 
 and are stored in a single `UniqueGroupList` within an `AddressBook`.
 
+#### Group Methods and Responsibilities
+The `Group` class is responsible for managing its internal members and events, but it does not directly modify the global contact list or other global data. Instead, it ensures internal consistency within the group. Synchronisation with global data is handled by higher-level methods elsewhere in the application.
+
+##### Internal lists and modification
+The internal lists (persons and events) are not exposed except as read-only `ObservableList`s. The only way to modify the group’s state is through its methods such as: `addPerson`, `removePerson`, `addEvent`, and `removeEvent`.
+
+##### Factory and update methods
+* `Group.fromStorage`: A factory method used to create a new `Group` from input data (e.g., event list, person list, dashboard). This method is intended to be used only by specific methods and is not typically used for new groups, which should start with empty fields (except for the group name).
+
+* `Group#withUpdatedName`: Returns a new `Group` with copied internal data but a different name. This method is used in commands like edit-group.
+    * This approach ensures that changes are explicit, preventing unintended side effects and making state management more predictable.
+    * While containers like lists or dashboards are copied to avoid modifying the original state, immutable elements are reused to optimize memory.
+
+##### Why This Design?
+This approach ensures that the `Group` class focuses solely on managing its own data, while global data (like contacts) is updated through methods in the `Model` layer. It keeps the system modular and reduces the risk of unintended side effects.
+
 #### Key Components
 ##### Unique Lists
 The implementation of `UniqueGroupList` and `UniqueEventList` follow the `UniquePersonList` pattern - that is, they are wrappers on an `ObservableList` which prevent the addition of duplicate entries.
@@ -201,7 +217,7 @@ To maintain the integrity of the application, the following invariants must be r
     * Use Existing High-Level Methods (e.g., `Model#setPerson`): To modify a person’s details, always use the existing method `Model#setPerson`. This method ensures updates are properly synchronised across the model. Avoid manually calling lower-level methods like `UniquePersonList#setPerson`.
     * Note: setPerson is a well-implemented method and serves as a good example for handling updates. While the codebase isn't fully consistent, use similar methods for other objects when available, or manually ensure synchronisation when necessary.
 
-The immutability of Persons and Events allows for future implementation of features such as:
+The immutability of Persons and Events simplifies the future implementation of features such as:
 
 * **State Saving:** Enabling features like undo/redo.
 
@@ -304,6 +320,25 @@ The following activity diagram summarizes what happens when a user executes a ne
 ## **Planned Enhancements**
 Team size: 5
 
+1. **Improve text wrapping behaviour in dashboard:**
+    The current dashboard GUI element does not properly wrap text for long member or event entries.
+    As a result, users must manually scroll horizontally to see the entire entry.
+    We plan to implement automatic text wrapping to improve the readability of these entries, ensuring that all content is visible without the need for horizontal scrolling.
+2. **Fix vertical scrolling issue in Event list GUI (Group card):**
+    Currently, the Event list GUI sub-element in the Group card doesn’t handle long event strings properly.
+    When the event string is too long, text wrapping causes the list to scroll vertically, instead of expanding as expected.
+    We plan to fix this by ensuring the event list expands horizontally to accommodate long text without forcing vertical scrolling.
+3. **Clarify event index error message:**
+    Currently, for commands using the event-index prefix, the error message does not specify if the event index is incorrect.
+    Instead, it generically states: "Index is not a non-zero unsigned integer." This could be confusing, especially when the command also uses a group index, as users wouldn’t know which index is causing the error.
+    We’ll update it to "Event index is not a non-zero unsigned integer" to clearly specify which index is invalid when both event and group indexes are used.
+4. **Improve error message for index parsing in command preamble (Contact command):**
+    Currently, index parsing errors in the command preamble (for contact-related commands) result in a generic command usage message.
+    We will update this behavior to specify that the contact index is invalid (if non-empty) with the message "Contact index is not a non-zero unsigned integer", making the error message more informative.
+5. **Improve error message for index parsing in command preamble (Group command):**
+    Currently, index parsing errors in the command preamble (for group-related commands) result in a generic command usage message.
+    We will update this behavior to specify that the group index is invalid (if non-empty) with the message "Group index is not a non-zero unsigned integer", making the error message more informative.
+    
 
 --------------------------------------------------------------------------------------------------------------------
 

src/main/java/seedu/address/model/event/UniqueEventList.java

@@ -60,6 +60,11 @@ public void setEvent(Event target, Event edited) {
         internalList.set(index, edited);
     }
 
+    public void setEvents(UniqueEventList replacement) {
+        requireNonNull(replacement);
+        internalList.setAll(replacement.internalList);
+    }
+
     /**
      * Removes an {@code Event} from the list.
      * The {@code Event} must already exist in the list.

src/main/java/seedu/address/model/group/Group.java

@@ -80,7 +80,14 @@ public static Group fromStorage(GroupName name, UniqueEventList events, UniquePe
     public Group withUpdatedName(GroupName newName) {
         requireNonNull(newName);
 
-        return new Group(newName, events, persons, repoLink, dashboard);
+        UniqueEventList newEvents = new UniqueEventList();
+        newEvents.setEvents(this.events);
+        UniquePersonList newPersons = new UniquePersonList();
+        newPersons.setPersons(this.persons);
+
+        Group newGroup = new Group(newName, newEvents, newPersons, repoLink);
+        newGroup.setDashboard(dashboard.getNotes());
+        return newGroup;
     }
 
     public GroupName getName() {