8000 Setting: Adding ability to override the default element tag list. by WalterWeidner · Pull Request #2063 · jquery-validation/jquery-validation · GitHub
[go: up one dir, main page]

Skip to content

Setting: Adding ability to override the default element tag list. #2063

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

Closed
wants to merge 1 commit into from

Conversation

WalterWeidner
Copy link
@WalterWeidner WalterWeidner commented Sep 12, 2017

This override allows elements implementing an input interface to be validated

Description

We have been using jQuery validation for several years and it has been very useful for our organization. Unfortunately, one area that it falls short is where it doesn't support custom elements that behave like native inputs. There is no way (without overriding methods) that we know of to validate any input type other than those that are hard coded in the elements() prototype method. This Pull Request attempts to provide a simple method for customizing what tags the element() function looks for.

This override allows elements implementing an input interface to be validated
@staabm
Copy link
Member
staabm commented Sep 16, 2017

With custom element you mean actually a webcomponent?

Really like what I see, thx!

@@ -616,7 +617,7 @@ $.extend( $.validator, {

// Select all valid inputs inside the form (no submit or reset buttons)
return $( this.currentForm )
.find( "input, select, textarea, [contenteditable]" )
.find( validator.settings.inputSelector )
Copy link
Member

Choose a reason for hiding this comment

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

validator -> this

@staabm staabm requested a review from Arkni September 16, 2017 08:56
@@ -265,6 +265,7 @@ $.extend( $.validator, {
errorLabelContainer: $( [] ),
onsubmit: true,
ignore: ":hidden",
inputSelector: "input, select, textarea, [contenteditable]",
Copy link
Member

Choose a reason for hiding this comment

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

Other settings dont use the suffix Selector we shouldnt use it either.

Copy link
Member

Choose a reason for hiding this comment

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

Not sure yet what a good name should be for this setting.

Copy link
Member

Choose a reason for hiding this comment

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

What about targets?
It aligns well with the internal method validationTargetFor(...).

@Arkni
Copy link
Member
Arkni commented Sep 17, 2017

Over all, it looks good to me.

One small thing that come to my mind while reading the description & the patch. How can the plugin attach events (click, keyup, ...) to the custom elements as it does for standard ones? The chunk of code that attaches the event is:

$( this.currentForm )
.on( "focusin.validate focusout.validate keyup.validate",
":text, [type='password'], [type='file'], select, textarea, [type='number'], [type='search'], " +
"[type='tel'], [type='url'], [type='email'], [type='datetime'], [type='date'], [type='month'], " +
"[type='week'], [type='time'], [type='datetime-local'], [type='range'], [type='color'], " +
"[type='radio'], [type='checkbox'], [contenteditable], [type='button']", delegate )
// Support: Chrome, oldIE
// "select" is provided as event.target when clicking a option
.on( "click.validate", "select, option, [type='radio'], [type='checkbox']", delegate );

What do you propose to fix that?

@staabm staabm mentioned this pull request Sep 19, 2017
2 tasks
@Arkni
Copy link
Member
Arkni commented Nov 15, 2017

Hi @WalterWeidner

Any updates regarding this PR?

Thanks!

@stale
Copy link
stale bot commented Jun 5, 2018

This issue/proposal has been automatically marked as idle and stale because it hasn't had any recent activity. It will be automtically closed if no further activity occurs. If you think this is wrong, or the problem still persists, just pop a reply in the comments and one of the maintainers will (try!) to follow up.
Thank you for contributing :)

@stale stale bot added the stale Used to mark stale issues label Jun 5, 2018
@stale stale bot closed this Jun 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants
0