Google GWT and Sakai
WG: Google GWT
Info
GWT Sakai Projects
Benefits of using GWT
I18N support
Strongly typed language benefits: No JavaScript syntax errors
Tooling support: eclipse, etc.
Debugging support
Unit Testable
Compiled to specific targets: no browser specific code
Cross browser support
Users are familiar seeing/using GWT widgets: Google application suite and many other Web 2.0 apps
Able to use 3rd party libraries via JSNI (JavaScript Native Interface)
Rapid development using GWT tools such GWTShell etc.
3rd party tools for producing WYSIWYG UI
MVC implementation that is very similar to programming in AWT/SWING
"When working with GWT as a developer, it's best to think of it as an analogue to the Java Abstract Windowing Toolkit (AWT). It's the basis for your application framework, not the framework itself."
GWT4Gadgets: Support for iGoogle Gadgets / OpenSocial Apps / Google Mapplets
Offline applications using Google-Gears
Full access to the GData APIs
Supports GWT-RPC, REST, WS, etc. communication to back-end, and or Data-APIs
Can send complex Java types to and from the server. Data gets serialized across network
Accessibility support: ARIA support on FireFox 3+, or FireFox2 with FireVox
Works with Java-Applets and or Flash
Optimizes out redundant metadata from JSON communication to reduce bandwidth cost of client-server communication
Libraries
Name | Description |
|---|---|
is a jQuery-like API written in GWT, which allows GWT to be used in progressive enhancement scenarios where perhaps GWT widgets are too heavyweight.] | |
GIN (GWT INjection) brings automatic dependency injection to Google Web Toolkit client-side code. | |
Library providing easy to use drag-and-drop capabilities to GWT] | |
Rich Internet Application Framework for GWT] | |
is a powerful widget library that provides rich widgets like Grid with sort, ...] | |
The GWT Server Library is a collection of Java server side components for the GWT ...] | |
Provides a set of code generators, scaffolding, utilities, and a basic MVC framework] | |
Permits you to use your Hibernate POJO in the GWT client side code] | |
A place to share, discuss, and vet speculative GWT features] | |
An extended GWT JRE Emulation Library that picks up where GWT's basic set left off] | |
consists of a number of components that can assist developers get more out of GWT. e.g. Comet support, ...] |
Project Info
Lead(s): @Former user (Deleted)
Description:
collab.sakaiproject.org: WG: Google GWT
Comments
About "Applications look like alien inserts in the middle of Sakai, using a look and feel that is subtly different from normal HTML look and feel."
I partially agree with your point of vue,I assume you are speaking about Sakai 2.x : IMHO I don't think it is a matter of GWT that makes "alien" feeling but more to try to adapt Sakai 2.x with a web2.0 look&feel, which IMHO is a normal and good (for end-users) evolution of Sakai (Sakai 3 is the best example)... in Sakai 2 this web2.0 tendance is not new, we have RSF tools like "Page Order tool" for example."Scrolling" issues .. agree but due to a Sakai typic iframe issue. Again, IMHO not sure it is a matter of GWT but more a matter of "HTML Page" view rendering paradigm vs full "Javascript" view rendering paradigm... In Sakai 2, you can have similar issues with any other javascript lib/sdk/frameworks.
"Staff"..."another framework to figure out". Yes a new framework (it is much more a toolkit) to figure out (but closer than a lot think), but IMHO one of the big benefits of GWT is that it allows to improve code maintenance and evolution on bigger to big javascript web application. With GWT, you can make a really good design of your application and debug it, refactor it etc.., with support of many browsers without specific knowledge.
Here are some of the disadvantages of GWT IMHO (to be completed):
compilation time and developing cycle when not using "hosted mode"... in fact not using "hosted mode" is rarely appropriate but it is "natural" as a developer to want to see the result in the your real environment.
not a framework (so, you can do really good things or really bad things) ... but of course you can avoid bad situation, by adopting frameworks and/or architectural best practices thatr exists for GWT.
I definitely agree with Sacha about the compilation time disadvantage. In Gradebook2 we've increasingly tried to get our development mode to work as a full-fledged standalone to allow for more rapid development, but of course this has added additional complexities to the project, and in the end all of the testing needs to be done in production mode. This is a significant issue, but in my mind it's far outweighed by the power of the toolkit in terms of rapidly developing more heavyweight apps on the browser.
IMO, things have definitely improved since GWT 1.7, and continue to improve in GWT 2.0 w.r.t. to development mode. Now that we can use our native browser (Firefox or Safari, for example) to do development mode work, it's greatly reduced the differences between the two modes.
In response to Charles' comment above, I just want to draw attention to the fact that much of what the user sees in Gradebook2 is not actually GWT, but a component library built on top of GWT (called Ext-GWT or GXT). Developing in GWT itself does not constrain your use of normal XHTML or CSS, and it would be possible to mimic exactly the Sakai look-and-feel, if that was desired. In the case of Gradebook2 we found that the requirements we had pushed us to use a richer component library (mostly so we wouldn't have to invent things ourselves and spend a lot of cycles fixing them). This has had some costs, but in hindsight I believe the project itself could not have been completed at the time it was begun without GXT.
Things have shifted a bit in the GWT landscape since then, and depending on the requirements of the tool being built, and I would expect that more and more component libraries will appear to compete with GXT.
I'm having trouble figuring out how to receive the BasicLTI POST parameters when my external tool is first launched. Are there any good resources for this?
Disadvantages of this approach
Applications look like alien inserts in the middle of Sakai, using a look and feel that is subtly different from normal HTML look and feel.
Scrolling occurs within the GWT section of the application, producing double scroll bars and horizontal scrolling. The default seems to be fixed-width panels. Thus the overall application does not resize in the same way that a table-based layout would, increasing the amount of horizontal scrolling.
Staff that need to work on multiple sections of Sakai now have yet another framework to figure out, with little resemblence to anything else. That might be OK if we were moving to this for Sakai 3, but Sakai 3 seems to have its own look at feel based on different tools.
Maybe it's just me, but I prefer the Gradebook UI to the Gradebook 2 UI.