Search jQuery

jQuery Forum

Proposal: $.mobile.pageTransitionFilter

in Developing jQuery Mobile • 12 years ago

One common issue I've been hitting again and again is how to work with jQM's default click handling when you want to interface directly with a rest api. jQM's default page handling framework (where it expects jQM style HTML from the server) is great for lots of projects -- making it easy to bootstrap, but it becomes a burden for other things like Phonegap style apps where we have limits around how we deploy (i.e., localizing all html pages vs. accessing them remotely). In Phonegap's case, you will likely need to store all of your html on the packaged app rather than access them remotely for two reasons 1) jQM's default click handler will treat remote pages as external pages due to the cross-domain nature and 2) the App Store(s) are likely to turn down apps that access pages remotely. Unfortunately, jQM's current page handling makes it difficult to support interacting with rest apis (that return json) and dynamically constructing pages from templates.

I've been experimenting with a few different strategies to work around jqm's default click handling. One strategy I use is to use href="#" on all pages where I want to get json data and render html through js. I do this by binding my own click handler to these type of links (since jQM ignores links with href="#"). This works fine, but part of this strategy is defining how to handle page transitions and history -- employing $.mobile.changePage in my custom click handler solves this issue. Along with defining a custom click handler, you also have to define a custom onload handler to account for times when a user might navigate to that page directly. In short, I've recreated jQM's page handler to support my json data based page rendering. This feels strange and hackish.

Another strategy I'm experimenting with is just going with the default jQM click handler then binding my json/template resolution code to "pagebeforecreate". The problem with this is that the page will likely render before the ajax call to get the json code and template rendering is done. Basically, "pagebeforecreate" doesn't allow us to "pause" the page transition/rendering until the our ajax call is complete. What I'd love to see is an option to pause the current event through jQM's set of "page*" events by allowing the dev to pass a callback. Maybe a good option for this is to use jQ's new deferred/promise features:

So instead of:

// asynchronous
$('#somepage').bind('pagebeforecreate',function(){... make ajax call for json data ... })

We do something like this:

// synchronous through promises
$.mobile.pageTransitionFilter('beforecreate',{
   ...
   make ajax call for json data. if successful, resolve promise to continue page transition
   ...
});

This code gets executed much like a "pagebeforecreate" binding but somehow pauses the execution until the promise is resolved.

Thoughts?

Replies(6)

toddparker

Re: Proposal: $.mobile.pageTransitionFilter

12 years ago

This is an interesting proposal. I'm curious to hear what other developers think. In general, the mobile team is aware that we need to figure out how to handle different URL schemes so we're collecting input from the community so this is a very helpful post. Thanks!

..............................................
Todd Parker
jQuery Mobile & UI design lead
Partner, Filament Group Inc.

todd@filamentgroup.com

oded.bend..

Re: Proposal: $.mobile.pageTransitionFilter

12 years ago

Hi all,

I'm relatively new to JQM (been working with it for the past month or two), but I thought I'd offer my two cents anyways.

I am using JQM to build a dynamic app. Mine requires loading some JSON containing templates via jsonp and building JQM pages from them, with custom behavior defined in the JSON attached to the created pages (event handlers and such).

For the purpose of a POC I decided to skip the templating part (since it's a solved problem that has nothing to do with JQM), but to still load and build the pages a dynamically. After some playing around I resorted to disabling all handling of clicks/history by JQM, and writing my own getPage method which does the JSONP call and then runs a callback function to attache the behavior to the requested page.I keep track of my app's state using a cookie.

My getPage function issues a request to a simple service that serves my finished JQM html according to a "UID". The returned html may contain more than a single JQM page, so I use a "pageId" to identify what internal page to navigate to. After loading the page an optional callback is attached to the "pageshow" event of the page. This contains the specific logic for handling each page's behavior (event handlers and such). Of course, getPage first checks to see if the page already exists in the dom before trying to fetch it, and skips the JSONP request if it does.

The code for getPage looks like this

function getPage(UID,pageId,callback){
    var page;
    if($('#'+pageId).length>0){

        //callback is executed after page is loaded
        if (callback !== undefined){
            $('#'+pageId).one('pageshow',function(event, ui){
                callback();
            });
        }
        $.mobile.changePage(pageId, "none", false, false);
        
        
    }else{

        $.getJSON("http://foo.bar/getPage?UID="+UID+"&callback=?",function(pageObj) {
            if (pageObj.success)
            {
                page=$(pageObj.data.html);
                $('body').append(page);
                $.mobile.initializePage();

                //callback is executed after page is loaded and before state is changed
                if (callback !== undefined){
                    $('#'+pageId).one('pageshow',function(event, ui){
                        callback();
                    });
                }

                $.mobile.changePage(pageId, "none", false, false);
                           
            }
        });
    }
}

(ps. I know that I could bind callback directly, I do it this way as a preparation to the time I enhance the logic to use the prev/next page info from the ui object)

The actual calls to getPage are of course done by my own event handlers, so I never really use anchors for navigation between pages.

I think that it could be great for my purposes if the hijaxing behavior of JQM would have been more customizable, with the possibility to define some custom changePage wrapper such as my getPage function. something along the lines of $.mobile.changePageWrapper=function(event,ui){}; taht would be called instead of changePage when defined.

An alternative is to add a "beforechangepage" event handler where one could handle the request if needed and return false to cancel the changePage and only issue changePage manually after the request succeeds.

For both of these options it might be a good idea to be able to tell JQM to use this behavior for a specific anchor by defining some property for it. Either as an opt in or opt out, or both.

Adding the custom logic for each page would still be done using the normal page events, and the binding could be done in the beforechangepage or the changePage wrapper.

I hope this makes some sense, as I disclaimed above, I'm pretty noob in JQM :)

rmanalan

Re: Re: Proposal: $.mobile.pageTransitionFilter

12 years ago

@oded this is a variation of a strategy I've been testing out as well. The problem with this strategy is it's very hackish.

The root of the problem is how jQM hijacks the default click behavior. I think that's fine, but after more thought, a good solution might be to allow devs to provide either a way to override or filter jQM's click handler. A possible way to do this is to introduce a new data attribute called data-event-handler. If a link, button, or form element has that defined, jQM could call the custom event handler passing it the context and a callback that will continue the standard transition and changePage behavior. For example:

<a href="/helloworld.html" data-event-handler="doHelloWorld">Hello World</a>

In this example, the /helloworld.html contains the template code (jquery-tmpl, mustache, etc).

jQM's $('a').live('click',function(event){...}) handler would then look for the data-event-handler. If it exists, it would first call doHelloWorld passing to it the context and a callback that allows jQM to proceed with the default click handling.

The only issue with this solution is that the custom event handler will get called before jQM retrieves the /helloworld.html which contains the template code. To handle this, we'll need to tell the callback how to bind the template and data together... maybe there needs to be a render callback passed to the original callback:

// custom click event handler called when data-event-handler='doHelloWorld'
function doHelloWorld(context, callback){
// get json data before rendering the page
$.ajax({
url: '/helloworld.json',
success: function(d){
var data = d;
// proceed with jQM's default page handling then have it callback with the template
// after the /helloworld.html is retrieved
callback(function(template){
// this is where we bind our data to the template... using jquery-tmpl as an example
$(template).tmpl(data).appendTo('#somediv');
}
}
}

This is pretty rough, but the injection and exchange between jQM's default handler and the custom handler feels about right.

Thoughts?

oded.bend..

Re: Proposal: $.mobile.pageTransitionFilter

12 years ago

@rmanalan, I agree it is a variation on the same strategy and that it's hackish. I think you have touched on a very important and somewhat painful point for dynamic apps in this otherwise simply amazing framework. And if it wasn't clear, I am very much in favor of the direction you are suggesting here.

About adding a data-event-handler, the only major issue I find with it is that for a project that mainly consists on anchors pages which will need this attribute it is inefficient and feels inelegant to add this to each an every anchor. I guess that a solution could be an option to define a default handler such as I suggested, with an option to override it with the data-event-handler attribute you suggested for specific anchors that need special treatment. this should also enable to define data-event-handler ="", or "none", to override a handler that was defined as default, for anchors that need only the default JQM behavior.

bmurmistro

Re: Proposal: $.mobile.pageTransitionFilter

11 years ago

I realize this post hasn't been updated for a while and was wondering if any decisions have been made regarding @rmanalan's proposal?

My app consumes json via rest apis and dynamically constructs pages from templates (using http://beebole.com/pure/ as our templating engine). For these types of pages, I'm binding to the pagebeforecreate create event and making my ajax call there. Since I'm unable to "pause" the pagebeforecreate event, I hide the content div of the requested page and show my own inline spinner to notify the user that the page is still being loaded. Once the ajax call returns and I apply my template I remove the spinner and then show the page.

    $('#someId').live('pagebeforecreate',function(event){
         show spinner in div
          $.ajax({
            url: someUrl,
            complete: function(){
        ...
                remove spinner
            },
            success: function(data){
        ...
                    $("#someId .ui-header")
                        .directives({
                           '.header' : firstName
                    }).render(data);
                    $(".content").buttonMarkup().trigger('updatelayout');
                    $(".content").show();
                }
         });
    });

Obviously this doesn't make for a smooth transition. It would be great if I could apply my template prior to the jqm transition taking place. @rmanalan, I'm curious what your end solution was? Also, if anyone else has any other strategies, please do share.

Again, I know this post hasn't been updated for a while and I'm curious if jqm has a strategy going forward for these types of issues.

Thanks,

Brandon