To get1.0a3 working on webOS with Phonegap, I would set jQuery.mobile.autoInitialize = false; in a "mobileinit" event handler, and then call jQuery.mobile.initializePage(); and jQuery.mobile.autoInitialize = true; in a "deviceready" event handler. If I did not do this, I would get an error that _trigger() couldn't be called on undefined. This error did not appear on iOS, so apparently it was only an issue with webOS.
In 1.0a4, the relevant lines that supported the autoInitialize option seem to have been removed. They were the following lines:
and the line to set the default:
// automatically initialize first pages or not.
It was an easy fix to copy the lines from 1.0a3 over to 1.0a4 to get things working again, but I'm wondering why this was removed? For all those using webOS, phonegap, and jQuery mobile, this just adds one more modification we need to make to get things working (in addition to the dynamicBaseTag:false workaround) since it was necessary (at least in 1.0a3) to delay initialization until phonegap was ready on webOS.
I'd really like to see the autoinitialize option returned. It's a complete must for my use case.
workaround - http://forum.jquery.com/topic/autoinitialize-option-removed-in-1-0a4
autoinitialize option is very usefull for my app, I'd like it will be back in next version.
We also reverted back to alpha 3 - this is a show stopper for anyone trying to integrate JQM into a larger framework where there is already an established async init flow. Please put the candle back :-)
I am working on a GWT wrapper for JQM (which I release on github once in better shape). autoInitialize is required for this, as GWT /must/ initalize before JQM.
The autoInit feature was removed on Feb 7th by John Bender with the commit "backed out autoInitialize moving to feature request backlog". No reason was given for the removal - was it causing some bug ?
Well I have to say I now use jquery.mobile-1.0a4.1-modified (I hate modifying libraries) :(
Are there any plans about including this the coming beta?
We have plans for handling dynamically generated pages that won't get in the way of C-grade support (in non-JS environments for instance). For the time being, are you able to make your page modifications by binding to the pagebeforecreate event? That should allow you to modify the DOM however you need to before jQM enhances the page...
Thanks for the update. FoOr the mean time I have to resort to modding this code:
$( $.mobile.initializePage );
since there are no jqm pages in the DOM when dom-ready fires in my application. Is there some way I did not understand to bind to pagebeforecreate without a page?
Oh okay. So, currently, there is no supported way to generate the first page dynamically, and I'm not sure we'll ever be able to officially recommend such a workflow, since serving content-free HTML would break the framework's goals of cross-browser/device accessibility, progressive enhancement, etc. That said, we of course have no intentions of actively deterring non-standard ways of using the framework. We'll look into bringing this option back, and I can see it being useful even in cases where the markup is present at load.
For what it's worth, the workflow we've been recommending for dynamically-generated-content apps is to serve real markup in the source for the first page you visit, then create dynamically-generated pages for qualified devices from there. This could allow you to preserve some level of accessibility to all of the browsers and devices we officially claim to support (and even those that we don't). This is definitely an area where we'll be looking to create recommendations and examples in the coming weeks and months.
I'm assigning this to myself to give it a shot.
Scott - thanks for looking into this (and congrats on beta 1!). Is there any workaround for the issue I'm having with webOS and phonegap. Unless I wait to call initializePage() after Phonegap's "deviceready" event, I get the following error: Uncaught TypeError: Cannot call method '_trigger' of undefined, shared/jquery/jquery.mobile-1.0b1.js:2,427
Thanks again for your explanations, and especially for taking this on yourself.
As for your comment that "I'm not sure we'll ever be able to officially recommend such a workflow, since serving content-free HTML would break the framework's goals of cross-browser/device accessibility, progressive enhancement, etc.", I just wanted to emphasize that the use case I am dealing with is one where there is markup present at page-load, it's just not JQM markup. The pages I am dealing with double as JQM/non-JQM web pages, and the JQM part is generated fully dynamically.
I realize that this is not the common case for JQM, and I must say that I am quite in awe of all that JQM is able to do for the use cases it was designed for. It seems very fortunate for me that with the possibility of (opt-in) "manual" control of the commencement of initialization I can harness this amazing power for my use case as well...
Okay, update: I made a new "autoinit-option" branch that implements this feature under the option name "autoInitializePage". Seems to work fine, but I haven't found a good way yet to unit test it. Any help on that would be much appreciated, and otherwise we'll try and get to it on our own as soon as possible. The test will need to go in the "init" suite. Thanks.
updated docs to include autoInitializePage option. Fixes #1391