Alex Collins is a enterprise Java developer and currently works in the UK. He has worked in the insurance, publishing, telecoms and supply chain. In his spare time he codes in Python, Clojure and Scala (but not at the same time) and enjoys a multitude of sports. His catchphrase is K.I.S.S! Alex has posted 20 posts at DZone. You can read more from them at their website. View Full User Profile

GWT in the enterprise - does it work?

09.07.2010
| 9719 views |
  • submit to reddit

Recent forays into GWT have enlightened me to this wonderful beast, but how do you apply it to the real world?

Consider this scenario: a web development team split into two groups - the developers and the designers. The former is responsible for implementing functionality on the website, the latter the page design, copy and usability. That can't be too alien to anyone who's worked in IT in a development or programme management role. Little wonder, perhaps, that there are numerous frameworks that try to ease the development of websites in Java, to allow the developers to be more productive in a business sense and not spend their time reinventing the wheel. This notion however does fall short slightly, and that is in how it is used by designers or editors.

In the old days of Struts 1.x you'd implement Actions as your controllers, and utilise an array of custom tags for reusability when it comes to the view layer. In our makeshift development scenario above, this would mean the designers having to put up with - or worse - get to grips with programming in Struts. This feels wrong from an organisational point of view. Perhaps it's akin to having your plumber lay your bathroom tiles too; although designers eat and breathe HTML, CSS & images it doesn't mean they should be au fait with Struts tags too. There's a fine line perhaps - custom tags could be used to leverage a designer-friendly functional tag for a page which is in your organisation's language.

So in steps GWT, which to be fair isn't supposed to fix this issue, but it addresses a larger need - dynamic web applications in JavaScript through reusable components ('widgets'), testable components and automated process (the code is compiled/converted to highly optimised JavaScript). This means you don't have to worry so much about client-side compatibilties such as does your page render in Chrome as well as IE etc. The best thing it does is harness the power of Java and combine it with the user experience, so that really MVC becomes MC - the view and controller very much are merged. Of course there's more to GWT than just these things - rich JSON integration, a well matured development environment & toolset - but these are the glaring big wins.

Can GWT be used to build big websites that separate design, editorial and development teams? Can a developer write the functional 'widgets' in GWT for a page and a designer work with it happily and perhaps still in HTML, or are you stuck with a developer creating your UIs in Java and your designers just playing with CSS? Is GWT simply not meant for this scenario of development? Is there a happy medium for such a thing to exist?

Tell me GWT experts lingering in the hue of their monitors - how does GWT sit within the real world 'enterprise' e-commerce department? Can it be utilised to build a large website, or are you stuck to cherry-picking from GWT and elsewhere? Enlighten this eager newbie, if you please!

 

Published at DZone with permission of its author, Alex Collins.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Jakub Grabowski replied on Tue, 2010/09/07 - 2:46pm

GWT is great technology that we've been succesfully using for some time building enterprise apps but in fact it's still quite poor in terms of designer/developer roles separation. It's definitely tool for developers and it performs great in this area. With good component libraries like Ext GWT or Smart GWT it's possible to create good looking and useful apps without designer. Recently there have been first step made to declarative UI (see UIBinder) but it's still too much "developerish" in my opinion. You can teach non-technical guys how to use it in simple scenarios (like using basic GWT widgets - buttons, fields, lists etc.) but using more sophisticated widgets still requires some developer skills.

Alex Collins replied on Tue, 2010/09/07 - 3:40pm in response to: Jakub Grabowski

Thanks for the heads up, I'll check those extensions out in due course. Seems my instincts were right?

Hisham Mardam-bey replied on Tue, 2010/09/07 - 9:19pm

Where I work (Mate1 Inc) we use GWT for our on-site email-like messaging system. The "mail client" is embedded into a div on the page and all navigation from that point on is solely in that div resulting in no full page reloads. Everything is relayed back and forth using JSON to a Tomcat cluster powered by Struts. The rest of the pages do not use GWT at this point. We've found that GWT worked really well for us because it really cut down on our bandwidth and load in the messaging system. The biggest problem remains that GWT can not re-use our templates that we use for Struts very well (in fact hardly at all) although we have styled it to perfectly match the rest of the site. Being the 3rd largest dating site on the web at the time of this writing, GWT helped us a fair bit and is continuing to do so everyday.

Gerry Noij replied on Wed, 2010/09/08 - 4:51am

I have a little experience with GWT and to me it's not a framework to use when you want to separate design and (Java) development. GWT uses Java to create the user interface (like Swing, although it uses css). It (or at least I) does not use html design.

When you want to really want to separate HTML design (including CSS, etc) from the Java development I would suggest a UI framework like Apache Wicket, where designers can design HTML pages and Java developers can develop the corresponding Java code and desired functionality. 

Sigma Hu replied on Wed, 2010/09/08 - 9:24am

I agree with Gerry. The only framework I have seen that really does provide separation of concerns is Wicket. Designers can hand over pure HTML pages (with css) to the devs and they can take it from there with no modifications aside from inserting a wicket:id="bla123" inside the relevant html/div/span tags.

Abel Morelos replied on Wed, 2010/09/08 - 10:57am

From my experience with GWT, I can say GWT is great for RIA applications, sadly GWT lacks many features that you would expect for enterprise applications such as security, IoC container, and others. The link provided by Allan looks like an interesting option if you are willing to integrate Spring with GWT, but I would love to have a GWT only solution.

Chad Retz replied on Wed, 2010/09/08 - 11:16am

We've used gwt-platform and found it properly separates roles. I can write view interfaces with several interfaces for handlers and what not and then pass it off to someone else to implement those interfaces. They know I populate the data, handle events, etc. Granted, the designer still needs basic knowledge of GWT widgets to develop with, but a strong understanding of CSS too (along w/ great features such as ClientBundles). The separation can be there. Reference part 1 and part 2 in this series.

As for IoC containers, I have great success sippin on Gin and Guice.

Mark Unknown replied on Fri, 2010/09/10 - 3:07pm

I think the title is wrong.  Most "enterprises" do little website work. The majority is applications. So yes, it is right for the enterprise. 

But actually answer your real question, no, i don't believe it is good for Web Sites where you have a developer and desginer or just a designer.  Can it be done?Sure. But there are better tools if you are building page-oriented sites. I don't do those. 

That all being said, GWT is JavaScript on the client. So one has to deal with the Java and JavaScript mismatch.

Main issues:

1. JavaScript does not have Reflection

2. Things like Calendar are not implemented in JavaScript

3. Can't serialize proxy objects to JavaScript.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.