Skip to content
This repository has been archived by the owner on Oct 8, 2021. It is now read-only.

Refactor: navigation.js A4.1 extensibility

Jump to bottom
StevenBlack edited this page May 9, 2011 · 24 revisions

List of triggers fired by jquery.mobile.navigation.js @ A4.1

In function transitionPages() definition:

  • from.data( "page" )._trigger( "beforehide", null, { nextPage: to } ); on L447
  • to.data( "page" )._trigger( "beforeshow", null, { prevPage: from || $( "" ) } ); on L449.
    Notes
  • These two triggers are co-located and occur essentially at the same juncture.
  • It's widely agreed that the beforeshow trigger, implementation-named pagebeforeshow via the widget factory, needs to be moved until the page is, in fact, right before show.

In function pageChangeComplete() definition:

  • from.data( "page" )._trigger( "hide", null, { nextPage: to } ); on L482
  • to.data( "page" )._trigger( "show", null, { prevPage: from || $( "" ) } ); on L485.

Notes

  • These two triggers are co-located and occur essentially at the same juncture.

List of clear junctures in jquery.mobile.navigation.js @ A4.1

These locations are good candidates for extensibility hooks because they are at critical junctures hence likely effective, as well as being at predictable junctures hence usable by developers who aren't jQuery Mobile ninjas.

  • At the very top of changePage() to allow for situation specific overrides or pre-empting. For example,
    • overriding the current constraint on navigating to the same url, or
    • forcing a user gesture-consistent transition.
    • Setup and state-setting tasks we're already doing at the top of changePage(), like the call to defaultTransition()
  • At the very bottom of enhancePage(), after the call to the page plugin, to allow for injection of further custom markup by plugins or by developers.

URL handling hook

See this [https://developers.jivesoftware.com/community/blogs/engineering/2011/04/15/jivin-with-jquery-mobile-inter-page-navigation](Jive Apps article on jQuery Mobile navigation). Here Sam Meder alludes to a small changw in jQuery Mobile code to allow using url queryString sections that don't interfere with the hash, to pass data.

As mentioned above, the most significant challenge is passing data to each template page in order to have it load the correct content into the template. The obvious mechanism for this level of data-passing is HTTP query string parameters, i.e., "?name=value". However, if you naively try to add this style of parameter after a hash like "#document-template?documentId=1234", jQuery Mobile will interpret the query string as part of the page ID hash and get confused. Placing the query string before the hash ("?documentId=1234#document-template") is handled correctly by jQuery Mobile -- i.e., "documentId" is ignored. However, if links from one jQuery Mobile application page to another application page are constructed like this ("index.html?param=value#pageId"), the web browser will think it needs to make a new request to the page, and therefore reload all of index.html, which was not acceptable. So, we made a small change to the code in jQuery Mobile that identifies the target page, causing jQuery Mobile to ignore "?name=value"-style HTTP query string parameters when processing the hash fragment string.

Read the whole thing. TL;DR A URL processing hook would be nice.

Implementation: A pre-hook to allow the user to extract data from the url prior to jQuery Mobile's normal url processing.

Hook to allow transitioning to the same page.

Currently this code categorically disallows that: https://github.com/jquery/jquery-mobile/blob/master/js/jquery.mobile.navigation.js#L358-362

Clone this wiki locally