I'm using Worklight Studio 6.0.0.20130917-1749 in 64 bit Eclipse Juno on OSX Lion.
I'm finding that if I put a call to WL.Client.invokeProcedure(), or even WL.Logger.debug() in a jQueryMobile (1.3.1) pagebeforeshow handler, it causes the design portion of the rich page editor to hang when I try to switch to that page.
$("#myPage").on("pagebeforeshow", function(){WL.Logger.debug("loading myPage...");});
If I double click on myPage in the Mobile Navigation view, the page doesn't display, and I am unable to switch to any other page in the app, or do anything with he design pane. The refresh button doesn't fix it (it just tries to load the same page and I am right back where I started) The only thing I can do is to close the html file and re-open it.
This seems to be caused by a missing definition for WL.StaticAppProperites in the code that is run in the RPE. If I look at the html source of the common resources for the app under chrome I see a definition:
<script>
// Define WL namespace.
var WL = WL ? WL : {};
/**
* WLClient configuration variables.
* Values are injected by the deployer that packs the gadget.
*/
WL.StaticAppProps = {
"APP_DISPLAY_NAME": "MyApp",
"APP_ID": "MyApp",
"APP_SERVICES_URL": "\/MyApp\/apps\/services\/",
"APP_VERSION": "1.0",
"ENVIRONMENT": "preview",
"LOGIN_DISPLAY_TYPE": "popup",
"LOGIN_POPUP_HEIGHT": 610,
"LOGIN_POPUP_WIDTH": 920,
"PREVIEW_ENVIRONMENT": "common",
"WORKLIGHT_PLATFORM_VERSION": "6.0.0",
"WORKLIGHT_ROOT_URL": "\/MyApp\/apps\/services\/api\/MyApp\/common\/"
};</script>
There are similar definitions in the generated HTML for the various environments. But looking in weinre, I see that there is no corresponding script injected into the html that is displayed in the RPE. The lack of a definition for WL.StaticAppProperties is causing the code in worklight.js to fail just before the definition of WL.Utils.
Is there any way for me to add WL.StaticAppProps = {} so that this would come before the code that gets injected to load worklight.js?
Is there any other workaround for this problem?
The editor is defining that WL.StaticAppProps property under-the-covers but it is in an additional injected .js file, not in an inline script block like in the running page. It's possible that the location of that script in the editor's markup is incorrect and we will investigate that.
However there's a larger issue here, which is that a page in the editor is not able to make calls to the Worklight server. Because the editor always needs to operate independently of whether a preview server has been published and started, it uses its own mechanism to load web resources into the Design pane. Therefore the origin server is not the Worklight development server and attempted calls to server-side logic will go unanswered. I believe this is more likely the reason for the hang scenarios you see.
A general recommendation is to use the editor to construct the page's UI markup and then start to wire in service calls after the UI is generally complete. At that point previewing the application should likely shift over to the Mobile Browser Simulator and/or native device testing. In order to continue to do incremental UI work in the editor you can also add some temporary conditional logic to avoid (or mock-up) server calls while doing design work, such as:
var designMode = true; // switch to false for real server preview
if(!designMode) {
// your service invocations here
}