Gwing

Ok, I am poking a bit of fun but on a serious note, Groovy + Swing; is it covered in the book at all? Is there any advantage to using Groovy (or scripting in general) for desktop app development? What are your thoughts?

Wow, Gwing! I like that name! There's Groovy's SwingBuilder that puts the bling in Swing. I've used it on a couple of non-work oriented desktop apps. I'm not sure what's in the book though, I'll wait for the experts to reply.

Originally posted by Gregg Bolinger: Ok, I am poking a bit of fun but on a serious note, Groovy + Swing; is it covered in the book at all? Is there any advantage to using Groovy (or scripting in general) for desktop app development? What are your thoughts?

Thanks.

Yes, there's a chapter in which the Groovy Swing Builder is explained, and where you'll learn how to create Swing UIs, layout components, write actions, and so on.

What does the SwingBuilder buy me? In what situation would I use it rather than regular Swing code?

Clifton Craig
Ranch Hand

Joined: May 26, 2006
Posts: 103

posted Dec 12, 2006 15:06:00

0

Gregg,

SwingBuilder buys you a hierachial-like API for constructing GUIs. Used along with other Groovy features like optional Map bracket syntax what you get is a lot more visually appealing than regular Java Swing code. Here's a brief example:

Thanks for the code. I installed groovy, which is to say I extracted the folder. Nothing real fancy or hard about it. Pretty much like installing Ant. Ran the example you provided. I get it. It makes sense. However, and don't take this the wrong way, it's not IMHO so much something Groovy is doing, but what the SwingBuilder is doing which just happens to come with Groovy. With the exceptions of the closures, I could write a SwingBuilder without groovy, making putting simple swing apps together just as simple. In fact, I have.

Again, I'm not slamming it or saying Groovy didn't aid in the process. I can clearly see where closures truly simplify the code. But I'm not seeing anything I'm drooling over. I'll keep plugging away. It's something time will tell with me. Thanks again.

"However, and don't take this the wrong way, it's not IMHO so much something Groovy is doing, but what the SwingBuilder is doing which just happens to come with Groovy. With the exceptions of the closures, I could write a SwingBuilder without groovy, making putting simple swing apps together just as simple. In fact, I have."

Very observant and partially correct. The idea of a builder is part of Groovy. Have a look at groovy.util.BuilderSupport. AntBuilder, MarkupBuilder, SwingBuilder, and other use it.

Don't forget, you can embed Groovy code within those closures. A rather lame example would be creating a bunch of menus: menu(text:'Bunch of menus') { for (i in 0..<10) { menuItem { action(name: i.toString(), ... } }

It is more than just a bunch of wrapper method calls. It is a way to create a mini language which extends Groovy.

Grails leverages builders in many ways. Look at the Grails docs, you should be able to spot the magic.

"However, and don't take this the wrong way, it's not IMHO so much something Groovy is doing, but what the SwingBuilder is doing which just happens to come with Groovy. With the exceptions of the closures, I could write a SwingBuilder without groovy, making putting simple swing apps together just as simple. In fact, I have."

Gregg, maybe you could show us an example of that. Ten we can compare these two. And maybe you should show how to integrate new components in the "builder" too, I mean custom ui elements, that you created or from a third party product.

The SwingBuilder example shown here uses many closures, in fact each "{" starts a new closure here. To get a code that is nearly as compact as this you would have either to define methods or inner classes.

Having to define methods makes it very complicated to extend the "builder", because I have to add methods for each custom ui element I add or that is not covered by the existing API. Using inner classes pollutes the view much.

So if you still want to have the method way, you would have to generalize the methods and use either Strings or class literals as information on what you want to do. But then... where is the gain? You loose static typing, don't you?

But maybe I am wrong, maybe you found a very good way in describing a complex ui with less code. Then it would be even more nice of you to show us the equivalent to the posted example.

Clifton Craig
Ranch Hand

Joined: May 26, 2006
Posts: 103

posted Dec 13, 2006 07:18:00

0

Gregg,

no offense taken. I'm sure you have written or seen code that makes Swing development less painful. Groovy offers it's own unique approach that's built in natively. The advantage of Groovy, as I believe you are beginning to see, is that these as well as many other features come bundled in the package. You get your closures, your builders, you meta-programming facilities, your typeless syntax, your Java API, your burgers and your fries all in a one stop shop.