# Save The Date

This codebase is designed to take in an XML file and turn it into a Planner System. The XML Editor

reads the xml, parses it, and transforms it into a Central Planner, uploading all the users with

their updated schedules. The schedule is designed to be exactly 1 week long, and each day is 24

hours long.

## Quick Start

No GUI so cannot be used yet. However, there is a main class. The main class can be run to check

the writing of a new XML file. With how it is currently set up, it will create a new XML called

Dave-Schedule.xml. This contains the contents of Dave's schedule written in XML.

## Model Part 1 Main Components

- A Central Planner (the "model") is used to model the Schedules of every User. A Central Planner

keeps track of each User that has a schedule currently in the Central Planner. It is helpful to

think of the Central Planner as an overlay of each user's individual schedule.

- A User (also referred to as a Client) is used to model each individual User.

Each User keeps track of its own Schedule.

- A NUPlanner (Also referred as a Schedule or Planner) is used to keep track of the Events in one

user's particular Schedule.

- An Event keeps track of all necessary information to create an Event. Every User in the list of

invitees has the Event in their Schedule.

- The PlannerView currently takes its list of user's, each with their own schedule, and prints

each user's schedule for the current week one after another in String format.

## Reading the XML

- The XML is read from an XML Editor class. This XML Editor keeps track of a list of Users, each

User updated to reflect its correct schedule. These Users are then relayed to the Central Planner

to be used.

- The XML Editor goes through each node and gathers the necessary information for a NUPlanner to be

assigned to a User.

- From there, it adds the User to the XML Editor's list of Users (clients field) if the user's name

(uid) is not already included. If it is, it adds the Event instead.

## Key subcomponents

- The Time represents a single instance of time, it includes hours, minutes, and a day of the week.

- The Day is an enum that has 14 values, every day of this week and every day of next week. This

allows us to book events on the next week while not taking up space in the current week that will

be read by the gui in the future.

## Invariants

- The hours of the time must be between 0-23. The minutes of the time must be between 0 and 59.

The day of a time must be a normal day of the week. It is not possible to initialize an Event with

the start day in the second week.

# Changes for Part 2

- From the initial design, the interface PlannerModel was refactored to extend an interface

ReadOnlyPlannerModel. This interface helps to keep separate the methods that do and don't mutate

the model. This way, when implementing the view without the controller, no method that may

accidentally cause a mutation is available to the view.

- We also fixed the createEvent method. In our last submission, a few tests did not pass because

of a bug with createEvent and hasTimeOverlap. This bug has been fixed and all tests now pass for

the model.

## View Main Components

- A ScheduleFrame: We created a large frame and added a Schedule panel to it. The frame takes in

a ReadOnlyPlannerModel.

- A SchedulePanel: We created a panel for the frame that has a File Menu at the top, a buttonPanel

at the bottom, and a grid with columns representing the Day of the week and rows representing the

hours.

- An EventFrame: We create a frame to add an Event panel to. This frame is shown when a user

attempts to modify the events in their schedule in some way. Specifically, the frame is shown

when the red of the calendar is clicked or when "create event" button is pressed.

- An EventPanel: We created a panel to place on the EventFrame. This panel is autofilled when the

red of the calendar is pressed, and not filled in when the "create event" button is pressed.

- It has three buttons that at the moment all do the same thing, first, they check that every

field of the event Panel is filled in, if not it will give an error message, then if every

field is filled in, it will print a message of the action and the event details.

## View Functionality

- File: Top of the Schedule Panel, Menu that has two items, Add Calendar and Save Calendar.

- Add Calendar: The add calendar button opens a file chooser that allows the user to click

only XMLs to add, or a directory to navigate to in order to find the XML. Once an XML is selected,

the file path prints.

- Save Calendar: The save calendar button opens a file chooser that allows the user to click

only directories to save the calendars to. Once the directory is selected, the file path prints

- ComboBox: Bottom of Schedule Panel, combobox that has the names of all the clients. Starts with

<none> until calendars are added

- Create event button: Bottom of Schedule Panel, allows user to input all the details of the new

event, the creator is whomever's schedule the panel is currently opened to.

- Schedule event button: Bottom of Schedule Panel, does the same thing as create event button.

# Changes for Part 3

- A major change that was implemented for part 3 was the structure of the Planner Model and the

read only model (ReadOnlyPlannerModel). The RO model now takes in a planner model and uses

composition to keep track of any updates to the PlannerModel. Before, inheritance was used,

however, with the design of our controller, it worked more smoothly to use composition.

- There is a small bug in creating an event if the planner begins empty, and the XML is read in.

In order for the planner to recognize that a user has been selected, the Combo Box of all the

users needs to be clicked, and a user (regardless of if it is the current user) needs to be

initially selected. Once this is done, all functionality works as normal.

## New view functionality

- SchedEventPanel: The SchedEventPanel consists of the contents of the panel, and the action

listeners for creating an event. This panel links to the controller, where the controller

can implement the strategy and update the view.

- SchedEventFrame: The SchedEventFrame is now the frame that appears when the "Schedule Event"

button is clicked. This frame consists of the panel with the functionality, linked to the

controller, to implement the strategies.

## Strategy functionality

- Strategy classes: Takes in: String eventName, User host, Location loc, String duration, and

ArrayList<User> invitees. Everything that the SchedEventPanel takes in gets sent to the strategy

classes.

AnyTime strategy: has a for loop for each minute that an event could possibly start

at. then it adds the duration to whatever startTime the for loop is currently at to make the

endTime. Then it creates the event and checks whether there is a time overlap with any of the

invitees. If there is a time overlap then goes through the for loop again until it creates an event

that every invitee can attend. THen it calls the controller's createEvent method.

WorkHours strategy: Takes in the same as AnyTime strategy. Creates the inital event the same as

AnyTime strategy but makes the startTime and endTime is between 0900 - 1700 on Monday-Friday and

that an event cannot span multiple days.

Lenient strategy: starts the same as WorkHours strategy but it creates an event based during work

hours based on whether the host and one other invitee can attend.

## Controller functionality

- The controller is structured to take in a view (ScheduleFrame). When a button is pressed from the

view, the action is sent to the controller to use the model to update the data. Because of the

composition used with the ROModel, the ROModel is immediately updated with the changes, in turn,

updating the view.

# Changes for Part 4

## changes for the customer

- We originally implemented Event, Location, NUPlanner, Time, and User interfaces to make sure that

our customers had access to any returns of those types that they needed. However, after restructuring

our code from our view to make sure the controller constructed any necessary classes for our model

instead of our view, the only necessary interfaces for our customers was the IUser interface. We

made the decision to keep the rest of the interfaces since it created more structured code for

those classes to have interfaces describing their functionality.

- These changes to have the controller initialize the model classes instead of the view, and the

addition of the extra interfaces, ended up making small changes in the return statements for

almost everything to return an instance of the interface instead of the class.

## adaptors

- In addition to these changes, to accommodate for our provider's code, we created 5 different

adaptors: FeatureAdaptor, ProvidedViewAdaptor, ProvidedModelAdaptor, EventAdaptor, and

ScheduleAdaptor. These adaptors allowed us to adapt our code to interact with the provider's

controller, view, model, event interface, and schedule interface.