Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Event reminders #135

Closed
wants to merge 16 commits into from

Conversation

bangyiwu
Copy link
Collaborator

Allows setting reminders for events x days in advance

@bangyiwu bangyiwu added this to the v1.3 milestone Oct 20, 2020
@bangyiwu bangyiwu linked an issue Oct 21, 2020 that may be closed by this pull request
Copy link
Collaborator

@LinkedInk LinkedInk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please reconsider the command structure used to be more consistent and edit all copy pasting references that are incorrect. The rest seems ok.

import seedu.address.logic.commands.IntroCommand;
import seedu.address.logic.commands.ListContactCommand;
import seedu.address.logic.commands.ListEventCommand;
import seedu.address.logic.commands.*;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Mind the star import command causing checkstyle to fail.

Comment on lines 23 to 24
REMIND("remind"),
REMINDER("reminder"),
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confusing command names. Should change into a "add -r" and "show/list -r" style like how contacts and events are handled to keep consistency.

Comment on lines 22 to 24
* Parses the given {@code String} of arguments in the context of the AddContactCommand
* and returns an AddContactCommand object for execution.
* @throws ParseException if the user input does not conform the expected format
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AddContactCommand references should not be here. Please double check if copy pasting has left anything that is not relevant and needs to be changed.

@chan-j-d chan-j-d added enhancement New feature or request priority.High Features of high priority for development. labels Oct 27, 2020
Comment on lines 24 to 26
REMIND("remind"),
REMINDER("listr"),
SHOW_REMINDER("showr"),
Copy link
Collaborator

@LinkedInk LinkedInk Oct 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What I meant from a previous comment was to split it into command word and command type. Not to modify the command word.

So right now, contact commands have the command type "-c", event commands "-e", and tag commands "-t".

Reminder should have its own type, allowing for a reminder oriented set of commands. Reminder commands can have the command type "-r".

This means that things like the command word "add" can be reused (instead of "remind", and "list" instead of "listr"), combining it with the "-r" command type and it becomes "add -r" to signal an adding of a reminder command. This keeps the overall experiece relatively consistent with the rest of the commands as well.

Copy link
Collaborator

@LinkedInk LinkedInk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Command structure needs to be reconsidered, reminder commands should be grouped separtedly. Rest seems ok for now.

Comment on lines 127 to 132
case REMIND:
return new RemindEventCommandParser().parse(arguments);

case REMINDER:
return new ListReminderEventCommand();

Copy link
Collaborator

@LinkedInk LinkedInk Oct 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Theses cases are ambigously named (REMIND vs REMINDER) when they clearly mean different things. They are also separated from the show reminder command when they should be grouped under another command type for reminder. Should not belong to events.

Comment on lines 165 to 167
case SHOW_REMINDER:
return new ShowReminderEventCommand();

Copy link
Collaborator

@LinkedInk LinkedInk Oct 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is separated from the 2 other reminder commands when they should be grouped under a single command type for reminder. Should not belong to the default branch.

Comment on lines +19 to +21
private static String home = System.getProperty("user.dir");
private static Path savePath = Paths.get(home, "data", "reminders.txt");
private static ReminderStorage reminderStorage = new ReminderStorage(savePath);
Copy link
Collaborator

@LinkedInk LinkedInk Oct 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please use the UserPrefs class to get paths as standard. Helps when trying to create test classes as well, making it possible to mirror off other test classes that needs sample files (ie need to change directory/make a fake directory for testing).
image

Comment on lines +28 to +34
static {
try {
reminders = reminderStorage.load();
} catch (IOException e) {
e.printStackTrace();
}
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not quite sure what this is. A constructor?

import seedu.address.model.event.Reminder;
import seedu.address.model.event.Time;

public class ReminderStorage {
Copy link
Collaborator

@LinkedInk LinkedInk Oct 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This class should be part of StorageManager as per addressbook, calendar, userPrefs, tagtree. Initial read should be part of MainApp init() method as show below.
image
It would be preferable to implement it in a .json file as well for saving and reading so that its standard. However, this is not a big deal as compared to just being a part of StorageManager. A .txt save file is fine as well.

Comment on lines 220 to 235
/**
* Executes the command to show the introduction. As the introduction command should not be
* accessible by the user, a commandText should not exist for it and the entire execution
* should be handled in the back-end. Note that as this method cannot throw a CommandException
* or a ParseException, handling can be ignored. The lack of an access modifier is intentional
* - method is supposed to be package private.
*/

CommandResult executeShowReminderCommand() throws CommandException, ParseException {
CommandResult commandResult = logic.execute("showr");
logger.info("Result: " + commandResult.getFeedbackToUser());
resultPanel.setFeedbackToUser(commandResult.getFeedbackToUser());
handleReminders();
return commandResult;
}

Copy link
Collaborator

@LinkedInk LinkedInk Oct 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it can't throw, the method should not have a throws keyword. Any other method that uses this are forced to implement catching the exceptions or throwing them again. Which is not the same as "this method cannot throw a CommandException or a ParseException, handling can be ignored".

In the case where command word for show reminder is changed in the enum but not changed here, this method will throw a exception.

Do not follow executeIntroCommand() method above, its not a good implementation. Import enum CommandWord to avoid such incident. Implement catching and processing in case of an error, perhaps displaying an error message saying something like "reminders failed to show" in the resultPanel. Think defensive programming.

Copy link
Collaborator

@chan-j-d chan-j-d Oct 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it can't throw, the method should not have a throws keyword. Any other method that uses this are forced to implement catching the exceptions or throwing them again. Which is not the same as "this method cannot throw a CommandException or a ParseException, handling can be ignored".

you realise that any command that uses execute has to either catch and deal with a CommandException and ParseException or it has to throws it as well?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Also, it would be really helpful to say why something isn't a good implementation instead of brushing it aside as one.

Copy link

@fyshhh fyshhh Oct 29, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this information is outright incorrect. the fact that you've said something like this shows that you do not understand how the method works.

If it can't throw, the method should not have a throws keyword.

correct.

Which is not the same as "this method cannot throw a CommandException or a ParseException, handling can be ignored".

incorrect. because line 229 uses Logic.execute(), your method has to either implement a way to catch these exceptions by embedding it in a try-catch block, or simply put it in the signature. the problem with the former is that your catch block then cannot be empty, as if the exception is thrown by Logic.execute(), neither is a CommandResult returned nor an exception thrown. the reason you can put it in the signature is because, as the back-end programmer, you know that it will never throw this exception.

basically, the method can throw it but won't.

In the case where command word for show reminder is changed in the enum but not changed here, this method will throw a exception.

yes, but CommandException and ParseException are both for users. as the programmer, you are expected to make consistent changes across the codebase when one reference changes. to use either of those exceptions as a way to ascertain that is wrong.

Import enum CommandWord to avoid such incident. Implement catching and processing in case of an error, perhaps displaying an error message saying something like "reminders failed to show" in the resultPanel.

this is literally what line 231 does.

Do not follow executeIntroCommand() method above, its not a good implementation.

would you like to explain why? if you want to say this, at least have the courtesy to @ me. if you want to discuss the implementation i'm all ears, but i'd prefer that to you straight up, condescendingly and accusatively stating that "its [sic] not a good implementation".

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is continued in person.

Copy link
Collaborator

@LinkedInk LinkedInk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Accidental extra review, ignore this.

@bangyiwu bangyiwu closed this Oct 29, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request priority.High Features of high priority for development.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

As a user, I should be able to set and view reminders
4 participants