Andres Almiray

Hi Bill,

You almost got it working. The problem you're facing is that the main contentPane (the component used by the JFrame to hold its children) has a FlowLayout as its default layout. You must apply a BorderLayout to this contentPane. Also, the constraints set on both panels are actually not set on the panels. Finally, the print callback intended for the button click event is never assigned to the button.

Have a look at the following snippet and notice the small differences:

import java.awt.* import javax.swing.* import groovy.swing.SwingBuilder import java.awt.BorderLayout as BL name = "ATestGroovyGui" builder = new SwingBuilder().edt { frame(title: name, show: true, pack: true, defaultCloseOperation:JFrame.EXIT_ON_CLOSE) { borderLayout() panel(constraints: BL.CENTER) { gridLayout(cols: 2, rows: 2) label(text: "These", horizontalTextPosition: JLabel.CENTER) label(text: "are", horizontalTextPosition: JLabel.CENTER) label(text: "four", horizontalTextPosition: JLabel.CENTER) label(text: "labels", horizontalTextPosition: JLabel.CENTER) } panel(constraints: BL.SOUTH) { borderLayout() alabel = label(text: "alabel", horizontalTextPosition: JLabel.CENTER, constraints: BorderLayout.WEST) button(text: "abutton", actionPerformed: { alabel.text = "changed" }, horizontalTextPosition: JButton.CENTER, constraints: BorderLayout.EAST ) } } }

Cheers,
Andres

Congratulations to the winners and a big "thank you!" to all participants and JavaRanch.

Cheers,
Andres

Hi Thierry,

It certainly is possible. You would have to choose which framework is the lead though. Either you bootstrap the application using NBP and somehow instantiate Griffon components and MVC groups; or you bootstrap a Griffon application and call NBP modules.

This is a question that appears form time to time but to be really honest noone has actually come back and told us about their experience. I'm not an NB user myself so I really can't say much about the whole experience. I hope I can change that in the future.

Cheers,
Andres

Vijitha,

This question has been answered in the following thread https://coderanch.com/t/549533/GUI/java/Migrating-existing-application-Griffon.

The simplest solution is to create a Griffon application, drop the existing codebase into src/main and make calls to it from MVC members.

Cheers,
Andres

Too slow to do what exactly? Is it because of the choice of Groovy as glue language?
I'm happy to say that the answer is no. Most of the Griffon runtime is written in Java, which means that the inner workings are as fast as your vanilla Java framework. There are parts of the code that use Groovy APIs, most of those APIs happen to be written in Java too.

Does this mean Griffon is as fast as a Java framework? No, it is not, but it's definitely not as slow as you might think. If you write MVC members in Groovy then you're subject to the Meta Object protocol, i.e, dynamic method dispatch. What happens is that instead of getting a direct method invocation you follow (automatically) a more elaborate decision tree to find out the right method to invoke. This is where the "slowness" of Groovy appears. In practice Groovy code can be +50% slow than Java, which only comes into play if you're doing computation intensive tasks like number crunching as most of the times the responsiveness of an application is measured by its weakest link: I/O.

Cheers,
Andres

Jeff,

Well, a colleague of mine is working with a team that built their own Java Swing framework. He convinced them to give Griffon a try. Considering that this is a very conservative Java shop they began by creating an skeleton app and place all the existing sources into src/main. They use the initial MVC group that was created with the app to bootstrap the "legacy" code. This has been going for 2 weeks I believe. The team is now ready to make the next step, which is migrate some of the legacy code into proper MVC members.

I would suggest you to follow the same path. You have one advantage over them though, that your views are already groovyfied. Switching to full Griffon views shouldn't be much of a trouble. I would highly recommend you to pay attention to Models and bindings. They will help you eliminate a lot of bolierplate code for keeping state up to date.

Cheers,
Andres

This is something that Dean Iverson (@deanriverson on twitter) can answer with full disclosure as he is the one working on a JavaFx 2.0 plugin for Griffon.
In short, yes it's possible to use GroovyFX and Griffon together but I can't say any more yet as I don't want to steal Dean's thunder.

Cheers,
Andres

Hi Mike,

You don't need to be a Groovy expert in order to take advantage of the framework. A great thing about Groovy code is that you can write it as if it were Java code, that is, the syntax is 98% close to Java. As time passes by and as you feel more comfortable with the language you can switch to a more idiomatic version.

However, we're aware that some people won't be able to make the switch (for a wide variety of reasons), that's why Griffon provides top-notch Java support as well. Yes, you can write a Griffon application in 100% Java code. The Griffon Guide has an entry about that topic here

http://dist.codehaus.org/griffon/guide/guide/13.%20Tips%20and%20Tricks.html#13.2%20Dealing%20with%20Non-Groovy%20Artifacts

Basically, you start by creating an application with the following command

griffon create-app sample -fileType=java

All artifacts (Controllers, Models, Views & Services) will be initialized using a Java based template. The Griffon APIs are Java and Groovy friendly. If you're curious about Groovy I would recommend you to pickup to great books:
- Groovy in Action 2nd edition (currently in MEAP)
- Programming Groovy by Venkat Subramanian

Cheers,
Andres

Hi Jeff,

Considering that you already have a combined codebase I'd say you're in a good position to make the switch.
Bear in mind that Griffon lets you mix & match Groovy and Java code in all possible combinations, that is. you can have a Java based controller with Groovy based Models and Views for example; or you can have every single member written in Java or Groovy; it's up to you.

Migration depends on how tightly coupled are the current components/classes of your application. If it's easy to identify which properties belong to a Model, which methods can be refactored into controller actions and what can be pushed to the service layer then you shouldn't have much trouble.

You can also drop your current codebase into src/main and make shell controllers/services that delegate to that codebase. Later you can refactor the code to move it to their respective places in each MVC member artifact.

Cheers,
Andres

Yes, it's just Swing underneath. Griffon does not provide a new UI toolkit for you to learn.
Rather it provides the building blocks for creating applications without red tape

Rob Spoor wrote:

Andres Almiray wrote: - threading problems. Tell me again, what happens if you call SwingUtilities.invokeAndWait() inside the EDT?

You get an IllegalStateException Error. One that can be prevented by checking EventQueue.isDispatchThread. Nothing hard about that.

Precisely. Not _that_ hard but troublesome. Which means you have to be sure in which thread you're currently on. Which means your code will usually look like this

Runnable block = new Runnable() { public void run() { // do the stuff you need } }; if(SwingUtilities.isEventDispatchThread()) { block.run(); } else { SwingUtilites.invokeAndWait(block); }

What Griffon proposes is that you write that code like this

execSync { // do the stuff you need }

or if you prefer to write in in Java

execSync(new RunnableWithArgs() { public void call(Object[] args) { // do the stuff you need } });

Follow the same principle for executing code asynchronously inside the EDT (invokeLater) and outside (spawn a new thread or use a ThreadPool). That's what Griffon does for you. That's what an application framework should do for you.

Rob Spoor wrote:

Item #4. Threading in Swing apps is hard.

No it's not. At least, not when you know about how the EDT works.

And yet we keep looking at code sample that open DB connections inside ActionListeners bound to buttons for example. The Swing threading rules are well explained but it's so easy to break them. Granted, Griffon does not claim to have solved the problem completely, developers still must exercise a level of restrain from executing code willy-nilly. Some additional things Griffon does for you are:

- all controller actions are automatically executed outside of the EDT. This execution is scheduled using a ThreadPool configured to make the most of the currently available processors.
- the previous setup can be overridden using either configuration flags or annotations
- threading becomes so important that every single artifact is aware of these concerns and gains the ability to fire executions in the appropriate thread.

And no. I'm not advocating to get away from Swing, far from it.

Cheers,
Andres

Hi Fredrik,

Yes. All Groovy code is compiled to .class files before launching the application.

As a matter of fact all Groovy based artifacts inherit/extend the same basic classes you would use if you choose Java as your main language when developing a Griffon application. The Griffon compiler is smart enough to weave the required types given each artifacts' placement, naming convention and responsibilities.

Views built with the SwingBuilder DSL behave in the same way as plain Java views. What you gain is a declarative way to express the UI hierarchy plus a more concise syntax.

Cheers,
Andres

Hi Greg,

Yes, as a matter of fact chapter 13 (Grails integration) discusses how you can setup a Griffon front-end for a Grails powered back-end using a REST approach to communicate both ends.
The revised edition of the same chapter (not the one currently available in MEAP) points you to SOAP resources as well.

The Griffon Plugins page has pointers to several options at your disposal for establishing communication with the outside world:
- http://griffon.codehaus.org/Rest+Plugin: lightweight REST client
- http://griffon.codehaus.org/Wsclient+Plugin: SOAP client
- http://griffon.codehaus.org/Xmlrpc+Plugin
- http://griffon.codehaus.org/Jabber+Plugin
- http://griffon.codehaus.org/Rmi+Plugin
- http://griffon.codehaus.org/Hessian+Plugin
- http://griffon.codehaus.org/Jml+Plugin: Microsoft's Messenger protocol

Related plugins:
- http://griffon.codehaus.org/Protobuf+Plugin: Google's protocol buffers
- http://griffon.codehaus.org/Avro+Plugin: custom serialization format/protocol
- http://griffon.codehaus.org/Thrift+Plugin: custom serialization format/protocol

Cheers,
Andres

Stephan van Hulst wrote:If you're comfortable with Swing, use that. I have the feeling Griffon was designed for people who never got into Swing.

Actually, Griffon was designed by seasoned Swing developers that were tired of writing the same boilerplate all over again, falling through the same traps every single time. What traps?
- lack of JDK5 features: yes, lack of generics and deeper integration with the collections library (ever wanted to iterate over a ListModel as you do with a java.util.List?)
- Swing Application Framework (JSR 296): killed before it got interesting
- Beans Binding (JSR 295): killed as well. The expert group even proposed yet another expression language in order to deal with declarative bindings.
- threading problems. Tell me again, what happens if you call SwingUtilities.invokeAndWait() inside the EDT?
- code verbosity. This one is attributable to the Java language itself

We took all of these things (plus a few more irritating problems) and solved each one of them.

We can't do anything about the standard Swing API but we certainly can enhance the classes via Groovy metaprogramming.

Item #1, fixed with something like this http://jira.codehaus.org/browse/GRIFFON-44
Now you can iterate over a ListModel, or ComboBoxModel or even a TableModel like this
for(element in comboBox.model) { ... }
I'm aware you can do this in plain Java but the code wouldn't look as succinct (unless you hide away the wrapping code in statically imported factory methods).

Item #2. Griffon takes inspiration in JSR 296 as a matter of fact. There's a clear application lifecycle manager (and lightweight to boot!).

Item #3. Binding, including both directions is as easy as pie with Groovy and not so difficult in Java. Have a look at sample code from the manual.
package sample; import java.util.Map; import groovy.util.FactoryBuilderSupport; import griffon.swing.BindUtils; import griffon.util.CallableWithArgs; import org.codehaus.griffon.runtime.core.AbstractGriffonView; public class SampleView extends AbstractGriffonView { private SampleController controller; private SampleModel model; public void setController(SampleController controller) { this.controller = controller; } public void setModel(SampleModel model) { this.model = model; } public void mvcGroupInit(Map<String, Object> args) { buildViewFromXml(args); FactoryBuilderSupport builder = getBuilder(); /* * Equivalent Groovy code * bind(source: input, sourceProperty: 'text', * target: model, targetProperty: 'value', * converter: {v -> v? "FOO $v" : 'BAR'}, * validator: {v -> * if(v == null) true * try { Integer.parseInt(String.valueOf(v)); true } * catch(NumberFormatException e) { false } * }) */ BindUtils.binding() .withSource(builder.getVariable("input")) .withSourceProperty("text") .withTarget(model) .withTargetProperty("value") .withConverter(new CallableWithArgs<String>() { public String call(Object[] args) { return args.length > 0 ? "FOO "+ args[0] : "BAR"; } }) .withValidator(new CallableWithArgs<Boolean>() { public Boolean call(Object[] args) { if(args.length == 0) return Boolean.TRUE; try { Integer.parseInt(String.valueOf(args[0])); return Boolean.TRUE; } catch(NumberFormatException e) { return Boolean.FALSE; } } }) .make(builder); /* * Equivalent Groovy code * bind(source: model, sourceProperty: 'value', * target: input, targetProperty: 'text') */ BindUtils.binding() .withSource(model) .withSourceProperty("value") .withTarget(builder.getVariable("output")) .withTargetProperty("text") .make(builder); } }

Item #4. Threading in Swing apps is hard. It's very easy to shoot yourself in the foot, so what can you do about it? You mitigate the problem with threading facilities. Every single Griffon application has access to correct implementations of threading execution options. Every single Griffon artifact (that is, Models, Views, Controllers, Services (and additional artifacts provided by plugins)) have access to those facilities.

Item #5. What do you do to combat Java's verbosity? Switch to a JVM language that gives you more bang for your buck: you write less and keep the same behavior; that's what Groovy is for in this case. However considering that Groovy is not the only alt JVM lang in town, we support other languages as well: Scala, Clojure, Mirah, Jython and Erlang (all of them just one plugin install away). Not to mention that Java can be used as well, in conjunction with any (or none) of those languages.

So, if plain Swing & Java plus maybe Maven to deal with build/package/deploy/dependency management are good enough to deal with all of these concerns then I guess Griffon wouldn't have been born in the first place.

Cheers,
Andres

OK let's see. Swing is an UI toolkit, and as such it comes with
- a rendering pipeline
- a set of UI components
- options for customizing how components are drawn
- ability to build your own components from scratch or by composition

But you need more than that to build an application, you need:
- a basic and recognizable structure
- the means to build, package and deploy the application
- a way to express optional dependencies (and believe me, you'll have additional dependencies)
- probably shield yourself from the Swing Bane, a.k.a, the Swing threading execution rules
- helper classes that tie things together

And that's precisely what Griffon offers (and more), wrapping all things together with a Groovy DSL cover.
It's true that the Griffon manual covers a lot of ground and topics. Truth is you only need to go through it fully if you really want to know all the gritty details. The basic building block of the framework, an MVC group, was designed to help you build the application organically. It's also true that there are many options you can choose from in Griffon, fact is you can let the framework decide most of the stuff for yourself, that's the power of Convention of Configuration.

Cheers,
Andres