-
Notifications
You must be signed in to change notification settings - Fork 2.4k
Refactor: navigation.js A4.1 extensibility
This document serves to list places where extensibility of jQuery Mobile could be improved.
-
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-namedpagebeforeshow
via the widget factory, needs to be moved until the page is, in fact, right before show.
-
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.
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 todefaultTransition()
- 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.
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.
A subset of what's required by [https://developers.jivesoftware.com/community/blogs/engineering/2011/04/15/jivin-with-jquery-mobile-inter-page-navigation](Jive Apps article on jQuery Mobile navigation)
From IRC ... user wants to change the contents of the current page and re-display it.
I am trying to create a shopping cart, where u can swipe left or right, and u see items of different category on each page.
Currently this code categorically disallows that: https://github.com/jquery/jquery-mobile/blob/master/js/jquery.mobile.navigation.js#L358-362