I am new to GWT and understood the motive behind creating such good framework. However I could not understand how GWT builds the UI and shows while in development mode.
It is said that while bootstrapping .nocache.js file is loaded in the browser, then this file created a hidden iframe. Then depending on browser and language settings a .cache.html file is loaded in the iframe where all application logic resides.
What I could not understand is how gwt does this in development mode/ hosted mode. Because .cache.html files are not available in development mode. I assume that the sdk receives a request from .nocache.js file regarding the browser details and then generates a .cache.html file for that particular browser and that is loaded in the iframe. My question is how .nocache.js file sends a request to sdk to dynamically generate a .cache.html file? Or does it have something to do with hosted.html and the browser plugin? How the UI and RPC code is loaded while in development mode. For nocache.js file to send a request there must be a server program (Servlet) listening to the request and allowing GWt to start looking for entrypoint class and start generating the UI content.
I could not understand how gwt will come to know about the browser settings and generate the UI? Does hosted.html and browser plugin has something to do with the content generation?
I searched using google, but all my trials went useless. Or may be I searched using wrong search keys. Could anyone please tell me or point me to a link where it is clearly explained?
When an application is running in development mode, the Java Virtual Machine (JVM) is actually executing the application code as compiled Java bytecode, using GWT plumbing to connect to a browser window.
As of GWT 2.0, development mode uses a regular browser instead of an embedded browser. You can use any supported browser.
Out of process hosted mode (OOPHM) is an upcoming replacement for GWT hosted mode debugger. OOPHM allows one to use a standard browser (IE, Safari (32bit) and Firefox) for debugging GWT-client-side code.
With OOPHM you can:
do modifications to your widgets with no time consuming Java-to-JavaScript recompilation
set breakpoints to widget code.
use any advanced browser features and extensions not available in conventional hosted mode (Firebug for example).
Useful links:
https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging
http://code.google.com/p/google-web-toolkit/wiki/DesignOOPHM
http://code.google.com/p/google-web-toolkit/wiki/UsingOOPHM
http://www.slideshare.net/allahbaksh/gwt-generators-and-oophm
Have a nice time.
Related
Can we implement the browser plugin to do the automation for sites?
I want to implement an standalone application either a browser plugin or desktop application which can do the automated tasks, basically:
1. Log in to the site
2. Navigate across the pages by filling forms if any.(navigation is not the same for all the use cases)
3. Do the action & download the files to local system.
can we implement this as a browser plugin. Pro's & con's is helpful.
I'm also looking at adobe AIR. Please suggest.
Note: I don't want the users to see what's happening n the browser.
Edit: I want this to be cross platform windows, linux, Mac...
Thanks,
John
I am currently using Selenium IDE, a FireFox plug-in. It is free and pretty easy to use until you get deeper into it's functionality which requires coding (e.g. C#, Javam Ruby and others).
Basic functionalities:
1) Record
2) Playback
3) Assert values
4) Screenshot on failure
5) Setup multiple variables as data source
6) Export a test cases or test suite
7) Yes, it supports use cases and they can be downloaded to playback or imported as test cases
Note on user's visibility to web page activities - the browser has to be opened for this version of tool. There is another version that can automate from a hub or central machine which is able to open multiple browsers or Operating Systems, but, that's just something to keep in mind if you need something more that record and playback page navigation.
Selenium IDE: http://seleniumhq.org/projects/ide/
I wonder if there is a way to perform a step-by-step debugging of the compiled GWT code, in order to determine how some events are being fired.
The interest I have on this is that I'm using SmartGWT, and for some reason the click events on their components propagate to pop up windows that occupy the same position. However this only happens in Mobile Safari.
Even more interesting it only happens with smartGWT version of onClick and not with the plain GWT onClick.
Mostly a hack for now, but I suppose it'll work (you'll have to recompile your app though):
First, compile a recent GWT from trunk: https://developers.google.com/web-toolkit/makinggwtbetter#workingoncode
Then recompile your app with source maps enabled: http://code.google.com/p/google-web-toolkit/wiki/SourceMaps
Follow the steps in the comments of this wiki page to be able to use SourceMaps in Chrome, then re-deploy your app
Get Chrome on the Dev channel: http://www.chromium.org/getting-involved/dev-channel
Use http://www.iwebinspector.com/ to start Mobile Safari with remote debugging and then connect to it from your Chrome desktop: http://www.webkit.org/blog/1620/webkit-remote-debugging/
Finally, enable source maps in Chrome so you'll see your Java code in the Web Inspector!
See http://www.youtube.com/watch?v=-xJl22Kvgjg for a preview of the future of debugging with GWT, that will allow this kind of things in a much less hackish way in the near future.
I don't know if there is a nice way to debug compiled javascript GWT code, but why do you need it?
For described purpose it's better to use GWT development mode with debugging options. You can add the following parametres e-Xdebug -Xrunjdwp:transport=dt_socket,address={PORT},server=y,suspend=n to the development mode running command, it will give an opportunity to add breakpoints to the cliend side GWT/SmardGWT source code. Then for debugging you should connect to port specified in parametres from your java IDE.
Debugging GWT https://developers.google.com/web-toolkit/doc/latest/DevGuideCompilingAndDebugging
I am using eclipse to develop an extjs based application with apache tomcat v6, and it seems to me like that the tool is not the best because sometimes (often) I have to restart the server to view changes in the browser even so I do small changes (js file). If you can advice me which tool is more convenient for Ext-Js (4.x) or tricks for eclipse.
You need to set up a way to disable page caching. You can do this through browser development tools (IE Developer Tools, Firebug, Chrome Development Tools, etc.) or through your server configuration.
In my work, we use a Java class that takes a list of JavaScript/CSS files and appends the request time as a Unix date to prevent the browser from caching. It then inserts the script tags into the page so the output looks like this:
<script type="text/javascript" src="app.js?_cb=20120319123456"></script>
So everything you access a page, the _cb param updates and it gets the new version of the file every time.
If you're already doing something like this and it isn't working, I would recommend switching to NetBeans. That's what I use and it works great.
If you're using MVC - which is brand-new feature of Ext JS 4 - you'll never need to restart or publish changes to application server. It always gets the updated file from file system.
we all agree that when we use GWT, we compile our application on the server, several javascript file are created. Normally, when deploying, we would use the obfuscated mode.
Now modifying a javascript file in obfuscated mode is almost impossible. Now what happens if we want to make some modification in our GWT application.
Do we have to go back again in Java, modify the file, compile, and then deploy again??
I'd say yes... If you use a code generator you should avoid modifying the generated code by hand.
No, no, no.
You don't "go back" to the Java code to modify it. You simply debug, test and modify the Java code. You ignore the code in the compiled javascript files except to deploy it. As far as you are concerned, GWT source code is Java code, not javascript, written within the environmental restriction of the browser.
Your question is like asking, "I have a C application that gets compiled to object code. Do I modify the object code or go back to the C code to modify it?" !!!
You simply treat the generated javascript as "native code".
No doubt you can include javascript using jsni, and so can you include assembly code when using C. So except for those assembly code you inject and similarly except the javascript code you include, you leave the "native code" alone.
When you try to modify the object code generated from C, that is called hacking. Hacking is an interesting hobby but when you wish to create an application and your main task is not "hacking", hacking would only be your extra-curricular activity not connected to your main employment or project.
Go back to the beginning: http://code.google.com/webtoolkit/overview.html
...Write AJAX applications in Java and
then compile the source to highly
optimized JavaScript that runs across
all browsers
When you're ready to deploy, GWT
compiles your Java source code into
optimized, stand-alone JavaScript
files that automatically run on all
major browsers, as well as mobile
browsers for Android and the iPhone.
While debugging: if you are running in development mode you may not even have to redeploy while in dev.
Thanks to the GWT developer plugin,
there's no compiling of code to
JavaScript to view it in the browser.
You can use the same edit-refresh-view
cycle you're used to with JavaScript...
I mean ActiveX is IE only and dead, and so java applets are dead.
Flash is still not present in mobile browsers, Mozilla is present only on 1 phone, so XPCOM is also not an option.
How do you write a plugin that need access to file system, and do some other things, like unzip files, upload, download, etc.
Forget about client side plugins. Most of that can be handled on the server side. Then for anything that really does need a client side implementation you can use Javascript.