Fowler's GUI Architectures

I re-read Martin Fowler's GUI Architectures article over the past couple of days. It's interesting in that it describes MVC as it was originally conceived for Smalltalk. Fowler describes this and its immediate derivatives very well. However, when he gets to the various flavors of MVP, the tone changes. It almost feels like he got tired of writing the article, which I can understand as I got tired of reading it and had to take it in multiple sittings. However, the lack of thorough illustration of the MVP varieties is a little disappointing after working through the rest of the article.

One thing that he does is describe the various architectures in terms of more fundamental patterns, such as Observer Synchronization, Presentation Model, and Supervising Controller. These seem to me to be the really valuable nuggets of information. You can think of each architecture as a combination of these fundamental patterns such that it fits the programming environment, specifically the capabilities of the source language(s) and runtime.

This is where the later applications of these UI architectures breaks down -- the UI architectures were designed specifically for the programming environment. It is unlikely that when you change some aspect of the programming environment, such as the source language, that the same UI architecture will be optimal. It is inevitable that some of the constituent patterns will be modified, substituted, or removed.

From here, I need to read more detail about the patterns and explore some of the further reading. Then, I can truly evaluate UI frameworks, not for the architecture that they claim to follow but for which patterns they use and well they fit in the environment that I'm working in.

Frustration with GWT 2.2 Upgrade

First, I'll admit that, as a developer on an open-source utility for GWT (gwt-multipage), I probably should have tried out the builds of GWT 2.2 before the final release. However, I'm to not the only one who wasn't prepared.

Many people seem to be struggling with upgrading their applications to GWT 2.2. A common theme seems to be when the application uses a code generator, either directly in the application or indirectly by making use of something like GIN. It seems that GWT 2.2 introduces a binary incompatibility with code generators by changing some classes to interfaces. Therefore, when upgrading the GWT jars to 2.2, you also have to upgrade the jars of any libraries that use code generators to versions that have been compiled against 2.2.

I mentioned that I'm the only one who wasn't prepared. GIN, a project maintained by Google employees, does not have a build ready. They even seem to still be debating how to manage the releases to provide compatibility with GWT <= 2.1.1 and >= 2.2. The google maps API jar, part of the gwt-google-apis project, is also affected.

That's what I know so far about the problem. I'll try to post what I know about the solution once I get a chance to experiment with it some more.

Running a Simple Ext GWT Application

Now that the holidays are over, I'm finally getting started with Ext GWT 2.0 Beginners Guide. I got the initial sample application running, but it took a little bit of doing.

For starters, I'm using IntelliJ IDEA (on Mac OS X 10.5, for the record), not Eclipse as suggested by the book. This wasn't too much of a problem. I only had to know how to:

• set up the GWT SDK
• add a global library for GXT
• create a GWT project

Having the GXT library set up, I did not need to copy gxt.jar into war/WEB-INF/lib, and frankly I'm surprised that this is necessary in Eclipse; I may have to try that myself. I did, however, have to copy the GXT resources into my project as the book suggested. This also surprised me, but that's not the fault of the book. I'll have to check the official Ext GWT documentation to see if they take the same approach.

Finally, I thought I had everything set up and fired up development mode. When running the GXT version, it would crash with the error:

Invalid memory access of location 0x8 eip=0x4245eb

I switched back to the original non-GXT entry point and it worked fine. I finally realized that the one other difference in my project was that I had forgotten to change the Java SDK to 1.6. To be fair, the book says to use Java 6. I just didn't realize that it wouldn't work with Java 5.

What's the moral of this story? I'm not sure. I'm just glad it only took me 30 minutes to figure out, which I think is pretty fortunate given the obscurity of the error message.

Ext GWT 2.0 Book

I've been asked to take a look at and review Ext GWT 2.0: Beginners Guide. I haven't personally used Ext GWT. Though the widgets look a little MS-Windowsy, it does appear to have some nice features. I've mostly avoided it because I've heard that it doesn't work well with GWT 2.0's UiBinder and bundled widgets. However, some of my co-workers are using Ext GWT, so I should probably learn about it anyway. Plus, I've read that Ext GWT 3.0 will be reworked to solve some of those problems.

I'll post my impressions of this book soon. In the mean time, maybe this will give me some incentive to post some of my other experiences with GWT as well.

Design Patterns and Class Names

In a meeting yesterday, I said something along the lines of, "when applying design patterns, if you use the name of the pattern in class names, you're doing it wrong." It's a statement that I don't really believe, but it crossed my mind a while back, got stuck there, and then came out of my mouth before I'd taken the time to understand my thinking.

When I first start using a design pattern, using the name in code is comforting. It acts as a reminder and helps me navigate the code.

Sometimes, I later realize that I haven't applied the pattern correctly or that it doesn't apply to the context as well as I originally thought. I look at my code and feel like it's misleading, or that I'm trying to use a pattern just for the sake of using a pattern. At that point, I develop a distaste for the pattern name. I'd rather the classes not say anything about design patterns and simply speak for themselves, letting the reader draw conclusions about whether or not a pattern is being used.

Eventually, I gain enough experience with the pattern to feel comfortable knowing how and when to use it, at which point I may choose to use the name in code as a form of documentation.

The specific pattern I had in mind yesterday was Model-View-Presenter applied to GWT applications as described in Ray Ryan's Google I/O 2009 "Best Practices" talk. It is presented (no pun intended) as a way to separate code to make it more testable and for those tests to run faster. I believe in this goal, but I learned about and first applied the pattern before ever feeling what it's like to write tests for a non-MVP application. I'm currently going through that exercise in an attempt to streamline the application of MVP (or some other pattern) to best meet our testing needs without being too cumbersome. I am quite squarely in that middle ground right now with respect to MVP, which is why I said what I said.

To further complicate the issue, I've been reading that presentations at Google I/O 2010 talked about a framework coming, likely in the 2.1 release, that uses the word "activity" when describing the classes that fill the presenter role. I haven't looked at the details yet, but I'm curious to find out if Google themselves are in that middle ground with respect to MVP or if it's more similar to interface/implementation naming decisions (which is a topic for another day).