Add jqm transition & layout support
cjolif opened this issue · comments
We currently do support delite transition & layout, we need to support jqm as well.
The requireJS loader paths needs to define how we will be referencing jquery, jquery.mobile and the jquery.mobile css. I have seen a few things used on other demos, the most common seems to be:
"jquery": "https://code.jquery.com/jquery-2.1.1.min",
"jquerymobile": "http://code.jquery.com/mobile/1.4.3/jquery.mobile-1.4.3",
"jquerymobilecss": "http://code.jquery.com/mobile/1.4.3/"
But I have also seen jquery-mobile and jqm used instead of jquerymobile. Whatever we use has to be used in the code, so whatever we pick will have to be used in the app.
As the name files are jquery and jquery.mobile, maybe we should keep that for module IDs even if that is not the most frequent use?
That works, I will go with:
"jquery": "https://code.jquery.com/jquery-2.1.1.min",
"jquery.mobile": 'https://code.jquery.com/mobile/1.4.3/jquery.mobile-1.4.3.min',
"jquery.mobile.css": "http://code.jquery.com/mobile/1.4.3/"
Another question deals with how the app developer will want to setup the views/templates as JQM pages, or have the view parent be the pages.
The issue came about because JQM will insert a page into the body if there is not one in the html. So when I was trying to have the pages in the templates things would not work because the JQM would insert the top level page, and when the views were added they were not being added at the same level, so the view pages would not be shown. So I tried to have the view parent setup as a page in the html to avoid having JQM insert the top level page. That worked fine, but it changed how the transition would be done, it had to be done on the view.parentNode instead of on the view itself.
Then I found that if I wanted to keep the page in the template, I could add code to find the JQM page, and add the views to that page's parent. As a simple case, if there are no pages in the index.html, and the view templates have the page on the outer div, and the config does not specify a containerSelector or a parentSelector for the view, we can find the parent node of the page which JQM inserted, and use that for the containerNode, and things will work ok.
So at this point I have a config option "useParentNodeJqm": true which tells me to do the transition on the parent instead of the view. Maybe there is a way to be able to determine which node is the page without requiring the option to be set.
I guess I would have to look at the code and even more use-case samples to make my mind but at first I tend to say that if we could not have to add one more option it would be good. We really want this to be as simple as possible avoiding to have to learn options in particular if they are specific.
History support can only work correctly if $.mobile.hashListeningEnabled = false;
which will prevent jQuery Mobile from handling hash changes. So if using History support is used (and
At this point it looks like I can remove the check for "useParentNodeJqm". Everything seems to be working OK when it is set to false. Earlier I was having some problems with History, but that is understood now as being related to $.mobile.hashListeningEnabled. So I am going to remove the "useParentNodeJqm" option, and the expectation will be that for JQM templates will begin with:
<template class="ui-content" data-role="page">
There seems to be an inconsistency between the way jquery.mobile 1.4.3 and 1.4.2 order pagecontainer events. For 1.4.2 if I call change to change pages, the order I see (which seems to match the docs) is:
pagecontainerbeforetransition
pagecontainertransition
pagecontainershow
With 1.4.3, I am getting pagecontainershow before pagecontainertransition, which is making it harder to process the afterActivate calls before indicating that the transition is complete.
The jquery.mobile support was added with cb84147