Tools:
- JavaScriptObject- any class extending this class will be used by GWT to look into the comments after the class "definition" (usually empty) to determine the javascript specific calls to use. Imagine php tags, but after java classes. That is what this boils down to. Embedding Javascript into Java. In theory the class is able to "compile" and "run", but in practice this looks flaky. There is a reason we moved to MVC and MVP, and minimized the ammount of 'comment managed code'.
- SOYC - "Story of your compile" - allows browsing of the GWT "compile" process. Feels more like a "compile debugger" - shows the process by which the Java classes turn into javascript pages. Extremely important, given the fact that "print(x+y)" will "compile" to "4" in the javascript if the only options of x+y are 2 & 2. This seems extremely efficient (why send x&y over the pipe, when 4 is good enough), but will make debugging a nightmare.
- ImageBundle - define a class as an extension of the imagebundle and annotate @Resources to be included with the bundle to aggregate all of them into one cached image group. Minimizes communication to the client & maximizes client cache hits.
- Can define class specific .css changes with @Define css-var css-val; at the appropriate scope.
- Can define class spericic & browser specific .css changes with @If browserA css-var css-val;
The performance benefits of GWT cant be stressed enough. Client load times showed reduction by 90% - and those client load times couldn't have been reduced in any other way. Troubleshooting looks like a very high learning curve. It seemed to me that typing was thrown out the window with GWT. Perhaps I am wrong. Unless I have to look at wicked optimization, GWT will remain outside of my toolkit.
No comments:
Post a Comment