-
Notifications
You must be signed in to change notification settings - Fork 5
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
Add Event reminders #135
Conversation
There was a problem hiding this 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.*; |
There was a problem hiding this comment.
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.
REMIND("remind"), | ||
REMINDER("reminder"), |
There was a problem hiding this comment.
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.
* 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 |
There was a problem hiding this comment.
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.
REMIND("remind"), | ||
REMINDER("listr"), | ||
SHOW_REMINDER("showr"), |
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
case REMIND: | ||
return new RemindEventCommandParser().parse(arguments); | ||
|
||
case REMINDER: | ||
return new ListReminderEventCommand(); | ||
|
There was a problem hiding this comment.
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.
case SHOW_REMINDER: | ||
return new ShowReminderEventCommand(); | ||
|
There was a problem hiding this comment.
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.
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); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
static { | ||
try { | ||
reminders = reminderStorage.load(); | ||
} catch (IOException e) { | ||
e.printStackTrace(); | ||
} | ||
} |
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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.
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.
/** | ||
* 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; | ||
} | ||
|
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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".
There was a problem hiding this comment.
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.
There was a problem hiding this 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.
Allows setting reminders for events x days in advance