search

PolymerElements / iron-input

An input with data binding
https://webcomponents.org/element/PolymerElements/iron-input
33 stars 45 forks source link

adding inheritance from iron-form-element-behavior #64

Closed MeTaNoV closed 8 years ago

MeTaNoV commented 8 years ago

Fixing Issue 63

notwaldorf commented 8 years ago

I don't think this is the correct solution. Iron-input is just an so it will already be counted inside the iron-form. If you add the behaviour to it, then a paper-input will be submitted twice.

I think the solution might be for the iron form to know how to deal with iron-inputs instead

MeTaNoV commented 8 years ago

Currently, a iron-input is not registered by the iron-form in the _customElements list. Moreover, in the iron-form a protection of duplication is already in place in both validate() and serialize() functions which is currently inhibiting an iron-input to be taken into account. So adding the iron-form-element-behavior won't triggered a double submission. Or did I miss another hidden subtility? :) In that case, we can also modify the iron-form to relax this constraints. Thanks for the follow-up!

MeTaNoV commented 8 years ago

Sorry, I got the point... :) paper-input also inherit from it! This make the situation more difficult to tackle...

MeTaNoV commented 8 years ago

The duplication issue would also arise if someone decide to write a custom element that wrap a paper-input and inherit from IronFormElementBehavior...

A way to prevent this would be to stop the event propagation upward in the IronFormElementBehavior if the event comes from a source different from itself. This way, the outermost IronFormElementBehavior will be the only one being registered by the iron-form.

@notwaldorf what do you think?

notwaldorf commented 8 years ago

@MeTaNoV The duplication bit will be solved by someone in an iron-form PR -- basically, it will check whether an element is in the native form's elements array, and if it is, not submit it when found again in the customElements array. That being said, I still don't see what this PR fixes -- an iron-input is just a type extension of a native input, so it will work in both native and the iron-form by virtue of that. It doesn't need this extra behaviour for anything.