Executive Summary: With all of our experience in Microsoft technologies, why did we choose Google Web Toolkit over other technologies for our start-up?

Almost six months ago, I described my initial reaction to Java coming from ten years in the Microsoft world. At the time, I tastefully glossed over the reason we ended up using Java, or more specifically, Google Web Toolkit saving the discussion for a time when all I really wanted to do was make sure there were no gaps in the list of months in my Archive. Plus the original post inspired would-be blog-reviewer, Dinesh Gajjar, to comment on the lack of content, a position that leads me to believe he’d only recently started reading my blog. In any case, one of his concerns was that I didn’t explain “why I chose what” which I will assume means “why I chose GWT” (and apologies, Dinesh, if by “what”, you really meant “to waste time that could be spent writing comments on other people’s blogs”).

When first deciding on how to proceed, our default was .NET, which led to some obvious options. MVC seemed a no-brainer and since I was involved in Sharp Architecture, my first reaction before we even finished the conversation was to run the Sharp project template. “But,” says we, “we’re pragmatic programmers. Why do we automatically reach for .NET? This is *our* project!”

Thus explains why my resume says I have two days of experience with Ruby. I played with it for (almost) that long before we changed our minds again. As we discussed the nature of the application, we discovered it would rely *very* heavily on JavaScript. So we wanted something that would facilitate that.

At the time, we were also a little apprehensive about the learning curve with Ruby. Not that we wanted to shy away from it. But this wasn’t some fictitious client’s money we were playing with. It was hours. “Learning on the client’s dime” had a more ominous effect when the client’s dime was my dime.

So we ventured back to .NET being familiar territory and telling ourselves “it’ll help us get this out the door faster.” We also looked seriously at OpenRasta because it seemed to facilitate our view of having the server serve up resources rather than the default view of serving up pages. Our intent was to have a single page and dynamically modify the various pieces view JavaScript. We weren’t looking forward to managing history support for something like that but we felt it offered the best user experience, which is more important than our nagging little technical problems.

One nagging aspect to this approach was testing the JavaScript, something I had little experience with. I did some smoke tests with WatiN and was encouraged a little but it always felt a little uncomfortable, especially trying to run the tests on a CI server. And both my partner and I (admittedly, he more than I) were concerned about the costs of long-term maintainability and were pretty adamant on making the app testable and following a strong focus on quality while we built it. WatiN didn’t give us that warm fuzzy feeling and I don’t believe we looked at Selenium at the time.

Around this time, my partner discovered Google Web Toolkit which looked tailor-made for the type of application we wanted to build: A single page with various pieces updated based on user clicks. And you could write it all in Java, which was easily testable. And better yet, it had history support built in.

So we both did smoke tests and decided it was the way to go. To summarize, it gave us (in order of importance):

• an AJAX application with a good user experience
• history support (also important for user experience)
• easily tested
• strong community and many resources

In retrospect, it seems there is a fine line between “pragmatic” and “indecisive”. There’s a good chance that not all of our decisions were the right ones, just the ones we made at the time with the information available to us. As I reflect on it, maybe we dismissed Ruby too soon. Or maybe we could have built the app faster in .NET and still made it maintainable. Or maybe or maybe or maybe…

Truth be told, writing this post is about all the reflecting I’ve done on it. Because I have no regrets using GWT whatsoever. It’s lived up to its promise. Yes, we’ve run into issues but none that have been insurmountable and certainly no more than we would with .NET (can’t speak for Ruby).

More importantly, it’s because we use Java/GWT that we have the team that we do and, with all due respect to the awesome team I worked with on my first Livelink project a couple of years ago, it is by far the best team I’ve been in in my twelve years of consulting. And this from a guy who gets along with everyone (almost).

Kyle the Indefinite

We’ve hired two new developers to our team, effectively tripling our development staff. So I’m celebrating the alleviation on my workload with some posts that are essentially going to be documentation for the junior developer. I hope she has a sense of humour when it comes to sample code as she reads this…

I’ve long forgotten what the traditional method is for making RPC requests between the client and server in GWT applications. In a traditional web application, that’s what XMLHTTPRequest was for until jQuery et al came out and was nice enough to make it readable. For GWT applications, the calls are called RPC requests which I think is just a fancy name for “our proprietary JSON format” based on what I’m seeing in Firebug*. I have a vague recollection of having to register URLs for every single type of request you wanted to make to the server.

In our case, we’re using gwt-platform which contains a built-in dispatcher for managing calls to the server, all filtered through a single URL. The implementation is based heavily on gwt-dispatch with some minor tweaks. (Side note: Not only are we using gwt-platform, we’ve hired the guy who built it. In his spare time, he builds 3D physics-based animation frameworks.)

How it works is like so:

• Client code gets an instance of a DispatchAsync object (almost always using dependency injection)
• Client executes a command on the dispatcher, registering a callback function
• Server receives the command, processes it with a handler, then returns a result
• Callback function executes using the result from the server

That’s all well and good and the description satisfies my “why use regular language when developer-speak will do?” gland. Now let’s try again a little less like I’m trying to compensate for something:

1. Even though they are in the same project, you still need to think of the application in three pieces: a client, a server, and objects that travel back and forth between them
2. When you’re working in the client, you’ll need to communicate to the server to do one of two things: get data to display, or process data for storing.
3. When you do need to communicate with the server, you instantiate an object called a command or action. This can be confusing at first because it’s an object that doesn’t really represent a “thing”. Rather it represents a verb (aka. an action). Examples: GetClientList, SaveOrder, FindSuitableMate. These actions contain all the data the server will need to process it. For example, FindSuitableMateFromFamilyTree may contain properties for the various search criteria, like HairColour and MinimumAge and NumberOfUndisputedSharedRelatives.
4. This action instance is sent to the server through an object called a dispatcher (think: Danny Devito’s character on Taxi, but more pleasant). Because the call is made asynchronously, we need to tell the dispatcher what to do when the server responds. So we give it a function to call when it’s done. The function will take a parameter that is provided by the server. It is typically named the same as the action with Result appended to it. E.g. GetClientListResult, SaveOrderResult, FindSuitableMateResult.
5. On the server, we have a handler for each action that we could potentially receive. A handler is an object that does all the heavy lifting for a particular action. For example, FindSuitableMateHandler would react to a FindSuitableMate action. It would examine the command and perform a search of the database based on the criteria provided in the FindSuitableMate object it received.
6. After the handler executes, it creates an appropriate result object. In our above example, FindSuitableMateHandler would create a FindSuitableMateResult object and set one of its properties, e.g. SearchResults, to the list of found items from the database.
7. The callback function we created in step 4 gets executed using the result object created by the server. Typically, this will do client-y type stuff like update a list of items on a page or display a message to the user.

That’s the crux of the RPC mechanism in GWT as I see it. I’ve skimmed over much of the details, like how handlers are registered. But this post is about two weeks overdue as it is.

Kyle the Commanded

* By “Firebug” I actually mean Chrome developer extensions but despite the fact that I’ve moved off Firefox, Firebug just sounds cooler.

Before I get started, I should point out I may have a shaky definition of the term “multitenancy”. I haven’t exactly studied up on it but I’ve skimmed some blog posts and I hope it means what I think it means.

In our Google Web Toolkit application, we’re going to have multiple clients but only a single instance of the app and only a single data store. Multiple instances of the application and the data store aren’t feasible as we are deploying to Google App Engine. That makes it sound like Google App Engine dictated the solution but it was more of an “icing on the cake” thing. Even if we were doing it in SQL, we were going to do it in one database. I think one reason was to make it easier to aggregate data but I hope there were more reasons because that one is kind of lame. After all, we could aggregate all the data we want into a separate database for reporting purposes.

We’d like decent URLs as well, like http://wholesaleroadkill.com/store/clients/crittersnstuff and http://wholesaleroadkill.com/store/clients/macysHairSalon. This isn’t as easy as it sounds in GWT because the default behaviour is to load the app and manage all transitions as AJAX calls. If you need to bookmark something, it’s done with a hash tag. Some examples:

• http://wholesaleroadkill.com/#clientList
• http://wholesaleroadkill.com/#inventory
• http://wholesaleroadkill.com/#category;mammal

I like to compare the type of applications you build in GWT to GMail. Once you hit the home page, you stay there. There isn’t really the concept of navigating to a new page, just refreshing sections of the existing page.

Furthermore, GMail supports multi-tenancy to some degree. If you use Google Apps For Your Domain, your home email URL is http://mail.google.com/a/wholesaleroadkill.com. After that, navigation is done the traditional way (e.g. #sent, #drafts/123123123, #inbox, etc.)

Problem is, as far as I know, GMail isn’t a GWT app. And even if it is, it’s not open source so how they configure it to be a multi-tenant application is for me to find out.

I’m told that multi-tenancy is on the radar for GWT but the radar sounds pretty big so I’m not holding out hope. So I did find out *a* way to achieve what I want, through modifications to the web.xml config file.

By default, the home page for your GWT application is <appName>.html. It’s a physical HTML file located in the war folder. It contains everything needed to load the JavaScript that powers the app. In ordered to set up the URLs, I modified web.xml to redirect requests to this file, like so:

<web-app>

  <!-- other stuff -->  
	<servlet>
		<servlet-name>Multitenant</servlet-name>
		<jsp-file>/myapp.jsp</jsp-file>
	</servlet>
	
	<servlet-mapping>
		<servlet-name>Multitenant</servlet-name>
		<url-pattern>/myapp/customer/*</url-pattern>
	</servlet-mapping>

</web-app>

With this in place, I can navigate to /myapp/customer/freddystaxidermy and /myapp/customer/thelmasgunemporium and have it serve up myapp.jsp. MyApp.jsp is almost an exact duplicate of MyApp.htm with one change I’ll get to later.

There are some considerations to this approach that I don’t know I’ve thought through completely. The big one is security. Every call needs to be qualified somehow to indicate which customer is making it. I.e. which URL launched the request. For the moment, I’m doing that by making a call in the main page that sets a session variable based on the URL. This kinda reeks of being very open to allowing someone smarter than I am to make a call with a fake URL and impersonating someone else. At the moment, that’s still a pending todo.

Back to the change I made to MyApp.jsp. We had a relative reference to our CSS stylesheet:

<link type="text/css" 
   rel="stylesheet" 
   href="myApp.css">

This doesn’t work because it’s now looking for myApp.css in the wrong place so I changed this line to:

<link type="text/css" 
   rel="stylesheet" 
   href="<%=request.getContextPath( ) 
   %>/myApp.css">

Now it properly references myApp.css at the proper level of the application.

This brings up an interesting aspect to this set up. There are still certain things, like myApp.css, that are accessed globally. We are using gwt-platform, which uses a modified version of gwt-dispatch for server-communication. All requests are routed through http://wholesaleroadkill.com/myapp/dispatch regardless of where it originated. I’m sure it can be configured so that requests are routed through http://wholesaleroadkill.com/myapp/customer/freddystaxidermy/dispatch but that hasn’t crept high enough on our priority list yet.

Note: I’ve had this post ready to go for a few weeks now. Typing it out made it sound more hacky than it did when I figured it out in the first place. So consider this an appeal for alternatives or tweaks.

Kyle the Let

Still heads down in start-up mode with GWT these days, which sounds more glamorous than it is in practice. That said, we’re looking for a junior Java developer and a Web Marketing Assistant so send on your details if you’re interested. I’d suggest reading the rest of this post first though…

This week, the progress report to my boss essentially read:

The app has now returned to the same state it was at a week ago. But it now uses a new architecture that sure makes me feel all warm and fuzzy.

This isn’t as clandestine as I make it out to be. We had a chat on Sunday after I’d spent a few hours prototyping the new architecture and had a brief bout of conscience wondering if switching things so drastically was just a way to satisfy some primal developer itch. I mean, in a company of 10,000 people, it’s easier to justify in many cases. Especially if the company has a tendency to swap out CMS products semi-annually. That, to me, says “we need to spend our budget on something this year or we won’t get it again next year.” But on a project of this scale, architectural changes cost much more relative to the income they generate, which at this stage is nothing.

During that chat, I made some estimates on how long it would take to revamp things. Optimistic estimate was two days, pessimistic/realistic one: five days. I hit the pessimistic one more closely than the optimistic one but frankly, I’m just glad the estimate fell in between the two.

Based on that, my cohort essentially said it would be stupid not to do it. We are early enough into the project that the long-term payoff will be substantial. Five days of work does indeed sound like it would be easy to make up over the lifetime of the application.

But there are other considerations than just plain time. The libraries I was replacing are gwt-dispatch and gwt-presenter. Both relatively proven, actively developed, and by all accounts, very good at what they do. Based on my own limited experience, I was very happy with both.

The replacement is gwt-platform, which by contrast, had its first check-in on March 3. When I joined the discussion group, I became member number 9. So there’s some risk involved with such a fundamental shift to a fairly unproven library. Another consideration: although gwt-platform has some nice features to it, there’s a very real possibility that they’ll be implemented in some form in gwt-dispatch and gwt-presenter.

And I wasn’t even looking to change. I effectively stumbled on to the library while checking up on Andreas Borglin’s adventures in GWT and he has yet to steer me wrong.

So the question remained: do we take the risk of switching to a new library with a more uncertain future for the sake of easing our development now?

In the end, we decided yes, we would. Because the risk doesn’t seem all that great, really. It’s an open source project. And not one like NHibernate where if it went belly-up, you’d be scared to navigate the code (and if you’re not, then this post isn’t aimed at you). The product is still fairly small and according to the upcoming features page, plans to stay that way.

My partner put it best during our discussion: “don’t be afraid to rip things out and start over if there is real business value.” But as a developer, I’m very much aware of my personal bias so it’s often hard for me to judge “business value”. Especially in this case where I wasn’t altogether unhappy with the existing products and there was an element of “Ooooh, Shiny!” to the decision.

The nice thing in this case was that the project is in its infancy and a major upheaval of this sort is only a week’s worth of effort. Not totally insignificant but still within the realm of justifiable spike, even for a start-up. In fact, it’s because we’re a start-up that I think the decision to switch was so easy. Trading uncertain future for present development time? That means “possibility of having to look at code we didn’t write” vs. “saving a trailerful of money”.

Besides which, after scanning the library and the corresponding sample project, it includes solutions to quite a few issues I had been ignoring until I had time to revisit them:

• Lazy loading presenters
• Code splitting
• Resource (i.e. CSS, images) management
• Internationalization
• Ability to use nested presenters, especially with UI Binder

So between making things easier going forward and solving problems I had not even thought about yet, it certainly warranted an evaluation. And after spending a week with the framework, it has proven itself extremely valuable in crystallizing a number of concepts I was having trouble with. Many kudos to Philippe Beaudoin for his effort in that alone.

Kyle the Upheaved

Google Web Toolkit has proven an interesting beast to code with. It’s not every web framework that encourages you to use passive view so strongly. That’s thanks partially to gwt-presenter which makes it pretty easy for views to be stupid. In most cases, the presenter even handles wiring up event handlers for the widgets.

Here’s a small excerpt of a view:

public class LiquorStoreListView extends Composite implements LiquorStoreListDisplay {

   Anchor addStore = new Anchor( "add store" );

   public LiquorStoreListView( ) {
      FlowPanel panel = new FlowPanel( );
      panel.add( addStore );

      initWidget( panel );
   }

   public HasClickHandlers getAddStore( ) {
      return addStore;
   }
}

This is missing a bunch of extraneous stuff as is the presenter below:

public class LiquorStoreListPresenter extends WidgetPresenter {

   LiquorStoreListDisplay display;
   EventBus eventBus;

   @Inject
   public LiquorStoreListPresenter( LiquorStoreListDisplay display, EventBus eventBus ) {
      this.display = display;
      this.eventBus = eventBus;
      bind( );
   }

   @Override
   public void onBind( ) {
      display.getAddStore( ).addClickHandler( new ClickHandler( ) {
         public void onClick( ClickEvent event ) {
            Window.alert( "Adding a new store" );
         }
      } );
   }
}

The magic is in the use of interfaces for the widgets. In this case, the Anchor widget implements HasClickHandlers which means the presenter doesn't need to know anything about the widget except that it implements a method, addClickHandler.

This falls apart a little when you have more dynamic user interfaces though. For example, what if each liquor store in our list contains an edit and delete button? Maybe we can expose them as a couple of ArrayList objects, I suppose. But that leads to much madness. And by "madness", I mean the angry kind, which isn't nearly as fun as the crazy kind where you're allowed more latitude at the daily stand-ups.

The reason exposing the edit and delete buttons as an ArrayList to the presenter is icky is because you need to figure out which row was selected. Which leads to some pretty funky implementations, some of which require you to maintain a separate list of click handlers and/or domain objects on the presenter which need to be kept in sync with the view.

Instead, I've started delegating a tiny bit more responsibility to the view. That is, it will wire up the click handlers which in turn, fire off custom events that have more useful data in them.

Here's a sample method in the view:

public void addLiquorStore( LiquorStore store ) {
   int lastRow = storeTable.getRowCount( );
   storeTable.setText( lastRow, 0, store.Name );
   storeTable.setText( lastRow, 1, store.Address );
   Anchor edit = new Anchor( "edit" );
   edit.addClickHandler( new EditStoreClickHandler( store ) );

   private class EditStoreClickHandler implements ClickHandler {

      LiquorStore store;
   
      public EditStoreClickHandler( LiquorStore store ) {
         this.store = store;
      }

      public void onClick( ClickEvent event ) {
         eventBus.fireEvent( new EditStoreEvent( store ) );
      }
   }
}

Then in the presenter:

public void onBind( ) {
   // ...

   eventBus.addHandler( EditStoreEvent.TYPE, new EditStoreEventHandler( ) {
      public void onEditStore( EditStoreEvent event ) {
         LiquorStore store = event.getStore( );
         // Get the store data and display it
      }
   } );
}

May seem like more work but I like the separation a little better. Alternative is to store the store ID in a hidden field and do some DOM manipulation to get it. But I always feel dirty if I have to do that in GWT.

Kyle the Impassive

I didn’t necessarily mean to piggyback off Greg’s two posts on ORMs but c’mon, what’s a hillbilly to do when he perpetuates such negative stereotypes? I mean, before you start knocking it, have any of you *tried* kissing your sister?

He also has some blather in there on RDMSs and ORMs. So I suppose I should hide my indignation behind something technical.

We’re using BigTable for our project by way of Google App Engine. The decision to use it was pretty easy once we landed on GWT as our platform. The integration ‘twixt GWT and App Engine is pretty seamless and hey, App Engine uses Big Table.

I’m glossing over the dozens of times we’ve second-guessed ourselves since making the decision though. The most recent was just yesterday as a matter of fact when my friend expressed a couple of concerns:

• How do we back it up?
• How do we do ad hoc reports against it?

Over the course of the conversation, these boiled down to: How can we work with BigTable in a way we’re used to with RDMSs?

The inevitable option came up. Maybe we shouldn’t use BigTable. Maybe MySQL is more suitable if we’re unsure. That means moving off App Engine though and we like what we’ve seen so far with it.

It was a bit of an uncomfortable conversation actually and this was between two very seasoned developers who have never shied away from new tech. I think the reason for the awkwardness though is that we aren’t dealing with someone else’s money. This is a startup so it’s a decision that he and I are going to have to live with.

In the end, being seasoned developers, we recognized that moving to a new development platform will just substitute one set of problems with another. For basic transactions (I hesitate to say OLTP because that will imply I know more about the term than I do), like getting some objects and saving them again, BigTable just plain works. There’s no ORM behind the scenes to map your data structure to the domain model. You create a User and you save it. Any relationships are automatically dealt with by some magic that is buried in the documentation somewhere, I’m sure. It really is like working with an ORM without actually having to deal with the mapping.

As for our two questions above, we have a tentative solution that I still like a day later and it will solve both problems. Let’s take the second one:

How do we do ad hoc reports against it?

See this is where RDMSs shine, I think. So breaking down the question we get: How can we get the benefits of BigTable for transactional stuff and the benefits of RDMSs for reporting and ad hoc querying?

Funny how CQRS starts to make sense when you have the right problem staring you in the face. We’ll have a separate relational database for querying. As requests are sent to BigTable, we’ll also dump them out to another service elsewhere that queues them up to be processed into the relational database.

This also addresses our first question:

How do we back it up?

The nice thing about this approach is that we now have our offline backup though of course, backing up is only half the solution. We also need some way to restore BigTable from our relational database easily. But the idea seems sound enough even if the mechanics may prove otherwise.

Maybe this sounds unduly complicated. It really doesn’t to me. App Engine and BigTable offer a lot of advantages. They solve problems I don’t want to deal with, most notably, scalability. The ones they introduce, backing up and querying, by contrast, are pretty simple. Besides which, I’m scheduled for Udi’s course in a couple of months anyway.

And for the record, I don’t have any sisters. Just three adventurous brothers.

Kyle the Restored

Almost three years ago to the day, I concluded a post with this:

I hate security and all software and hardware related to it, including but not limited to: anti-virus, spam, phishing, SSL, permissions, LDAP, NTLM, forms authentication, SecurID tokens, VPNs, swipe cards, PIN numbers, security deposits, car alarms, bike locks, and cell phones for seven-year-olds.I don't like that the major upgrade to Windows XP was a firewall that broke a bunch of apps. And that among IE7's features is not to let me into websites because I'm not smart enough to figure out if they're dangerous. And that Vista's main differentiation from XP is that it's harder to play my music. I will concede, however, that retinal scanners are pretty cool.

Now, three years later and my position has changed slightly in that now I also don’t like OAuth, RSA, salts, Kerberos, MD5, SHA, IPSec, OpenID, HTTP sessions, cookies, cross-site request forgery, fingerprint scanners, parental controls, deadbolts, my mother’s maiden name, my favorite pet, the name of my elementary school, and “forgot my password” links that all but announce my password on Twitter. Again, though, retinal scanners rock.

With that background, today’s topic is authentication with Google Web Toolkit.

In the .NET world, I had my head somewhat wrapped around authentication. Or rather, I knew which code to cut and paste from previous apps to make it work in new ones. But having thrown myself headlong into GWT, I’ve had to actually research the concepts. A little.

With an AJAX application like one built with GWT, there are actually two scenarios that require authentication:

• Navigating to a page
• Performing an action on a page

Navigation has traditionally been fairly easy for me to work out. You fiddle with the web.config, add a login page, toss around a FormsAuthenticationTicket or two and call it a day. With GWT, this needs to be done via gwt-presenter. But I’ll leave it at that for now because I haven’t actually got around to doing that part of the authentication yet.

Instead, I’ll focus on the second item: performing an action on a page. In GWT, I’m using gwt-dispatch, a command pattern implementation. It’s nice in that it provides a centralized interface for making RPC calls ‘twixt client and server. Nicer still is the latest version on the trunk which includes support for securing these calls.

As David Peterson points out in this thread, there isn’t much you need to do in order to add security to your command calls. That said, it isn’t altogether obvious to a Java greenhorn how to implement it. So forthwith are my current thoughts in as plain English as I can realistically make it.

The main issue I had when researching all this is that it seemed fairly academic. There is talk of sessions and session IDs and I couldn’t make the leap from that discussion to what I really wanted: to log in to the application. As I lamented on the OpenRasta forum, I can get a username and password from the screen, validate it against a database, and create a random session ID. What happens after that is still a little foggy.

So here is the workflow as I see it now:

• User enters username and password and clicks submit
• Login command is created and sent/dispatched to its appropriate handler on the server
• LoginHandler validates the user, creates a user object, and dumps it into the HTTP Session
• Server also creates a random session ID and dumps it into an appropriately-named cookie.
• Server returns login success

Next, the user performs some action that requires authentication:

• Client creates an appropriate command and sends it to the server
• The session ID is attached to the command and sent to the server
• The server checks to see if the action being performed requires authentication.
• If not, it executes the action
• If so, it checks to see if a user has been added to the session. It also verifies that the session ID it received matches the one it generated earlier (by also checking the cookies)
• If the checks fail, throw an InvalidSessionException. Otherwise, execute the action.
• Back on the client, we use a custom AsyncCallback class that specifically checks for InvalidSessionException. If it catches one, we raise a Logout event which is configured elsewhere to redirect to the login page.

The session ID check seems kind of superfluous on the surface. But from what I gather, it’s necessary to prevent cross-site request forgery attacks. As far as I can tell, it’s not used for any other purpose.

The vast majority of this is taken from various sources and I hope I remember them all. First is the Hupa, a web mail app written in GWT. Much assistance has come from the guy behind this site, which is shaping up to be one of the best tutorials I’ve seen in either Java or .NET. A good chunk of the explanation is from this post and I should note that most of the code in it has been incorporated into gwt-dispatch already.

I had planned to incorporate some code in here but didn’t for a couple of reasons. One, this is kind of wordy and I’d rather do a follow-up that is more code-centric. Two, I haven’t finished the code. For now, the act of typing all this out has served it’s purpose in that it’s helped clarify things in my head. The nice thing is that much of this is already incorporated into gwt-dispatch already. I’m still a little fuzzy on where to implement the parts I need to implement (e.g. where do I check to see if an action can be performed anonymously?) but I have something that works. Which will serve as the basis for future posts.

Kyle the Dispatched

I’m in week four of my Google Web Toolkit adventure and things are heating up nicely. I’ve already switched to IntelliJ and back to Eclipse at least once (not really counting the two times I switched in my head while I was laying in bed; let it not be said that being spoiled for choice is always a good thing).

Reason I’m currently sticking with Eclipse: it seems better suited for GWT development. As an editor, IntelliJ rocks for .NET/ReSharper developers. All the shortcuts are familiar and things seem more organized and intuitive. Generally speaking, Eclipse feels like an IDE developed by committee, which it kinda was from what I’ve read. But the GWT and Google AppEngine plug-ins for Eclipse are pretty solid and there’s no confusing terminology around libraries and facets and artifacts and modules like there is with IntelliJ. After all, I’m just a .NET developer.

The gwt-presenter library has been a godsend in the short time I’ve been on the project. Its implementation of MVP is cleaner than my kids’ hides after they’ve had a good whoopin’. Unlike the ASP.NET version of MVP I’ve used over the years, this one has a very decoupled link ‘twixt presenters and views. Communication is managed through dependency injection to wire up view interfaces to their implementations and through an event bus, which comes standard with the gwt-presenter library.

Say you have a link in a left sidebar that users click to launch the Settings page in the main content window. With gwt-presenter, the workflow to wire this up is as follows:

• In the left sidebar’s presenter, attach a click handler to the Settings link exposed as a method on the Display interface, which the view implements. (gwt-presenter appears to use a Passive View approach to MVP.)
• In the click handler, raise a ShowSettingsWindow event on the event bus.
• Elsewhere (for example, in the main AppPresenter), we register a handler on the event bus to listen for this event and swap out whatever is being displayed in the content window with the SettingsPresenter.

Here’s where it gets even better. I don’t even need to create a ShowSettingsWindow event. gwt-presenter has history management built-in. This means that in order to navigate to a new “place” in the app, all I need to do is raise a PlaceRequestEvent. Furthermore, I also don’t need to handle the event anywhere. The PlaceRequestEvent includes a parameter indicating the name of the place you want to navigate to. (I believe I’m simplifying but then, I’m a simple person.) As long as that’s mapped to the SettingsPresenter (typically, exposed as a property on the presenter itself), gwt-presenter handles all that for you including adding it to the browser’s history.

So to sum up, out of the box, gwt-presenter gives you:

• A view and presenter decoupled thanks to dependency injection and a built-in event bus
• navigation between views
• browser history management and bookmarking

What makes this all the more amazing to me is something to which I alluded in the previous post: it’s nearly impossible not to use all of this in a GWT application. Yes, gwt-presenter is optional but it’s not optional the way ASP.NET MVC is optional to WebForms developers. The GWT documentation itself encourages the use of it as well as an event bus.

Note that I’m being sparse with implementation details. That’s because there’s no point. The absolute definitive guide for this is already underway over at Andreas Borglin’s pad. As much as I love David Chandler’s articles (and believe me, they’re golden), Andreas’s step-by-step guide to the various pieces, along with detailed source code for each step, is the type of teaching guide I can only aspire to. The purpose for this post is two-fold:

• Get people over to Andreas’s site to join in the awesomeness
• To help clarify my own thoughts on how this all works together.

As always, if any of this is helpful or interesting to you, that’s not my fault.

Kyle the Presented

The hillbilly be all Java’d up these days. For coming on three weeks, I’ve been the lone developer on a project based on Google Web Toolkit. It’s a web framework (naturally) that allows developers to build applications in Java and compiles it down to JavaScript, CSS, and HTML. Scoff all you want, if it were any other company behind it, I’d probably be right there with you.

We considered quite a few technologies before landing on this one. We went through Ruby, Sharp Architecture, Open Rasta, Moo Tools, and probably several others. I can defend ending up Google Web Toolkit privately if you want but putting the thought process up in a public forum is going to lead to comments that I’m too tired to moderate these days. And yes, I’ve heard of Script #, too.

Coming at this from a .NET developer’s standpoint has been interesting. It’s surprising how much we take for granted in our IDE, for example. I’m still meandering my way through the keyboard shortcuts in Eclipse (after a brief fling with IntelliJ IDEA). One thing I’d really like is a keyboard shortcut for the GWT Compile button, which currently is available only via a toolbar button or a context menu, as far as I can tell. Was happy to find a VIM plugin for it too that works as advertised.

Not sure if this applies to Java in general but within the confines of the Google Web Toolkit, the ecosystem is freakin’ phenomenal. The documentation page alone encourages unit testing and the use of an MVP architecture. Once you start reading about it, you can’t help but stumble on a number of other projects:

• gwt-presenter: A passive view implementation for GWT
• gwt-dispatch: A command pattern implementation for GWT
• Guice: Google’s dependency injection framework
• Gin: A dependency injection framework for the client part of GWT

The shocking thing from a .NET perspective is that these concepts are just sort of assumed. There’s little debate on whether dependency injection is necessary or whether passive view is overkill. Someone watched a presentation from Google IO last year, whipped up a command pattern project based on it, and lo! the people said it was good. Between support for Hibernate and the App Engine data store, I think people would look at you bug-eyed if you even suggested writing your own data access layer.

The downside to all this as that the tooling seems to be several steps behind what I’m used to in the Microsoft world. It’s still too early to make a fair comparison but even after digging a little deeper into Eclipse, I can’t imagine being quite as productive as I currently am in Visual Studio. Yes, there’s also IntelliJ but our anecdotal evidence suggests that neither Java IDE is seen as a de facto standard. For the moment, I’m sticking with Eclipse simply because all the documentation refers to it and the GWT and App Engine plug-ins for it work out of the box.

Couple of final shout-outs to two blogs that have been invaluable during the learning curve phase. First is Hive Development (currently featuring two posts on how to unit test MVP applications in GWT). Second is TurboManage, whose sample code is more detailed than many apps I’ve written.

Anyway, it’s been an interesting couple of weeks.

Kyle the Decaffeinated