Configurable options: original behaviors get lost

[starnutoditopo]

Issue description:

After having set some configuration options (like linkBindingEnabled or hashListeningEnabled; see http://api.jquerymobile.com/global-config/ ), there is no way to perform the original behaviors any more.

An example is the use of Query Mobile with Backbone.js, as shown at http://demos.jquerymobile.com/1.4.5/backbone-requirejs/

Here $.mobile.linkBindingEnabled and $.mobile.hashListeningEnabled are set to false. Now, if a view contains a "select" tag, there is no way to make it show its popup whit the nice JQM's style, setting data-native-menu="false".

This problem has already been pointed out for example at http://stackoverflow.com/q/16187209 and at http://stackoverflow.com/a/16209370 some hack is reported to attempt to workaround it.
Note that the suggested workaround do not really perform exactly like the original behaviors (see http://jsfiddle.net/f9Pt2/)

Test page:

http://jsbin.com/tadewepame/1/

Steps to reproduce:

In te thest page, just try to select an option from the list. As jqm has been configured with
$.mobile.ajaxEnabled = false; $.mobile.linkBindingEnabled = false; $.mobile.hashListeningEnabled = false; $.mobile.pushStateEnabled = false; and the select element ha been marked with data-native-menu="false", nothing appears (as expected!), but there is no way to force the popup to show, so that the configuration options, just for that case, could be ignored.

Platforms/browsers:
Chrome on Windows 7

jQuery Mobile and jQuery core version used:
jquery 2.1.3
jquery mobile 1.4.5

[gabrielschulhof]

http://jsbin.com/sacota/4/ shows you how to get the popup to open. We still have a bug though, because our API docs do not mention that the selectmenu widget generates an id for itself if it doesn't already have one from the markup, and that it then proceeds to derive ids for all the elements it generates by appending suffixes to its own id. I have opened jquery/api.jquerymobile.com#359 to address this issue.

[starnutoditopo]

Thanks for the reply!
I saw the sample at http://jsbin.com/sacota/4/ , but my issue is not about showing the popup in particular, but to have the capability to perform any action that jqm would do if those options were not set to false (i.e.: show popups, manage routing, etc.).

An example in "pseudo code" of what I think to be missing:

   ...
            $.mobile.ajaxEnabled = false;
            $.mobile.linkBindingEnabled = false;
            $.mobile.hashListeningEnabled = false;
            $.mobile.pushStateEnabled = false;
   ...

            $( document ).on( "click", "#whatever", function( event ) {
               RunMyFantasticCodeToHandleClickEvents();
               LetJQueryMobileHandleTheEventAsTheOptionVariableWereNotSetToFalse(); 
            });

Referring to the example at http://jsbin.com/sacota/4/, what I would like to do, regarding routing, is:

 var Router = Backbone.Router.extend({
        routes: {
            "": "defaultAction",
            "*actions": "defaultAction"
        },

        defaultAction: function (actions) {
            console.log('Performing default action');
            // now leave jquery mobile handle the routing as it would do if hashListeningEnabled would not be set to false
            LetJqueryMobileHandleRoutingAsIfHashListeningEnabledWouldNotBeFalse();
        }       
    });

Thanks!

[gabrielschulhof]

You can get part of the way there with

$( ":mobile-pagecontainer" ).pagecontainer( "change", url );

as the default action. I'm assuming there's a way of retrieving the URL for which the default action is to be taken.

That's what the click handler ends up calling anyway. The only piece you'll be missing is the click handlers checks which make sure the URL is one it can handle.

I'm going to reopen the issue because it sheds light on an aspect of navigation we need to keep in mind when we do the nav refactor.

It seems that we need to roll navigation in such a way that it can serve as a link in a daisy chain of different navigation implementations.

One way to go

The easiest way to do this is to maybe factor out the click handler into its own module, providing two items: The click handler logic, but without actually attaching the event handler.

So, like,

$.mobile.clickHandler = function( event ) {
  /* do what the click handler currently does */
};

You could then detach the handler yourself, reversing the action of js/navigation.js, while continuing to have access to the code that runs, but having to call the handler yourself from, say, the default action of a backbone router.

A better way to go

Build the click handler into a pagecontainer widget extension, predicated upon a boolean option which enables the event handler:

$.widget( "mobile.pagecontainer", $.mobile.pagecontainer, {
  options: {
    linkBindingEnabled: true
  },
  _create: function() {
    this._superApply( arguments );
    this._on({ click: "_handleClick" });
  },
  _handleClick: function( event ) {
    if ( this.options.linkBindingEnabled ) {
      return this.handleClick( event );
    }
  },

  // Public API, available for calling from other frameworks
  handleClick: function( event, options ) {
  }
});

This latter approach would give us per-pagecontainer widget click handling. We probably also need to add the vclick handler, and maybe even the form submit handler to the widget.

At this point we have supplanted linkBindingEnabled and made it per-pagecotnainer. Then we can also move pushStateEnabled, hashListeningEnabled, and ajaxEnabled into the pagecontainer widget's options.

The options parameter to handleClick() could be used to pass options which temporarily override the value of the widget-widge options, much like the way popup accepts overrides from the link (such as, for example, position-to).

@starnutoditopo a modification such as this would then allow you to

$( ":mobile-pagecontainer" ).pagecontainer( "handleClick", event, {
  ajaxEnabled: true,
  hashListeningEnabled: true
});

... and the pagecontainer would behave as if those flags were true.

[starnutoditopo]

Ok.

Hope that this could improve next versions of JQM!

Thanks!

Xc

On Thu, Feb 12, 2015 at 12:34 PM, gabrielschulhof notifications@github.com
wrote:

Reopened #7961 #7961.

—
Reply to this email directly or view it on GitHub
#7961 (comment).