No description provided.
[formwidget] New base class for form widgets
[select] Deriving from formwidget instead -- Fixes #5137
[checkboxradio] Deriving from formwidget instead -- Fixes #5137
[slider] Deriving from formwidget instead -- Fixes #5137
A couple questions:
A couple questions:
We're using the "widget inheritance" model when this, at least by my estimation, appears to be behavioral. That is, can we just extend the prototypes of our form widgets with a "mixin" object to capture this? Inheritance is generally extremely brittle.
I'm not sure what the effect of that would be on the widget prototype. UI has done a good job implementing inheritance properly, and we should be using it to override the _reset() method introduced by the form superclass. If we go the mixin way, we may end up having to reproduce some of UI's work.
Have we looked into the setTimeout? Is that something we could solve with an event (seems unreasonable but worth asking)? I'm just curious why it requires the stack to unwind (I'm guessing something to do with the order in which we report the value on selection).
I couldn't figure it out either why the stack has to unwind. The fact is that, if we don't unwind, only the input fields are reset, and that's probably because in their case we do not hide the original native widget.
Is the goal to move over to the _reset because it's the UI standard? If it is I'm for just moving the functionality in our widgets into a _reset and then calling that from refresh. This saves on confusion with calls to refresh because the call site is in the widget definition, without committing to yet another class in the widget hierarchy.
UI isn't really concerned with form inputs. The only widget they have that's tied to a form input is the button, which has reset logic - the same as ours, i.e., call refresh on form reset. So, I'm not modelling this after UI.
The best reason I see to avoid another class is that we should avoid having too many abstract classes. I'm not sure if we could call this class abstract, but the fact is it is not itself a widget, nor is it useful by itself. So, I suppose we ought to organize this such that every form widget makes a call to a common $.mobile._setMeUpForFormReset( callbackToRunInsteadOfTheDefaultRefresh ) which binds to "reset", does the stack unwind, and calls _reset() if no callback is given and if the widget has a refresh method. In fact, it's probably a bad idea to pass a callback at all, because, if anyone ever decides to subclass the widget whose _create() passes a callback, that widget won't have the option of overriding the passed-in function.
$.mobile._setMeUpForFormReset( callbackToRunInsteadOfTheDefaultRefresh )
If we go this route, we should establish
Hmmm ... while implementing this other route, I ran into @johnbender's 3. from above: We cannot simply move the body of refresh() into _reset() and then call _reset() from refresh() because, for example, the slider's refresh() method takes parameters, whereas the _reset() method does not. Thus, in the current implementation, the slider overrides the form widget's implementation of _reset(), calling refresh() with some parameters.
This would not be possible if the body of refresh() would be executed without parameters.
Check out #5214 - it accomplishes the same thing without introducing a new base class.
Regarding the setTimeout. I don't think we can avoid this. When the reset event fires the values of the form elements aren't actually reset yet so we grab the old value when we call refresh(). Unfortunately the change event doesn't fire after the values has been updated, otherwise this wouldn't have been an issue at all.