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