I am using JS Overlay objects in my GWT application. When Debugging the application, I am not able to see the value of Overlay object. Is it a limitation of Using GWT overlay objects.?
Is it because Overlay object is a native Object..? If it is a limitation, Is there any future plan to bring debugging support for Overlay objects in GWT.?
[I am not able to upload images. So typing what I see in the debug window]
> customer= JavaScriptObject$ (id=52)
> hostedmodeReference= JsValusOOPHM (id=183)
> value= BrowserChannel$JsObjectRef (id=188)
refId= 2
GWT version 2.5.1
Overlay types in GWT are a very special beast and are implemented using bytecode rewriting. See https://code.google.com/p/google-web-toolkit/wiki/OverlayTypes for (maybe a bit outdated) details.
As Suresh points out in the comments, there's low-level support for it in GWT but then IDEs have to use it for a seamless integration.
Pending that integration, you can use the utility class directly in the “watch” view (or similar) in your IDE during a debugging session:
com.google.gwt.core.ext.debug.JsoEval.call(MyJso.class, myJso, "myMethod")
This will print the json string from the JavscriptObject.
// Print it to the log
GWT.log(new JSONObject(customer).toString());
// Popup window
Window.alert(new JSONObject(customer).toString());
Related
I'm developing a GWT project at the moment and it's been up and running for a while. New functionality that is to be added require extensive testing, visualizing and simulating of a specific algorithm. I would like to export that specific algorithm so that I may call it directly from JavaScript and do some canvas magic.
How can I export a number of classes for direct use in JavaScript from a GWT project?
I've tried using the GWT exporter, following the Getting Started section closely.
I've noticed that my output directory contains a new generator class (TestClassExporterImpl.java) but the final JavaScript output contains no trace of my TestClass or the exported methods.
I'm sure I've made a mistake somewhere on the way or didn't understand the GWT exporter correctly.
Try to disable obfuscation, it will create the same names in Javascript as in the original Java code
In our Eclipse RCP 3.7 application we have quite a few calls to PlatformUI.isWorkbenchRunning().
For example most of the calls are guards around Workbench API calls, along the lines of
`
if (PlatformUI.isWorkbenchRunning()) {
display = PlatformUI.getWorkbench().getDisplay();
} else {
display = Display.getDefault();
}
We're migrating now to Eclipse RCP 4.4 and I can't find the correct way to replace these calls with RCP 4 compliant code.
I'm guessing I should inject some service / component and use that, but which component? IWorkbench cannot tell me whether it's running or not.
I would expect it to be quite a common problem, but could not find a solution by googling. Anyone solved this already?
e4 does not currently run headless so there isn't really an equivalent.
For access to the Display you can use
Display.getDefault()
everywhere.
If you have a class derived from SWT Control available you can also use Control.getDisplay()
If you want to use the asyncExec or syncExec methods of Display you can use UISynchronize as an alternative:
#Inject
UISynchronize uiSynch;
uiSynch.asyncExec(runnable);
GWT auto generate the JavaScript code.
I could not understand the generated code event mechanism.
for instance, which function run when I click on a button?
I would love to see the javascript that GWT generates for button with explanations
For event handling, GWT attaches a EventListener (generally, your widget) as an expando property (called __listener) of the elements. The events are then all handled by a single dispatch method that looks at the __listener expando of the event's target and dispatches the event to it. Of course, the dispatch method does a bit more (event previewing, entry/finally scheduled commands, etc.)
This dance is (or at least was) required to avoid memory leaks in browsers (mainly IE). You can find more details in the GWT wiki: https://code.google.com/p/google-web-toolkit/wiki/DomEventsAndMemoryLeaks
When you develop in GWT, you don't care about JavaScript.
You should look at the Java code, and search for a function that handles the click event for your button.
When you compile the code Compiler will generate the autoamted Javascript functions ...And that too in compressed (thats depends on your compile type).
It is very hard to find the corresponding function and widget id because those are generated by compiler ..So its better to debug your gwt code is hosted mode ..
Even you want to read the generated code while compiling give the compilation type to
DETAILED, which improves on PRETTY with even more detail (such as very verbose variable names)
Still more details available here .
You should use GWT Compiler options STYLE whenever you need to understand the GWT's output js. GWT by default compresses and obfuscates the javascript output as it uses OBF as default value for STYLE.
To prevent compression and obfuscation you can use PRETTY or DETAILED as the parameter to STYLE argument.
NOTE: You should always use OBF mode for production as it ensures smallest bandwidth usage along with obfuscation.
Reference - https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging#DevGuideCompilerOptions
In GWT web/production mode, Java code is complied into Javascript code that is rendered in the browser.
Also,I have always thought that in GWT development mode, GWT developer plugin compiles my Java code into JavaScript to render it in the browser. But after reading on some site, I came to know that there's no compiling of code to JavaScript to view it in the browser in development mode.
So, I wonder: What are all these widgets I see in the browser during this mode if they aren't JavaScript code?. I don't understand it.
Please help understanding this.
The crux of the Dev Mode is that your code runs in Java. This is a prerequisite if you can use a standard Java debugger. You'll find a high-level overview in the GWT documentation.
The magic happens with JSNI methods and overlay types: when a class is loaded, all its JSNI methods are extracted and their JS body is sent to the browser, ready to be executed (as JavaScript then), and the class is rewritten on the fly to reimplement the JSNI method to make a call to the browser (via the Dev Plugin you installed there and is triggered by ?gwt.codesvr= in the URL) to execute the corresponding JS function. This is the reason why Java objects are seen as opaque handles in JSNI methods; they're assigned a numeric ID to pair the Java object with a dummy JS object on the server-side. A similar though more complex rewriting is done for overlay types, and the same ID mapping is used when JS objects are passed to Java code (as overlay types).
BTW, Super Dev Mode compiles to JavaScript (almost) on the fly.
I'm creating an NPAPI plugin that isn't supposed to have a UI (for use from Javascript only). What windowing model should I use (windowed/windowless/xembed) to support as many browsers (and browser versions) as possible?
I currently implement the following functions:
NPP_SetWindow: do nothing, return NPERR_NO_ERROR
NPP_Event: do nothing, return kNPEventNotHandled (0)
NPP_SetValue: do nothing, return NPERR_NO_ERROR
NPP_GetValue: if asked for NPPVpluginNeedsXEmbed, answer yes if the browser supports it (NPNVSupportsXEmbedBool), no otherwise
For this plugin I am supporting Linux & Windows only for now. The NPPVpluginNeedsXEmbed was necessary for Chrome on Linux (bug 38229), however some old versions may not support it as the MDC page says that the sample plugin for XEmbed is only supported on Firefox 2.0+.
The most common that I have seen is to not care at all about the windowing mode and set the object tag to 1x1 (you can try 0x0, but I've seen browser bugs related to that) size, in which case it doesn't really matter what window mode you use. However, I would do windowless myself since it won't ever cause the trademark block that floats over all other DOM elements that a normal windowed (XEmbed or not) plugin gives you.
This is what FireBreath does if the FB_GUI_DISABLED flag is set.