Posts Tagged gwt

Spring4gwt, or Spring’s harmony for GWT

I’ve had an idea itching at me for awhile now, which started shortly after building a complex enterprise application using GWT connected to Spring services on the server. There are countless blogs out there describing various ways to wire up Spring with GWT, and Google’s own Gin is quite adequate for client-only dependency injection. But what I’d really like is something that ties this all together, and in the true spirit of GWT, makes it easy for a seasoned Java developer to apply proven, consistent DI practices in both the client and server using the Spring knowledge they likely already have.

My vision is basically this:

public class SomeGWTComponent {

	// Some other client-side component
	private MyWidget widget;

	// A remote service proxy to a server-side Spring service
	private MyService service;

	public void doSomething() {



		service.doServerStuff("data", new AsyncCallback<String>() {

				public void onFailure(Throwable caught) {

				public void onSuccess(String result) {

It’s important that MyService is a vanilla Spring service on the server – no extension of RemoteServlet required – and that MyWidget is any other GWT component. Injection should occur when the component is created, potentially with varying scopes just like on the server, and potentially also with @PostConstruct support for code to be executed after injection, leaving the constructor available for any pre-injection initialization. And finally, as much work as possible should be done during GWT compile minimize the run-time cost.

The approaches to GWT lookup/injection I’ve seen out there have at least one the following gaps:

  • They’re client-only (Gin)
  • They’re largely run-time, and slow (MVC helpers in component libraries like GXT)
  • They involve SpringMVC or other unnecessary server-side complexity (most blog guides)

So I’m going to try to bring this altogether in one simple library with the following goals:

  • Simplicity: Access Spring services from the client through a generic exporter; no service-specific mappings in web.xml, forced type hierarchy (services should be existing Spring POJO’s), or dependency on SpringMVC. In other words, when a new Spring service is added to the server it should require zero configuration changes to be accessible in the client if desired.
  • Consistency: Client-side dependency injection with native Spring look and feel; freedom to inject private members, via constructor, or via getters/setters with same Spring annotations and conventions that are already familiar.
  • Performance: Do all the heavy lifting with GWT generators to keep the client lean.

Behold, spring4gwt where I’ll do my best to make this a reality! The initial version captures objective #1, bringing together a generic servlet for exposing Spring services without turning each into its own RemoteServlet mapped in web.xml. Up next: accessing those services with Spring DI in the client!

, , , ,


GWT 1.6 and GXT 2.0-M1 upgrade experience

This past weekend I had a chance to upgrade a GWT/GXT project earlier than expected. We’ve had considerable pain on the current version of GXT and hoped this might lessen it; sadly, the grass was not much greener on the other side.

GWT for its part was a fairly straightforward process, even with all the significant “breaking” API changes like a new war-based project layout, new eventing model, new compiler, and revamped hosted mode (see the complete list here). The steps involved were essentially:

  • Bring in the new jars
  • Move resource directories and web.xml into the new preferred war location
  • Fix compile errors (mostly new event/listener type and getters/setters replacing public members)
  • Change the compiler and hosted mode classes to the new ones, with the new args
  • Toy with the hosted mode and build classpaths so that Selenium is in the classpath first for unit tests, but GWT is first for hosted mode (because our project uses Selenium for UI tests and both Selenium and GWT are nice enough to bundle Jetty – and different versions, no less – as dependencies; Selenium, please move to Jetty 6 already!)

Additionally, each developer on the project had to disable/re-enable their GWT profile in Eclipse to have it detect 1.6 mode and re-create any run targets (not a big deal really, since the GWT Eclipse plugin makes this much easier than before!).

We have run into one intermittent problem worth noting: When attempting to run our client with a mock services stack (simple web.xml with local servlets that return test data), hosted mode will occaisonally freeze on startup. Debugging has revealed that our RPC calls are initiated but never returned. Base on the randomness and timing of the freeze it almost looks like a race condition where the mock services aren’t deployed as fast as the client, and hosted mode gets stuck in a loop waiting for the return on a call that was never received. Since our application has a rather custom setup where we run RPC against a different context in production (separate services war inside the same container), and this is also something we’ve attempted to mock, it’s not bad as a single issue; our workaround is to simply run the mock service stack externally on Jetty via an ant task and use hosted mode solely for deploying the client.

GXT on the other hand was a nightmare. GXT issues were the main driver behind our early upgrade – since the 2.0 release date keeps moving we decided to bite the bullet now and try M1 in hopes that it would fix more than it breaks. The obvious breaking changes were minimal – just some type changes, event differences, and slight re-arrangement of classes. But in terms of functionality the visual layout of the application was immediately wrecked on upgrade due to a number of blatant bugs (or very questionable behavior changes). Note that after our initial run-through we downloaded the very latest 2.0 snapshot from svn (as of 4/26/2009) and built that with similar results:

Percentage/pixel sizing problems
On components using a CardLayout (like TabPanel), height and width percentages get changed into raw pixels. In other words, calling setHeight(“100%”) results in HTML with height=100px embedded in it. This is incredibly annoying and I can’t overstate how thoroughly it breaks an application. Since our application sizes very dynamically and we intentionally avoid fixed size like the plague, it immediately became a mangled cluster of 100×100 boxes. Entertaining yes, but difficult to fix. We’ve ended up implementing a mixture of fixed heights/widths on the affected components and trying to delegate more explicitly to parent sizes until there’s a permanent fix.

Tighter coupling
Components seem less designed for extension, or at least more tightly coupled to each other and the DOM; for instance, several components that we’d extended and overridden onRender() for specific functionality blew up spectacularly, requiring that we override and assuage other methods to make them content again. The changes aren’t bad, but a framework doesn’t feel well thought-out when I’m forced to hack things one way in release x, then hack them a different way in release y.

CSS changes
To the GXT team’s credit the CSS tags used by objects are largely unchanged, however the css behavior and default values of many components are different; this was mostly an impact where we’d intentionally hacked things in CSS to make them look correct cross-browser and the hack was no longer necessary (or worse, now causing an issue). Our bad for hacking, but again, it sucks when a framework forces you into this, then keeps changing it.

New features incomplete
Any of the big “new” features we tried like HBoxLayout and VBoxLayout seem incredibly incomplete or broken. For example, attempting to use a VBoxLayout resulted in a panel rendering partially in the correct spot with its children lined up at the bottom of the screen, below the rest of the application; source inspection revealed some serious div madness going on. Based on this state of fail we’re not planning to dive further into any new features until it’s GA.

All in all the net change in GXT 2.0 as of M1 seems to be slightly better performance and a mild set of new features, yet with most of those new features broken and some very serious and annoying core bugs such as the percentage/pixel issue. I really hope they’re hard at working fixing these, as the pushed release date may suggest, and that the final release has some honest documentation on ALL breaking API changes and known issues, especially since documentation is something GXT has always lacked. I would highly recommend against anyone taking 2.0-M1 unless pain is something you enjoy, considering the serious issues and the fact that none of the new features feel usable yet.

GWT 1.6 by contrast is a no-brainer; if you’re lucky enough to be building an app with core GWT and homegrown components and/or another library this will probably make your life much easier. The war layout makes for even tighter integration with Java and is great for projects that are a mix of GWT and static content or other UI technologies. And the new configurability of the compiler makes parallel compilation or even disabling some browser permutations as easy as a few compiler args or lines in your .gwt.xml.

To the Ext guys: I really hope you have something better in store for us by 2.0 GA! The team I work on has many developers who’re new to GWT development and have backgrounds in custom AJAX, Flash, or C# UI’s. GXT 2.0 is continuing to build their impression that this technology is a hack that brings the “worst of both worlds”: they see a complex framework that’s lacking many features, yet is difficult or impossible to extend in a way that will be a) consistent cross-browser and b) not break completely on upgrade. Combined with the lengthy build/deploy time to test small changes in real browsers, it’s feeling like a net loss vs. straight AJAX (in JavaScript) or, better yet, another RIA technology completely such as Flash or Silverlight.

It’s worth noting that none of the pain points I’m belaboring, especially when it comes to CSS weirdness and cross-browser testing, are anything unexpected for traditional web application development. But they should not be the norm for GWT: a library on top of GWT that experiences all these pitfalls with regularity seems to miss the point. We expect something in return for long compile times and difficult-to-debug generated code; certainly more than just the convenience and familiarity of Java versus JavaScript.

But as someone heavily vested in a GXT project, here’s hoping even more that it shapes up a bit by 2.0 GA!

, ,


GXT is cool, but painful

Let me start by saying I’m completely on board the thin-client bandwagon. I think lightweight web applications are the future of everything from simple apps to enterprise software, and loved the premise of the Google Web Toolkit (GWT) from the start. So naturally when I had a chance to use GXT – Ext-JS’s framework that bridges their sexy JavaScript library with the promise of GWT development – I had high hopes. So far, I still feel the potential but can’t bring myself to love it quite as much as I want to.

The whole point of GWT is to take fragile and tedious web 2.0 development and make it feel like you’re actually building software: write one set of code that’s reusable and browser-agnostic, add handy modern language features like generic types and annotations, support a (relatively) fast change and deploy model, and best of all, at the end of the day still build good-old-fashioned HTML and JavaScript that runs in any browser: no Flash, Applet, Silverlight, or hardcore server-centric architecture required.

The core GWT guys get this and have made huge strides. The biggest beefs like IDE integration, richer hosted mode, and faster compile are all getting addressed. Integration with standards like Spring and Hibernate are already there and work amazingly well, if not quite out-of-the-box. For example, check out Giving GWT a Spring in its Step and Gilead.

By itself Ext-JS is also a great JavaScript library, with some of the best looking and most functional components out there. But so far their take on GWT misses the mark. The framework’s architecture – and more importantly, day-to-day use of it in real application code – screams JavaScript at every turn. Yes, I know this code will be used to build more code that runs in a browser at some point but it’s not supposed to constantly remind me of it! I don’t like switching between strongly typed objects and BeanModels full of string properties, having to bury myself in ten levels of CSS to make any slight component change look good in both Firefox and IE, or find their generic contortions that entertaining. It’s like the Ext guys are so lost in JavaScript that they missed the point of GWT.

The irony is that they’ve built a lot of tools that solve these problems individually quite well: there’s a BeanModelTag that will assemble reflection-like metadata when beans are sent to the UI and provide it on-demand using a factory from the bean, allowing you to switch between their models and the original beans as needed. The css for the components themselves is incredibly specific, well-organized, and for the most part consistent. The event framework, while not totally complete, is easily extended. These pieces just need to be put together with some level of configuration and convention so that day-to-day application code can focus on the look and feel instead of boilerplate MVC connectivity. In short they need to focus on how Java developers build applications, rather than how web developers can write the same kind of client code in Java. I’d love to be able to populate data in a UI component by doing the following:

  1. Write the server-side Java service
  2. Expose the service with simple annotation-based name and/or URL
  3. Create a client component that takes a data store and assign that store to the service endpoint

Ironically, this is the kind of thing that JSF components via Seam and Flash via Flex with BlazeDS do really well. The Ext components look way better than any JSF component library and are easily on par with their Flex counterparts, and that eye-candy appeal wins them a lot of ground (especially from those non-technical decision makers!). Architecturally, not depending on Flash or a heavy Java server puts them ahead of the curve: just put some implementation-level polish on it please!

I still have high hopes for GXT 2.0 which is currently in preview. The project I’m working on is standing by on 1.2.3 for now but we’ll switch over eventually and see how it goes.

, ,