Skip to content

Handle form reset in form widgets without introducing a base class #5214

Closed
wants to merge 4 commits into from

4 participants

@gabrielschulhof

No description provided.

@johnbender

The only two thoughts I have are, first, that tacking the extension onto the already crowded global namespace $.mobile is probably a bad idea, and that we should extend the prototype directly. Though I understand why you put it on the global namespace, where else would you put it?

I think it's probably time (it probably was time for this a long time ago) to commit to a project convention for widget extension that isn't the inheritance hierarchy.

Here's my proposal.

First we create top level namespace for common behaviors in jquery.mobile.core.js:

// ...

// namespace to contain extension functions for widgets and other object constructors
$.mobile.behaviors = {};

// ... 

Then for the current common functionality we can create individual behaviors like so:

In widgets/forms/reset.js

define(["jquery", "core"], function( $ ) {
    $.mobile.behaviors.formReset = function( widget ) {
        widget.prototype._formReset(function() {
            var self = this;

            self._on( self.element.closest( "form" ), {
                "reset": function() {
                    setTimeout( $.proxy( self, "_reset" ) );
                }
            });
        });
    };
});

In widgets/forms/selectmenu.js

$.widget( "mobile.selectmenu", $.mobile.widget, {
    _create: function() {
        // ...

        this._formReset();

        // ...
    }
});

$.mobile.behaviors.formReset( $.mobile.selectmenu );
@frequent

how about actions instead of behaviors ?

@johnbender

@frequent it's not necessarily going to be a single action, it could be a collection of behaviors. "Behaviors" is poor anyway, but that's a general software convention (Mixins => behavioral).

I have to fix this up to use $.widget anyhow. See @scottgonzalez's comment

@johnbender

Adjusted per @scottgonzalez's suggestion

define(["jquery", "core"], function( $ ) {
    $.mobile.behaviors.formReset = {
        _formReset: function() {
            var self = this;

            self._on( self.element.closest( "form" ), {
                "reset": function() {
                    setTimeout( $.proxy( self, "_reset" ) );
                }
            });
        }
    };
});

$.widget( "mobile.selectmenu", $.mobile.widget, {
    _create: function() {
        // ...

        this._formReset();

        // ...
    }
});

$.widget( "mobile.selectmenu", $.mobile.behaviors.formReset );
@scottgonzalez
jQuery Foundation member

You should very rarely need to capture this...

_formReset: function() {
    this._on( this.element.closest( "form" ), {
        reset: function() {
            this._delay( "_reset" );
        }
    });
}
@johnbender

@frequent

That was a poor explanation. Actions suggests, to me at least, a single function/method. In this case we might have collections of functions or methods that work together to form some common "behavior" - that's the idea at least.

@frequent

@johnbender

I see. I was thinking along, like in a collection of "actions", but general software convention does sound convincing :-)

@gabrielschulhof

Hey! I've re-implemented this with behaviours: #5216

@frequent

@gabrielschulhof: so with this implemented, I could ditch my "manual form widget reset", since JQM will reset selects/sliders et al to their intial values?

One thing I'm starting to like lately is adding a data-persist="true" attribute on form elements, which then are not reset when I'm running my form cleanup. Anyway, can't wait to use this 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.