Nav thoughts

Do you think we can modify the $.mobile.navigate method to take its parameters as hash? Like, ( url, data, {/* options */} ), or ( { url: url, data: data, otherOption: otherOption, ... } )

The reason I ask is that I'm thinking that we could move a lot of the URL calculation into $.mobile.navigate and have it all in one place. Like: ( url, data, { allowDeepLink: true/false } ), and $.mobile.navigate would also take into account $.mobile.hashListeningEnabled, $.mobile.changePage.defaults.changeHash, etc ...

For example we could move a lot of the url calculation code out of changePage and popup and dialog into this method, and we could make the parameters more flexible (which actually calls for having only one parameter - a hash): { back: true/false (false means forward), url: url, data: data } where the presence of the key "back" means we don't bother checking the url, but instead we either simply call $.mobile.back() or we do the history-disabled version of back, namely what dialog and popup currently do when history is disabled.

I think our ultimate goal should be to have our elements call this method in one of four ways:

1. URL + deepLink
2. [ URL + ]noDeepLink (url is optional if you just wanna add a dialogHashKey to the current URL, however, if you're loading a dialog via AJAX, it's not optional)
3. Back
4. Forward

Then, we can concentrate our navigation-when-history-is-disabled, stale-dialogHashKey-reuse, initial-url-has-dialogHashKey-corner-case and whatever else into this one place.

Another thought (method name is irrelevant):

// whereTo:
//  - if boolean, then true means back, false means forward
//  - if string, it's the URL
//  - if undefined, it's empty, and deepLink must be false,
//    and the semantics are to simply move to a dialogHashKey
//    state off the current location
// deepLink: boolean
// whenDone: deferred:
//  - success is called when the browser history has been
//    created and the hashchange/popstate/whatever events
//    have all passed
//  - failure is called when a default (such as
//    beforenavigate) has been prevented. In this case, the
//    browser history entry is the same as it was when this
//    method was called.
$.mobile.go( whereTo, deepLink, whenDone ) {
}

This function would perform all URL calculation and would then branch for two cases: hash manipulation is enabled vs. disabled. If enabled, it would likely call $.mobile.navigate, otherwise it would call $.mobile.history.add()

changePage could call this function with the URL that was passed to it. It might still have to do some URL calculation to determine which file should be AJAXed in. If we want to add that calculation into this function as well, then we could return the resulting URL to give to loadPage(). However, if we do that then the deferred must not be resolved synchronously, because changePage must continue on and loadPage. It will be tempting to resolve it synchronously when history is off, because there are no hashchange/popstate/whatever events to wait for (as I describe in the function parameter spec above).

This would also introduce a race condition between the arrival of the hashchange/popstate/whatever signals and the arrival of the AJAXed-in page. If we want to ensure that the page is loaded before the history entry is created (as is the case currently) then the calculate-URL-to-pass-to-loadPage portion would have to be made into a function on its own to be called separately.