Alicia Ho Sor Sian - Project Portfolio

CalendarEntry represents an entry created by users.

A CalendarEntry is implemented in the following manner:

The following is a brief description of the attributes of CalendarEntry:

Entry management is facilitated by CalendarManager residing in ModelManager. It supports the adding, removing and editing of CalendarEntry(e.g. addCalendarEntry, deleteCalendarEntry) and maintains a UniqueCalendarEntryList to store CalendarEntry.

The following diagram shows class diagram of Model Component related to CalendarEntry.

In the Figure 34, ModelManager contains an instance of CalendarManager. ModelManager calls the functions in CalendarManager to manage CalendarEntries stored in it. CalendarManager in turn calls methods in UniqueCalendarEntryList to add, remove or edit CalendarEntries stored in it. CalendarManager contains an instance of Calendar belonging to CalendarFX’s library. Calendar stores Entry, as defined in CalendarFX’s library. CalendarEntry is converted to Entry before they can be added to Calendar via CalendarEntryConversionUtil in the Commons class.

Logic Component contains the commands required to manage user’s entries, which are AddEntryCommand, DeleteEntryCommand and EditEntryCommand. These commands inherit from UndoableCommand and are thus can be undone via the UndoCommand.

The sequence diagram below shows how adding an entry works:

In Figure 35, when a user enters the command to add an entry, AddEntryCommandParser is invoked which creates a CalendarEntry based on user input. The parser then creates AddEntryCommand passing the CalendarEntry to it. When AddEntryCommand is executed, CalendarEntry is passed from AddEntryCommand to ModelManager and to CalendarManager, which adds it to UniqueCalendarEntryList. The CalendarEntry is then converted to Entry to be added to Calendar (not shown in diagram) and control is eventually returned to the user.

Storing of CalendarEntry data is managed by CalendarManagerStorage within Storage Component. CalendarEntry is converted to XmlAdaptedCalendarEntry, which can be stored in XmlSerializableCalendarManager. XmlSerializableCalendarManager is stored in a .xml file using XmlFileStorage.

CalendarView within CalendarFX’s library uses the Calendar within CalendarManager in Model to display all entries stored within Calendar. CalendarPanel residing in Ui component creates an instance of CalendarView to manage the display of the calendar.

The following code snippet shows how CalendarPanel is initialised.

When CalendarPanel is initialised, CalendarFxUtil returns an instance of CalendarView that is modified to remove unused features within CalendarView, such as the ability to print the calendar. CalendarSource is required to store the Calendar from Model and CalendarView in turn stores CalendarSource before it can display contents of Calendar.
The setting up of CalendarSource and CalendarView is done by initialiseCalendar(calendar). createTimeThread() creates a Thread that updates the timeProperty() in CalendarView every 10 seconds, ensuring that the current time displayed within the calendar interface matches the actual time the user is using the application.

Any changes made to Calendar in Model will automatically be shown via the CalendarView as Calendar is a class-level member in CalendarManager that is passed to CalendarPanel. updateCalendar() in CalendarManager clears all entries within Calendar and adds CalendarEntries converted to Entries to Calendar.

As the placement of CalendarPanel coincides with that of PersonPanel at the center of the GUI interface of ContactSails, CenterPanel is used in place to switch between displaying contents of the two panels.

The following code snippet shows how CenterPanel is initialised.

CenterPanel contains one instance of CalendarPanel and PersonPanel. PersonPanel is displayed upon initialising CenterPanel by calling displayPersonPanel(). displayPersonPanel() is also called when BaseEvents related to PersonPanel is received by CenterPanel.

The following code snippet below shows how CenterPanel displays PersonPanel.

Based on the snippet, CenterPanel checks whether centerPlaceholder contains root node of PersonPanel. If it does not, centerPlaceholder` will clear any existing child nodes and add root node of PersonPanel, which causes PersonPanel to be displayed.

CenterPanel displays CalendarPanel with displayCalendarPanel(), which is written similar to displayPersonPanel().

CenterPanel subscribes to BaseEvents related to the CalendarPanel and PersonPanel, such as ChangeCalendarPageRequestEvent and PersonPanelSelectionChangedEvent. Thus, BaseEvents received by CenterPanel can be split into two categories, one meant for CalendarPanel, and the other for PersonPanel. The following sequence diagram below shows how ChangeCalendarPageRequestEvent is handled by CenterPanel.

In Figure 36, ViewTodayCommand posts a new ChangeCalendarPageRequestEvent to the EventsCenter. CenterPanel handles the event by calling handleChangeCalendarPageRequestEvent() in CalendarPanel before calling displayCalendarPanel(). In CalendarPanel, getRequestType() is called on the event to check the page that is requested. Given that REQUEST_TODAY is the requestType of the event, CalendarView will switch the displayed page to today. The calendar will be displayed at CenterPanel as control is eventually returned to the user.