By now, most of you probably have heard about the announcements at Google I/O around Spring, Roo, STS and GWT. Ben and Rod covered this in their respective blogposts recently. If you missed the keynote I strongly recommend to watch the recording on YouTube to catch up (the relevant section starts at 1:09:00 into the recording).
Today I’d like to provide some detailed steps and instructions on how you can use Roo and STS to create your first GWT application.
Before we can fire up the Roo shell and start typing commands, we need to download and install all pre-requisites. Although a lot of components are involved in building advanced single-page applications that can run on the cloud, you really only need to download the STS 2.3.3.M1 bundle for your operating system. The STS installation includes Roo 1.1.0.M1, tc Server Developer Edition with Spring Insight (required to get Speed Tracer integration), Maven 2.2 and access to the Google Plugin for Eclipse (GPE).
Grails is a fantastic framework for developing web applications quickly and easily. You also have access to a plethora of plugins that provide features or make integration with other systems nice and easy. That’s all good, but in this article I want to talk about what happens when your application grows and you start drowning in a sea of controllers, domain classes, and other files.
Separation of concerns
One of the most useful patterns in software architecture is called separation of concerns. The idea is that you group everything related to a particular feature or concern into a single, self-contained unit. The code in that unit should not take on any other responsibility. For example, the business logic of a web service should be in one class while the handling of SOAP messages should be in another: the business logic and SOAP handling are two different concerns.
Last week, I described how Grails now treats plugins like normal dependencies that can be pulled from Maven-compatible repositories. Although this was the big new feature for 1.3, it wasn’t the only one. In this post, I’ll look at some of the others, starting with a feature that I only recently found out about.
GORM provides three distinct ways of performing database queries:
dynamic finders, e.g. Book.findByTitleAndAuthorLike(…);
A few weeks ago I tweeted that—incredibly—SpringSource was executing faster within VMware than as a startup. Today we announce another exciting development bearing this out.
Following our VMforce partnership with SaaS leader salesforce.com, we are today announcing a collaboration between VMware and Google, centering around the Spring programming model and SpringSource IDE and RAD tooling. Today’s announcement makes Spring the preferred programming model for Google App Engine. This is a tremendous endorsement of Spring as the best and most portable programming model for Java and opens up a new deployment opportunity for Spring developers. The demo in today’s keynote at Google I/O showcased the results from months of collaboration between SpringSource and Google engineers—most of which benefits Spring developers, regardless of where they wish to deploy their applications. The highlights: innovative, close integration between Spring and Google Web Toolkit (GWT) offering the ability to build rich applications with amazing speed; the ability to easily target Spring applications to App Engine; a compelling integration between Spring Insight and Google Speed Tracer to provide insight into the performance of Spring applications from browser to database; and tight integration of all this with SpringSource Tool Suite to provide a polished, productive experience.
I’m delighted to announce that we’ve just released Spring Roo 1.1.0.M1. Spring Roo is the fastest way for Java developers to build Spring-based applications in the Java programming language. With the Roo 1.1.0.M1 you can build working web applications - complete with a Google Web Toolkit (GWT) front end - in as little as 200 keystrokes! Plus as usual we’ve concurrently released a new version of SpringSource Tool Suite (STS 2.3.3.M1) which is optimised for the latest and greatest Roo goodies!
For a long time, managing Grails dependencies simply meant putting them in your application’s lib directory. Then came Grails 1.2 and the dependency DSL: you could finally declare your dependencies and have Grails automatically download them and make them available to your app. Great!
Now, Grails 1.3 has brought the dependency DSL to the realm of plugins.
setting up a suitable Subversion server to act as a Grails plugin repository is not simple; and
you can’t control what dependencies a plugin brings into your application.