Skip to content
This repository has been archived by the owner on Mar 5, 2023. It is now read-only.

Ui: Make the ResultDisplay red on command failure #799

Closed
wants to merge 5 commits into from

Conversation

yamgent
Copy link
Member

@yamgent yamgent commented Jan 19, 2018

Part of #784. Rebased, and added tests to verify the result display.

Propsed commit message:

ResultDisplay shows an appropriate error message when the user made a 
mistake in his command. The color of the error message is the same as 
the color of a successful one.

Using a different color for error messages makes it easier for a user
to realise that it is communicating the mistake made by him.

Let's make the ResultDisplay red on command failure.

Note: For demo purpose, don't merge this to master!

@CanIHasReview-bot
Copy link

v1

@yamgent submitted v1 for review.

(📚 Archive)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/799/1/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

@Zhiyuan-Amos Zhiyuan-Amos added the pr.Answer Pull request is answer for a tutorial in developer guide. Do not actually merge. label Jan 20, 2018
Copy link
Contributor

@Zhiyuan-Amos Zhiyuan-Amos left a 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();
Copy link
Contributor

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.

Copy link
Contributor

@Zhiyuan-Amos Zhiyuan-Amos left a 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
the command execution succeeds.
(since you've already mentioned that we are only modifying 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) {
Copy link
Contributor

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

Copy link
Member Author

@yamgent yamgent Jan 27, 2018

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() {
Copy link
Contributor

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.
Copy link
Contributor

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() {
Copy link
Contributor

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;
Copy link
Contributor

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>
Copy link
Contributor

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,
Copy link
Contributor

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

Copy link
Contributor

@Zhiyuan-Amos Zhiyuan-Amos left a 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);
Copy link
Contributor

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

@CanIHasReview-bot
Copy link

v2

@yamgent submitted v2 for review.

(📚 Archive) (📈 Interdiff between v1 and v2)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/799/2/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

Copy link
Contributor

@Zhiyuan-Amos Zhiyuan-Amos left a 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.

Copy link
Contributor

@Zhiyuan-Amos Zhiyuan-Amos left a 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

@damithc
Copy link
Contributor

damithc commented Jan 28, 2018

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 ?

@CanIHasReview-bot
Copy link

v3

@yamgent submitted v3 for review.

(📚 Archive) (📈 Interdiff between v2 and v3)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/799/3/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

@yamgent
Copy link
Member Author

yamgent commented Jan 28, 2018

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 ?

I split up the commits, so now the unit tests are in [v3 2/5] and [v3 4/5] instead.

Copy link
Contributor

@damithc damithc left a 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.

@yamgent yamgent mentioned this pull request Aug 4, 2018
7 tasks
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.
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.
@CanIHasReview-bot
Copy link

v4

@yamgent submitted v4 for review.

(📚 Archive) (📈 Interdiff between v3 and v4) (📈 Range-Diff between v3 and v4)

Checkout this PR version locally
git fetch https://github.com/se-edu/addressbook-level4.git refs/pr/799/4/head:BRANCHNAME

where BRANCHNAME is the name of the local branch you wish to fetch this PR to.

@yamgent yamgent requested a review from a team August 9, 2018 05:32
@yamgent
Copy link
Member Author

yamgent commented Aug 9, 2018

Changelog:

  • fc363ad: Updated HelpCommandSystemTest.java, because it now uses assertCommandBoxShowsDefaultStyle(), but in this PR we renamed this method to assertCommandBoxAndResultDisplayShowsDefaultStyle().

@damithc damithc closed this Dec 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
pr.Answer Pull request is answer for a tutorial in developer guide. Do not actually merge.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants