IBM Worklight 6.0.0.1 - Rich Page Editor blocks

Question

Problem - As the project was growing from some point on I cannot use anymore Worklight's Rich Page Editor. It looks as on the picture.

Configuration:

Eclipse Juno EE
Worklight 6.0.0.1

Project details - All pages are packed in the same HTML file. At the moment HTML file contains 6-7 pages in about 1100 lines. Compiling and all the rest works.

screnshot

both answers are correct but i had to choose one... so i looked for solutions of type #ifdef for java script and although it's possible i found out that it's easier (at least for this project) just to kick out all js code from the html file to its own file and in that way control its loading and executing from just one line in the html file. commenting out that line enables me to use rpe, enabling that line enables testing the app — Dark, Nov 01 '13 at 09:40

score 1 · Accepted Answer · answered Oct 31 '13 at 17:56

There should be no problems at all with that page size or number of views, so the appearance is likely tied to recent changes in the application logic itself. In your screenshot the editor has already finished loading the page into the embedded browser (otherwise you would still see a "Loading..." message in the editor's toolbar). The circular icon in the middle does not come from the editor itself but from something in that page or an associated script. In fact it looks a bit like a jQuery Mobile loading indicator to me.

One thing that may be happening here is something in the application's startup code has been added to call out to server-side logic (ex. a Worklight adapter call). Within the editor, the full preview server is not available so generally only the browser-side resources of an application will be functional. This allows you to use the editor for UI design work and then once you start hooking up to server-side features, previewing of the app would typically switch over to the Mobile Browser Simulator (Run As->Preview) or even native browser testing.

The best recommendation is to look for something in your app initialization process that's expecting data back and put in some temporary development-time mockups for such data. As an example, instead of making a service call to retrieve some JSON data just point to a test .json file in your project instead.

score 1 · Answer 2 · edited May 23 '17 at 12:07

Could be related to this: Worklight Studio Rich Page Editor fails of WL.* call in page load

The short answer is that if you put just about any WL.* calls (even WL.Logger.*) in a page loading handler, it causes the Rich Page Editor to lock up.

If the problem is that you are calling backend resources that aren't available, then the normal timeouts and error handling in your code should keep the editor from locking up. You do have timeouts and error handling in your code, right? ;-)

If this problem can't be debugged easily, weinre (http://people.apache.org/~pmuellr/weinre/docs/latest/) works in the Rich Page Editor. You can see what is in the JavaScript console and if there are any exceptions thrown when it locks up.

IBM Worklight 6.0.0.1 - Rich Page Editor blocks

2 Answers2