Child pages
  • Google GWT and Sakai
Skip to end of metadata
Go to start of metadata

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

GwtQuery

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.]

google-gin

GIN (GWT INjection) brings automatic dependency injection to Google Web Toolkit client-side code.

gwt-dnd

Library providing easy to use drag-and-drop capabilities to GWT]

MyGWT/Ext GWT

Rich Internet Application Framework for GWT]

gwt-ext

is a powerful widget library that provides rich widgets like Grid with sort, ...]

gwt-sl

The GWT Server Library is a collection of Java server side components for the GWT ...]

gwittir

Provides a set of code generators, scaffolding, utilities, and a basic MVC framework]

hibernate4gwt

Permits you to use your Hibernate POJO in the GWT client side code]

google-web-toolkit-incubator

A place to share, discuss, and vet speculative GWT features]

gwtx

An extended GWT JRE Emulation Library that picks up where GWT's basic set left off]

The Rocket GWT library/framework

consists of a number of components that can assist developers get more out of GWT. e.g. Comet support, ...]

Project Info

  • Lead(s): Thomas Amsler
  • Description: The Development Discussion Group (DG) is for those interested and involved in the design and development of Sakai. This is the companion wiki space for the sakai-dev email list hosted on Collab's DG: Development (a.k.a. sakai-dev) site. Conference presentations related to this topic can typically be found in the "Building Sakai" track.
  • collab.sakaiproject.org: WG: Google GWT
  • No labels

4 Comments

  1. 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.

      • 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.
      1. 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.


  2. 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?