jQuery Forum

So I'm using jQuery Mobile with the intent of mimicking native apps... and I'm not succeeding.

I like that jQM facilitates the "single page model", but it's not doing enough.  Consider a standard scaffolded Rails CRUD app.  For simplicity sake, let's just say there are two pages:  an index page (which lists all the items) and a new page (which has a form to create a new item).  Assume we desire that submitting the form takes us back to the index page which will then show the newly created item.

Root (/) is the index page.  It has a button that links to the new page.  Clicking it works great; an ajax request is made and we're smoothly transitioned to the new "page". It even has a back button that properly transitions back to the index page.

At this point, we have 2 "pages" in the dom with ids: item-index and item-new, and we're currently on the new page.  Now the desired behavior for filling out the new form and submitting it is that we're taken back to the index page where we see the new item.

jQM overrides the default submit handler to submit the form via ajax, it then creates a new index "page" from the response and transitions to it.  That's all fine and good except for 3 problems:

1)  Now we have 3 "pages" in the dom:  item-index, item-new, and another item-index

2)  The index page now has a back button on it!  Sure we can remove it by saying backbtn=false on the page div (well, in theory, it doesn't actually work with jQM being in alpha and all), but even if we do remove it, we can still navigate back by hitting the browser's back button.

3)  The url bar in the browser has some funky url in it.  Why is this (the user asks)?  I'm back on the index page where I started from... didn't it used to just say "/" instead of this weird url?

So I thought I'd be smart and fix this.  I removed jQM's submit handler and installed my own.  It does the following:

1)  Submits the form via ajax.

2)  Searches the response for divs for "pages" (i.e. data-role="page").

3)  If any "pages" in the current dom have the same ids of the "pages" in the response, then delete them out of the dom.

4)  Insert the new "pages" into the dom.

5)  * Transition (changePage()) to the new page.

* Originally, I had step 5) be "window.history.back()" but wow that messed things up.

So that fixed the problem of the duplicate pages in the dom, but now my navigation is severely messed up.  All my back buttons are broken.  Plus it doesn't fix the issue of the url bar having a funky url instead of being "/".

So my question is... why rely on window.history.back() for navigation?  When I submit the new form, I want to go back to the index page with my history being that of when I was last on the index page!  Instead, my history says my last page was the new page.  Technically, yes it is... but I'm done there... I already submitted that form and it can't be undone... so what's the point of going back there?

Admittedly, the example is a bit contrived, but I've encountered a lot of examples where I want to navigate to page-x after submitting a form and I want my history to be what my history was when I was last on page-x.  That way, my back buttons work like how I expect (i.e. take me back to the page I was on before page-x, NOT back to the form I just submitted).

Why doesn't jQM implement their own history object and use that for navigation and also allow the user to manipulate it? *

Instead of saying window.history.back() to go back (like on back buttons), we'd say $.mobile.history.back(), which would just find the target page and then do a changePage() without updating the history.

* I know of urlHistory, but it's only used to determine what transition animations to use.

Sorry for the long winded post... I half expect someone to answer with a one-liner that will bring to light a fundamental misunderstanding on my part which will make all these issue moot... :)