-
Notifications
You must be signed in to change notification settings - Fork 1.7k
Ui: Make the ResultDisplay red on command failure #799
Conversation
v1@yamgent submitted v1 for review.
Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level4.git refs/pr/799/1/head:BRANCHNAME where |
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.
[1/3]: communicates -> passes. That's the term we usually use right? XD
* - the text remains <br> | ||
* - the command box's style is the same as {@code errorStyleOfCommandBox}. | ||
*/ | ||
private void assertBehaviorForFailedCommand() { | ||
eventsCollectorRule.eventsCollector.reset(); |
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.
maybe we should clear after the verifications requiring eventsCollectorRule#eventsCollector
have completed i.e. at line 150, for the purpose of segmenting eventsCollector
related things together.
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.
[2/3] 1st para: executed by the user succeeded or failed.
3rd para: Let's modify ResultDisplay to display the message in red when the
command execution fails. The message will still display white when (since you've already mentioned that we are only modifying
the command execution succeeds.ResultDisplay
to turn red when it fails, so it's clear that we aren't modifying the success case)
Platform.runLater(() -> { | ||
displayed.setValue(event.message); | ||
|
||
if (event.isSuccessful) { |
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.
can we ternary this? :P
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.
Ternary operators are only meant for assigning values though.
/** | ||
* Sets the {@code ResultDisplay} style to use the default style. | ||
*/ | ||
private void setStyleToDefault() { |
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.
since we have setStyleToIndicateCommandFailure
, it seems that this method should be named setStyleToIndicateCommandSuccess
?
@@ -19,4 +20,11 @@ public ResultDisplayHandle(TextArea resultDisplayNode) { | |||
public String getText() { | |||
return getRootNode().getText(); | |||
} | |||
|
|||
/** | |||
* Returns the list of style classes present in the command box. |
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 box result display :P
/** | ||
* Returns the list of style classes present in the command box. | ||
*/ | ||
public ObservableList<String> getStyleClass() { |
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.
I guess we can return this simply as a List<String>
, instead of an Observable<List>
, since we aren't observing it.
new NewResultAvailableEvent("failure", false); | ||
|
||
private ArrayList<String> defaultStyleOfResultDisplay; | ||
private ArrayList<String> errorStyleOfResultDisplay; |
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.
can these 2 simply be List<String>
?
|
||
/** | ||
* Posts the {@code event} to the {@code EventsCenter}, then verifies that <br> | ||
* - the text matches the event message <br> |
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.
the text on the result display matches the {@code event}'s message
/** | ||
* Posts the {@code event} to the {@code EventsCenter}, then verifies that <br> | ||
* - the text matches the event message <br> | ||
* - the result display's style is the same as {@code defaultStyleOfResultDisplay} for successful message, |
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.
for successful message
sounds weird :P
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.
[3/3] Should there be a commit message for this? :P
private static final List<String> RESULT_DISPLAY_DEFAULT_STYLE = | ||
Arrays.asList("text-input", "text-area", "result-display"); | ||
private static final List<String> RESULT_DISPLAY_ERROR_STYLE = | ||
Arrays.asList("text-input", "text-area", "result-display", ResultDisplay.ERROR_STYLE_CLASS); |
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.
I realise that we have inconsistencies in our code base; for ResultDisplayTest
, we use private ArrayList<String> defaultStyleOfResultDisplay
and then we call defaultStyleOfResultDisplay = new ArrayList<>(resultDisplayHandle.getStyleClass())
to add the style classes. :P
0357510
to
825f2ce
Compare
v2@yamgent submitted v2 for review.
(📚 Archive) (📈 Interdiff between v1 and v2) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level4.git refs/pr/799/2/head:BRANCHNAME where |
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.
[1/3]: The commit message mentions about ResultDisplay
, but there's no changes made in the code concerning ResultDisplay
:P Perhaps:
1st para: NewResultAvailableEvent only stores the message of the command execution. It does not store the success status.
2nd para: This is bad cos event subscribers like ResultDisplay may require this information (can phrase better)
3rd para: As part of teaching ResultDisplay to use the success status to update the display accordingly, let's modify NewResultAvailableEvent to store the success status.
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.
[3/3] there should be a 2nd para mentioning that this isn't current being tested :P
Just a general comment: after adding tests, this PR is a lot more complicated than before although it is a small UI change. This might overwhelm students. Is it possible to split into even smaller commits so that students can learn one commit at a time. e.g., add functionality first and then add the tests ? |
825f2ce
to
9b4657a
Compare
v3@yamgent submitted v3 for review.
(📚 Archive) (📈 Interdiff between v2 and v3) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level4.git refs/pr/799/3/head:BRANCHNAME where |
I split up the commits, so now the unit tests are in [v3 2/5] and [v3 4/5] instead. |
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.
Looks good now. On a related note, in the dev guide we can order the suggested UI-component improvements in the order of difficulty so that this one (which seems to be the most difficult one) comes last and also leave a comment there to recommend the reader to learn one commit at a time.
NewResultAvailableEvent only stores the message of the command execution. It does not store the success status. Subscribers such as ResultDisplay requires the success status to work. As part of teaching ResultDisplay to update the display according to the success status, let's modify NewResultAvailableEvent to store the success status.
CommandBox stores the success status of command execution in NewResultAvailableEvent. This behavior is not verified by any of the unit tests for CommandBox. Let's update the unit tests in CommandBoxTest to verify that behavior.
The ResultDisplay shows the same color (white) regardless of whether the command executed by the user succeeded or failed. Changing the color of the message when the command execution failed gives a clear visual signal to the user that he made a mistake, and that the message shown is an error, rather than a normal message. Let's modify ResultDisplay to display the message in red when the command execution fails.
ResultDisplay will turn red when command execution fails. This behavior is not verified by any of the unit tests for ResultDisplay. Let's update the unit tests in ResultDisplayTest to verify that behavior.
9b4657a
to
d5dd735
Compare
The ResultDisplay style changes if there is an error in command execution. This behavior is not verified by any system tests. Let's update the system tests to verify that.
d5dd735
to
fc363ad
Compare
v4@yamgent submitted v4 for review.
(📚 Archive) (📈 Interdiff between v3 and v4) (📈 Range-Diff between v3 and v4) Checkout this PR version locallygit fetch https://github.com/se-edu/addressbook-level4.git refs/pr/799/4/head:BRANCHNAME where |
Changelog:
|
Part of #784. Rebased, and added tests to verify the result display.
Propsed commit message:
Note: For demo purpose, don't merge this to master!