Category: Griffon

Categories
Grails Griffon Groovy Spring

SpringOne 2GX final thoughts

I wound up too busy to maintain my daily reports, but here are a couple of items I want to highlight as important take-aways from SpringOne 2GX. Rather than just recap sessions or dole out marketing-type praise, I’m going to focus on some things I learned that I didn’t necessarily expect.

  1. A lot of people who advocate Scala or Clojure over Groovy emphasize their scalability and features like immutable objects. Groovy’s @Immutable annotation takes care of the latter, and the gpars project handles the rest. You can use @Immutable right away. The gpars project is still pretty early in its lifecycle, but it’s going to be HUGE.
  2. By the way, despite the fact it looks like it’s pronounced “Gee-Pars” (and Paul King kept calling it that), I love the way Scott Davis kept referring to it as “jeepers” 🙂
  3. Twitter has reached “essential” status at conferences. This is the first conference I attended where I would have missed half of what was going on if I hadn’t been using my Twitter client the whole time (I use twhirl, btw, but I’m open to other possibilities). Most of the presenters (@glaforge, @graemerocher, @paulk_asert, @daveklein, @jeffscottbrown, @scottdavis99, @aalmiray, and several others that would come to mind if I thought harder about it) were continually tweeting good info. As a company, @ManningBooks did an excellent job, especially with their #hideandtweet game.
  4. As a totally unexpected (to me) underlying theme, the rise of non-relational databases is striking. Apparently, the major cloud providers (Google AppEngine, Amazon SimpleDB) have decided that relational simply doesn’t scale, so they’re going with “schemaless” solutions. I had no idea how significant that was until I heard enthusiastic support for the idea from the audience of one of the Amazon cloud computing sessions. I know a lot of DBAs who are in for quite a shock. So is Oracle, too, and that’s got to be a Good Thing.
  5. Like Grails recently and Ruby on Rails before that, the new Spring Roo project makes existing web development approaches look antiquated. Roo and Grails are siblings that will learn a lot from each other as they continue to grow. For example, Grails has an interactive console, but it isn’t nearly as cool as Roo’s. I’m sure that’ll change soon enough.
  6. The extraordinarily humility and friendliness of the Groovy and Grails core teams is charming. Everyone I met seems almost embarrassed to be having so much fun working on something they like so much. There’s none of the arrogance or elitism that characterizes so many other revolutionary groups, and they always go out of their way to help and answer questions. I love talking to them and really hope to be included as one of them some day.
  7. Speaking of that, sometimes timing is everything. I told Guillaume Laforge (Groovy team lead, for those who don’t know) that he was one of my personal heroes and nearly made him spit up his drink. Sorry, I didn’t get a picture. 🙂
  8. Griffon made several fans at the conference, especially among the existing Groovy people. I still think it’s a bit early for mainstream practice, but all the signs are favorable.
  9. October is definitely the right time to visit New Orleans.

I had a very good time at the conference and am already looking forward to the next one.

Categories
Griffon Groovy Spring

SpringOne 2GX Day 1

… or day 2, by the official count. Today was the first full day of sessions, though, so I’m counting from 1.

From now on, I can only comment on the sessions I attended. There were many parallel sessions I wish I could have gone to, but until I get one of those cool Time Turner like Hermione Granger had in the third Harry Potter movie, I still have to operate synchronously. I’ll just make some comments about each here.

Since the conference is a combined one, I decided I should try to attend some Spring sessions as well as Groovy/Grails/Griffon ones. The first session I went to was “Overview of the Spring 3.0 Web Stack,” given by Keith Donald. This was a major overview, with some discussion of Spring MVC, Spring JavaScript, Spring Web Flow, Spring Faces, Spring Security, and even Spring BlazeDS Integration. That’s obviously way more that can be covered in one session, so a lot of the slides were really pointers to other presentations given later in the conference.

That said, after the introductory material he spent a fair amount of time on the new REST support in Spring MVC 3.0. I’ve been working with Spring 2.5 for some time, and I’ve played with the new MVC annotations like @Controller and @Service, but I hadn’t seen the RESTful ones yet.

To give us an idea what’s coming, Keith went over parts of the new sample application for Spring MVC 3.0, yet another version of their PetClinic app. For those interested in looking at it, the svn repository for the RESTful PetClinic is here. Feel free to check it out.

Keith spent a fair amount of time on ways to do the URL mapping, the new validator framework, and the new formatters that replace custom property editors. This isn’t the right post for a detailed discussion, so I’ll refer you to SpringSource for more details. The slides suggested the link http://www.springsource.org/web , but that site didn’t exist when I tried to go there. Still, there’s tons of documentation on all the projects at the base URL.

It turned out there wasn’t time for much information about the other areas, but I did note that Spring JavaScript is really a spring-enabled front end on dojo, which is pretty cool.

(I can’t help automatically going, “Pain … does not exist … in this dojo!” Hopefully Spring JavaScript is also painless.)

It also turns out that the amount of configuration to get Spring Security working has been reduced dramatically. That can only be good news.

In the end, I’d say that Spring definitely lived up to its “Swiss Army Chainsaw” reputation, but I liked a lot of what I saw.

(I especially liked the introduction to Spring Roo that I saw later. See below for that.)

The next talk I attended was “Introduction to Griffon” by Danno Ferrin. I was torn there, because I really wanted to go see Paul King talk about Spring and web services, but I knew most of what Paul was going to say already. Besides, I can probably harass him with questions about the rest (no pun intended) tomorrow. 🙂

I do know something about Griffon. It started off as an offshoot of the Grails project, with the same value proposition: bring ease of development and convention over configuration to desktop development. I’ve had long email exchanges with Andres Almiray about Swing development, especially with Groovy’s SwingBuilder and working on and off the Event Dispatch Thread, which I’ve written about here a few times. I’ve only run the basic demos on Griffon, though, and hadn’t seen it presented in any official way yet.

Griffon is all about enforcing MVC architecture with desktop apps. It looks and feels a lot like Grails, but there are important differences. The project is only at version 0.2 (and only a beta for that at the moment), so it’s really early. Still, the basics of “MVC groups” (Danno wanted a better term for them, but I kind of like that one), event handling, deployment, and more are already in place.

The deployment story rocks, by the way. You can export your app as a jar file, as an applet, or even as a Java Web Start application automatically, and it’ll help you digitally sign the jars. That’s really cool. The whole technology is pretty slick, actually. It’s pretty much the only framework for desktop apps I know, though I believe there are a few in development. I suggest that anyone interested in desktop development (and there are far more people like that than most developers think) to check it out at its home page.

By the way, Danno had a great line that I just have to use in the future. He said at some point in the presentation he might have to switch from Bob Ross mode to Julia Child mode, meaning he wasn’t necessarily going to have enough time to paint in front of us, but rather would have to pull completed meals out of the oven. I knew exactly what he meant. 🙂

My feeling about Griffon is that it’s great, but it’s still very early in the development cycle and the documentation isn’t sufficient yet for actual work by people who aren’t closely involved in the project. On the other hand, Danno, Andres, and James Williams (not here) are all co-authors on the upcoming “Griffon in Action” book from Manning. I suspect that book will be as important to future Griffon developers as “Groovy in Action” was (and is) to Groovy developers.

** update: James’s last name is Williams, of course. Also, he’s not a co-author on the book. He is a core committer on the Griffon project. **

The next talk I attended was Paul King’s presentation of “Industrial Strength Groovy.” As he explained, some of the reluctance to adopt Groovy that he finds in the business world is a fear that they won’t be able to use the tools they already adopted and really like. Paul went through a range of tool categories showing how that wasn’t the case.

He discussed lots of testing tools, including mocks like MockFor (built into Groovy), GMock, and EasyMock; injection with Spring or Guice; code coverage with Cobertura; build tools like Ant, Gant, GMaven, and Gradle, Hudson continuous integration, and lots more.

Here’s the best part, at least as far as you, the outside reader, is concerned. You can see all of Paul’s slides on SlideShare.

As an aside, I’m of the opinion that anything Paul writes is great. He has an excellent introductory tutorial for Groovy online in PDF form. He’s also a co-author on GinA (Groovy in Action), which doesn’t surprise me at all.

For the next talk I switched back to the Spring side and attended “Introduction to Spring Roo” by Ben Alex. Ben founded the Roo project, and as it turned out he also founded the Spring Security project. That’s quite a resume. He’s also an outstanding presenter. He doesn’t go for rah-rah tricks or false enthusiasm. Instead he has a very friendly, comfortable, low-pressure style that I find quite appealing. He reminds me a lot of Jason Rudolph that way, or even Guillaume Laforge.

I’d heard of Spring Roo, but didn’t know any details. My original thought was, “oh no, not another Java framework,” but decided to give Roo a try.

Let me just say flat out that I was very impressed. Roo’s best feature (okay, best is a strong term — one of its best features) is that it operates as an interactive command-line application with lots of help and hints available. You start up Roo at the command line (or in STS), type “hint”, and it tells you what it’s expecting next. Just keep hitting the TAB key to get more suggestions.

Essentially what Roo is about is building and configuring a Maven project with lots of AspectJ code generation to modify the source. It felt a lot like Grails, but using Java instead, and most of the code generation affected what happens at compile time rather than at run time. For example, it automatically generates getters and setters and toString() methods for domain objects. It generates the same sort of dynamic finders that Grails has, though you have to choose to add them. It automatically configures Spring JavaScript to do form validation. It uses the JSR 303 bean validation annotations to enforce what it wants. It configures databases for you, too.

I couldn’t help but feel that the Grails framework has been highly influential inside SpringSource. I can only assume that’s partly because Graeme Rocher is now one of their employees (after they bought G2One). At any rate, this was the first Java-based framework that I thought could provide serious competition to Grails. I still like Grails partly because I really like Groovy, and I think it’s always easier to implement anything in Groovy than in Java. Also, Grails has about 300 plugins at the moment, that do basically everything. But if you’re committed to Java, Roo looks like a great alternative. You can download it at the project page at SpringSource.

I only had a couple of criticisms. One was that you can replay your Roo scripts, which is cool, but there’s no way to automatically record them as you go. Expect that to change, since everybody seemed to want it.

The other came from the fact that I downloaded Roo while Ben was talking and was running the app along with him. Then, when typed

roo> perform eclipse

to generate an Eclipse project, I did the same and had to wait about 15 minutes (literally — that’s an estimate) while the underlying Maven engine downloaded the Internet. When I went to test the app in Tomcat, I exited Roo and typed “mvn tomcat:run” and waited again for tons more downloads, even though I have both Tomcat 6 and Tomcat 5.5 on my hard drive already. Finally, when I tried out the Selenium support (another great feature, btw) and ran “mvn selenium:selenese” I had to wait again as Maven did its thing. They all worked, and the delays all had to do with Maven rather than Roo, but yikes nevertheless.

Right now Roo is at version 1.0.0.RC2 and should be at GA some time in December, and that one will include docs. Until then it’s mostly blog posts and the associated forums. I’m definitely going to try Roo, though, when it’s ready.

This post has already gone on too long, so I think I’ll leave it at that. I’m enjoying the conference and am looking forward to more presentations tomorrow.

Categories
Griffon Groovy

Making Swing Groovy, Part II: Binding

In my previous post in this series, I presented a trivial Echo GUI written in Groovy.  By using SwingBuilder and closures, the code for the GUI was dramatically simplified compared to the Java version.  But Groovy can go beyond that.  In this post, I’ll talk about the bind method and the @Bindable annotation, which help transform Swing development into the MVC structure of Griffon.

The code for the Echo GUI currently consists of:

[sourcecode language=”java”]
import groovy.swing.SwingBuilder
import javax.swing.WindowConstants as WC

SwingBuilder.build() {
frame(title:’Echo GUI’, size:[300,100],
visible:true, defaultCloseOperation:WC.EXIT_ON_CLOSE) {
gridLayout(cols: 2, rows: 0)
label ‘Input text: ‘
input = textField(columns:10,
actionPerformed: { output.text = input.text })
label ‘Echo: ‘
output = label()
}
}[/sourcecode]

The closure assigned to the actionPerformed property transfers the input from the text field to the output label.  In order to make that happen, both the field and the label were given names that could be referenced inside the closure.

Groovy 1.5+ includes a method called bind, which works with bound properties in the ancient JavaBeans specification.  For those whose only exposure to JavaBeans is through POJO’s on the server side, the original JavaBeans framework was designed to support GUI builders.  It looked and felt much like building GUIs in VB, in that you dragged these “beans” onto a palette, hooked them together, and set the values of their properties.  It was a way of writing Java user interfaces without writing any Java code, at least until you wanted the various widgets to actually do something.

I remember back around 1998, I convinced my boss at the time to purchase Sun’s proposed IDE based on beans.  I think it was called Sun Java WorkBench, or something like that.  It cost about $99, and it came with beans that you could drag and drop, and you could add your own jar files full of beans as well.  While it looked pretty cool, you didn’t have the source code for any of the beans, which limited their usefulness.

Java on the client side didn’t really take off, and the market for the IDE certainly didn’t pan out.  I do remember that the JavaBeans specification — written largely to support the client-side development model — brought us many aspects of Java that we take for granted now.  My first encounter with serialization came from there, as well as reflection, though they used the extremely awkward name introspection for it.  In addition to implementing java.io.Serializable, JavaBeans according to the spec were also supposed to have default constructors and the now-infamous naming convention for getters and setters for all the properties.  Actually, providing a getter method was sufficient to define a property of a JavaBean.

The spec also referred to various types of properties, like bound and constrained, and JavaBeans were also supposed to implement the PropertyChangeListener interface.

Very few Java programs were actually written using those JavaBeans, and the expected third-party market in JavaBeans libraries never seemed to develop.  I seem to recall that there were a couple of success stories (wasn’t IBM’s VisualAge for Java supposed to be written using the original JavaBeans spec?), but mostly the whole technology went away.

It wasn’t until a few years later that JavaBeans re-emerged, as the way to get Java code out of JavaServer Pages.  Sun’s Model 1 architecture consisted entirely of JSPs and JavaBeans, with no explicit servlets anywhere.  Model 2 changed all that by using servlets for controllers, but that came later.  By then, though, people used what we now call POJO’s for model classes, and you were still supposed to make your beans serializable, but all that stuff about property change listeners was largely ignored.

Groovy gives us a chance to use JavaBeans as model classes in an especially easy way.  First, here’s an illustration of a simple GUI that uses the bind method in Groovy.

[sourcecode language=”java”]
import groovy.swing.SwingBuilder
import javax.swing.WindowConstants as WC
import java.awt.BorderLayout as BL

SwingBuilder.build() {
frame(title:’Binding to Slider’, pack:true, visible:true,
defaultCloseOperation:WC.EXIT_ON_CLOSE) {
panel(constraints:BL.CENTER) {
slider(id:’sl’)
}
panel(constraints:BL.SOUTH) {
label ‘Slider value: ‘
label(text:bind(source:sl, sourceProperty:’value’))
}
}
}
[/sourcecode]

Here we’re taking advantage of the fact that all Swing widgets extend Component, which means they support property change listeners.  In this case, we have a slider with a property called value.  The bind method assigns the text of the label to the value property of the slider.  Dragging the slider immediately updates the label.

This is seriously cool, and means that the Echo GUI shown above can be made even more responsive by replacing the actionListener by binding the output label directly to the input text field.

[sourcecode language=”java”]
import groovy.swing.SwingBuilder
import javax.swing.WindowConstants as WC

SwingBuilder.build {
frame(title: ‘Regular Binding (Groovy)’, size: [300,100],
visible:true, defaultCloseOperation: WC.EXIT_ON_CLOSE ) {
gridLayout(cols: 2, rows: 0)
label ‘Input text: ‘
textField(columns:10, id:’tf’)
label ‘Echo: ‘
label(text:bind(source:tf, sourceProperty:’text’))
}
}
[/sourcecode]

The result is that now, any characters typed into the text field are immediately transferred into the label. Deletes work the same way. The text in the output label is bound to the value of the input text field.

While this is interesting and even useful, a true model-view-controller architecture wouldn’t always bind widgets to other widgets. Instead, input values would be transfered to a model class, and then the model values would be sent to the output view. What we need, therefore, is a way to bind the view elements to an actual Java bean.

If this was Java, we would introduce a class that supported property change capabilities. Consider such a model class in Java:
[sourcecode language=”java”]
import java.beans.PropertyChangeListener;
import java.beans.PropertyChangeSupport;

public class Message {
private String text;
private PropertyChangeSupport pcs = new PropertyChangeSupport(this);

public String getText() {
return text;
}

public void setText(String text) {
pcs.firePropertyChange(“text”, this.text, this.text = text);
}

public void addPropertyChangeListener(PropertyChangeListener listener) {
pcs.addPropertyChangeListener(listener);
}

public void removePropertyChangeListener(PropertyChangeListener listener) {
pcs.removePropertyChangeListener(listener);
}
}
[/sourcecode]
The Message class has a single property, called text. It also relies on the PropertyChangeSupport class to enable it to add and remove property change listeners. When the text property is changed, the setText method fires a property change event to all the listeners, where the arguments to the firePropertyChange method are the name of the property, its old value, and the new value.

How does Groovy simplify this? The key is the @Bindable annotation, which is currently only in Groovy 1.6 beta 2. Fortunately, that version is included in Griffon, though I did go to the trouble to download and rebuild it myself (a post for another time).

Using Groovy 1.6b2, here’s the equivalent Groovy bean:
[sourcecode language=”java”]
import groovy.beans.Bindable

class Message {
@Bindable def text
}
[/sourcecode]
Seems almost unfair, doesn’t it? Add an annotation to the field, and you’re done. It’s hard to get much simpler than that.

Now all you need is a listener. In Java land, the GUI would use something like:
[sourcecode language=”java”]
//…
private Message msg = new Message();
//…
msg.addPropertyChangeListener(new PropertyChangeListener(){
@Override
public void propertyChange(PropertyChangeEvent evt) {
output.setText((String) evt.getNewValue());
}
});
//…
[/sourcecode]
again using an anonymous inner class to respond to the change. By contrast, here is the Groovy version (where in this case the code is sufficiently succinct that I can include the whole thing):
[sourcecode language=”java”]
import groovy.swing.SwingBuilder
import javax.swing.WindowConstants as WC

def model = new Message()

SwingBuilder.build() {
frame(title:’Echo GUI’, size:[300,100],
visible: true, defaultCloseOperation:WC.EXIT_ON_CLOSE) {
gridLayout(cols: 2, rows: 0)
label ‘Input text: ‘
input = textField(columns:10,
actionPerformed: { model.text = input.text })
label ‘Echo: ‘
label(text: bind { model.text })
}
}
[/sourcecode]
Once again, this won’t work unless you’re using Groovy 1.6b2 or above. The bind method has been modified to take a closure as its last argument, and the closure in question refers to the text property of the model, rather than to another widget. Note that now I’ve gone back to implementing actionListener, because I have to get the text value from the view into the model, so it’s not quite as clean as before. That could be changed, but at the moment it seems reasonable to do it that way.

Of course, if we have a model and we have a view, what we need next is a controller. Griffon shows how to do that, but I’ll leave it for another post.

The bottom line is that by using Groovy’s bind method and @Bindable annotation, constructing a GUI based on a realistic MVC architecture is now viable, and even easy.