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
NIFI-4390 - Add a keyboard shortcut for Connection... #2157
Conversation
...related dialogs Connection related dialogs can be confirmed by the Enter key.
Will review... |
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.
Thanks for the PR @yuri1969! Sorry for the delay. I have a couple questions regarding the changes that I added to the review.
@@ -50,6 +50,7 @@ | |||
* disabled: isDisabledFunction, | |||
* handler: { | |||
* click: applyHandler | |||
* keyup: keyupHandler |
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.
Is there a reason the keyupHandler
is specified per button? If both Apply and Cancel have keyupHandlers specified, which one is called? Can one handler 'consume' the event and prevent further listeners from triggering?
Does it make sense to only allow a single key listener per modal? In other places, we have placed key listeners on components within a dialog. Was that not an option here? How do the key listeners effect those if configured at the same time?
@@ -127,6 +128,10 @@ | |||
// check if the button should be disabled | |||
if (isDisabled()) { | |||
button.addClass('disabled-button'); | |||
// remove keyup listener | |||
if (isDefinedAndNotNull(buttonConfig.handler) && isDefinedAndNotNull(buttonConfig.handler.keyup) && typeof buttonConfig.handler.keyup === 'function') { | |||
document.removeEventListener('keyup', buttonConfig.handler.keyup, true); |
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.
Is there a reason we're not using jQuery for adding/removing the event listeners? This isn't a big deal but I'd prefer to remain consistent with the rest of the code base if possible. Does it have to do with the useCapture flag you've specified here?
@mcgilman This PR was created solely in order to speed up the connection creation. There was a follow-up discussion at https://issues.apache.org/jira/browse/NIFI-4390. So I'm not sure if this particular PR is still valid in the given context. |
We're marking this PR as stale due to lack of updates in the past few months. If after another couple of weeks the stale label has not been removed this PR will be closed. This stale marker and eventual auto close does not indicate a judgement of the PR just lack of reviewer bandwidth and helps us keep the PR queue more manageable. If you would like this PR re-opened you can do so and a committer can remove the stale tag. Or you can open a new PR. Try to help review other PRs to increase PR review bandwidth which in turn helps yours. |
...related dialogs
Connection related dialogs can be confirmed by the Enter key.
Thank you for submitting a contribution to Apache NiFi.
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
For all changes:
Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
Does your PR title start with NIFI-XXXX where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
Has your PR been rebased against the latest commit within the target branch (typically master)?
Is your initial contribution a single, squashed commit?
For code changes:
For documentation related changes:
Note:
Please ensure that once the PR is submitted, you check travis-ci for build issues and submit an update to your PR as soon as possible.