GWT Pros and Cons

Pros:

• no need to learn JavaScript (yay!)
• you get the fast productivity of Java => resulting in a faster and more optimized JavaScript than what you would have written by hand
  
• no need to worry about browser quirks
• using statically typed language (Java) to develop the client-side of the app allows to catch various problems even before the code is compiled (tools, IDEs, static analysis tools are available)
• debugging tools like any other Java app (can set breakpoints and debug the app in hosted mode)
• sharing the same language between the client and server (ability to use a shared Java package)
• hosted mode (you can make changes in Java on the fly and just hit "refresh" in the hosted mode browser)
• generics in GWT 1.5 (better static type checking on the client part of the app)
• DOM abstraction => code in one language and compile properly for any browser
• history support
• open source => many free widgets

Cons:

• only a subset of JRE available to use on the client side (translatable to JavaScript using GWT compiler)
• the concept of modules can get very confusing
• web indexing of Javascript is difficult, often developers need to create a HTML-only version of the app just to allow search engines to index it => hard to maintain, pain to write
• hard to the use a wider range of browsers for testing
• can not edit CSS while in hosted mode
• does not offer RPC mechanism using Comet

Binding the Model to the View in GWT

When you start creating a simple GWT widget, it is very tempting to keep all UI elements (view), the data (model), and the logic that manipulates the view and model (controller) in one place. When your app gets bigger, you end up creating a spaghetti code, especially when you want make an event to cause an update in a widget defined in another class. To untangle the mess, split the code into three logically separate parts: Model, View, and Controller.

To bind the data to the view:
The best solution is to register a ChangeListener in the Model and notify the View on change (this is what MVC pattern does). Ideally, you would split the code associated with a Widget into three separate classes. One would be a Controller, one a Model, and one a View.

• The Model (the Observable) does not have any reference to the Controller or the View
• The Controller has a reference to Model
  
• The View has a reference to the Model (is able to add listeners to it) and the Controller
  

So what does View do?

• It registers listeners with a Model, allowing the Model to fire onChange() events which the View can use to update itself.
• It registers various listeners on its UI elements (ClickListener for a Button, etc) and defines the onClick() or such methods, where the calls to controller are made.
• When the user clicks on an UI element, the controller method is called and performs the necessary computation and/or updates the model.

What does Controller do?

• Exposes various public methods that perform computations and manipulate the data in a Model
• Controller does not update the View directly. It updates the Model which View listens to.

What does Model do?

• Allows to register change listeners via addChangeListener()
  
• It contains the state of the data, and fires the onChange events when Controller calls its setter methods
  

This decoupling of the model, view, and controller allows better reusability of code, as well as testability. You do not need to extend (the painfully slow to use) GwtTestCase to test the code in Model or Controller. You simply extend the junit.framework.TestCase and you can use any Java library, not only those supported by GWT.

Design Patterns and GWT

I discovered this amazing article about the use of MVC in GWT. It is the best GWT article I have read in the past few months. It shows a practical example (Calculator widget) using MVC with Observer and Strategy patterns. I immediately ordered the book "GWT IN PRACTICE" and can not wait to read it in the shuttle during my long commute to work.

Portraits

I had a little portrait lesson with Bill and Laura yesterday. Brad and Polina posed, and the results were pretty good. We first tried Rembrandt Light, then soft light on Polina, and hard light on Brad. We used four strobes: two from the front, one for the top of the hair, and one for the backdrop. I still do not get the theory behind this all, but I am getting there. I finally understand the meaning on the inverse square law and the square root of 2 used when computing the distance between stops. It is pretty simple when you get it. But at first you just wonder why the hell they are talking about square roots when they talk about light.

Waiting For the Golden Gate Bridge

Bill and I decided to go shooting Golden Gate Bridge at night. Sunset was at 7:29pm, and we made sure we were at the Baker Beach on time. The bridge is a beauty, it has many faces, and strikes a different pose each time you trigger the shutter. Weather in San Francisco can not be summarized in one sentence. Each neighborhood has its own micro-climate which dramatically changes during the day. As the sunset approached, Baker Beach turned into a cold windy place. We climbed over some boulders, walked through one of the beaches, and settled our tripods at a nice spot with a great view at the bridge. The pictures were well worth the frozen asses we had towards end of the photo trip.