Parameter passing between pages does not work

[borismus]

I'm attempting to pass parameters from one page (ex. with a list view of items, each with an id) to the sub-page corresponding to each item. I need to pass the id to the sub-page. I'm attempting to do this with get-style parameters resulting in the following URL:

.../index.html#item.html?id=1898432

I have a pageshow callback: $('[data-role=page]').live('pageshow') which triggers when the page is loaded. However, when this event fires, the window.location isn't updated to have the extra parameters in it.

I think there are two possibilities:

1. I'm doing it wrong. Perhaps sub-hash URLs are the way to do what I'm trying to do:
   http://jquerymobile.com/demos/1.0a2/#docs/pages/docs-navmodel.html
2. The event should fire after window.location is updated to reflect the URL with parameters.

[tiegz]

I ran into the same problem (wanted to load a nested page but with extra params to load a JSON resource in the background). The only way I can think of currently keeping it within 1 subpage is to save the "id" param in a cookie.

[borismus]

I'm currently hacking around this with a 50ms setTimeout just to let the URL change. But still the strategy of using GET-style params is problematic for other reasons: jQM treats each page.html?param=val as a separate page load, so you end up with many copies of the same HTML being loaded. This might be desirable in some cases, but clearly there must be a better way of doing it.

[tiegz]

Oh nice; I guess my main use case is that I want to be able to go to a page like "index.html#child?id=123" that would load the "index.html" file using the "child" page and store parameters "id=123" somewhere. Actually, it would also be really cool if we could intercept the event and pass it through some router before the event is fired.

[fermion]

Scott, Jesse (Streb) and I were talking about this one and we're wondering if this calls for either changing how the pageshow callback is fired or introducing an entirely new event (pagecomplete, for example) that's triggered at the end of changePage's internal transitionPages function right hereish:

https://github.com/jquery/jquery-mobile/blob/master/js/jquery.mobile.navigation.js#L250

I can't decide if the better thing to do is change when pageshow is triggered or if it's a case for introducing a new callback. I'd love some input so I can try to fix this!

[fermion]

Pretty sure this is a dupe of https://github.com/jquery/jquery-mobile/issues/issue/583 and was fixed in 5456827

[sam-meder]

I know this is not quite the same issue, but we were expecting the code for changePage("#hash?param=value") to look for a page identified by #hash, i.e. we were expecting the parameters to be ignored. I realize this behavior is problematic with respect to deep linking (although for deep linking you could have the same code also work with ?param=value#hash), but how is one otherwise supposed to deal with parameterized pages?

The patch for enabling the behavior I describe can be found here: jivesoftware@53e93ef

[thegrubbsian]

I'd be happy if there were some reference to the original list element that triggered the page transition. At least then you could grab some data attribute or something from it. Or assign whatever HTML5/jquery data that was attached to the original anchor to the data property of the event argument. That way you could store data such as data-id="5" on the anchor and access it via e.data.id within the pageshow callback.

// JC

I'd like to remind you that
a.html#b?c=1
is an invalid url. The valid version is
a.html?c=1#b
the search string comes before the hash, since hash is inside one page, while query is params to the server.

[smeder]

doom777:

It is at the very least a valid URI (according to http://tools.ietf.org/html/rfc3986). That said, the point here is really that one can encode parameters in the fragment value (whether those need encoding or not).

[tiegz]

Yeah, altho it's not as common as the "/" nowadays, here's a quote from that spec:

The characters slash ("/") and question mark ("?") are allowed to
represent data within the fragment identifier. Beware that some
older, erroneous implementations may not handle this data correctly
when it is used as the base URI for relative references (Section
5.1).

I think when I initially wrote that comment I was thinking more about something like "index.html#child/123" (passing back template name and params thru a router). The only problem I can see with a question mark is that a lot of [older?] js libraries might do stuff like +document.location.href.split('?')+ without taking into account the fragment.

[OpenGrid]

I think this solution look much better than passing parameters after hash
http://forum.jquery.com/topic/passing-parameters-to-a-page-in-a-mobile-jquery-app#14737000001858480

[owain]

It seems link this is still an issue after the navigation refractor in Beta 1.

[ArtS]

It looks like a lot of people are hitting this problem and end up inventing half-assed solutions using cookies, local storage, global variables etc - just have a look at the jQuery forum - searching for "pass parameters" brings up quite a few questions: http://forum.jquery.com/search/pass parameters (you will need to click on 'jQuery Mobile' in Refine Search)

I'd say this is a very common scenario and it would be really good if parameter passing gets implemented in some generic shape or form, say via data- attributes of the "a" tag.

If one could go:

<a href="#details" data-parameter="1900">Account N12394-12341</a>

and then have some function to call to retrieve the parameter value after page transition is finished.

[ArtS]

I just realised, however, that proposed solution (ie. keeping parameters in data-* attributes) will not work for cases when page is bookmarked.

So the original proposal of having parametrised hash is better in that regard.

[owain]

Looks like the guys are looking to include a potential solution in Beta 2...

https://github.com/jquery/jquery-mobile/wiki/Refactor:-navigation.js-A4.1-extensibility#template

The "URL handling hook (for data passing)" section