Avid JavaFX developers may have noticed that the JavaFX 2.0 APIs provide Window and Stage classes that may be roughly mapped to java.awt.Window and javax.swing.Frame. However there's no counterpart class for building dialogs. If you search for examples you'll find that the most commonly suggested solution is to configure an Stage instance. Here's how to do it with Griffon and a temporary MVC group.
The first step is to create a new MVC group, let's call it dialog for simplicity's sake (though you can pick *any* name you want).
$ griffon create-mvc dialog
This command creates the following files
- griffon-app/models/sample/DialogModel.groovy
- griffon-app/views/sample/DialogView.groovy
- griffon-app/controllers/sample/DialogController.groovy
$ griffon create-app sample --archetype=javafx
Alright. Now that we have a starting point for the new MVC group let's change each member in order, starting with the Model. The Model holds basic information that will be used to tweak the dialog's behavior and its looks
The Model defines two observable properties that can be used to specify a title and a textual content for the dialog. It also sets the default modality to true, which means the dialog will block its owner window. Next we move to the View where we can appreciate the model properties in action
Two things of important note about this piece of code
- the Model has JavaFX properties given that some properties were annotated with @FXBindable. These properties can be used with standard JavaFX bindings.
- Apparently you can't set alignment nor margins on the center component of a borderPane node. This is caused by a name clash between builder variables and borderPane pseudo nodes (bottom is not a real node, but a method call handled by the borderPane factory, hence "pseudo node"). What we see at the end of the View script is a temporary workaround by making direct usage of the JavaFX APIs.
We see two actions in this controller: one to show the dialog, the second to hide it. Both actions are annotated with @Threading(Threading.Policy.INSIDE_UITHREAD_SYNC) as they are only concerned with UI stuff, otherwise they would get executed outside of the UI thread and we'll get an ugly exception from the JavaFX platform. Notice how the show action configures a freshly created Stage instance. Now all that's left is make use of this dialog; the following controller shows both model and non-modal usages
In the modal action we make use of withMVCGroup. This method instantiates a new MVC group with the specified parameters taking special care of releasing any resources when the group is no longer needed, which is the case when the dialog is dismissed. Given that the dialog is modal the call to withMVCGroup waits until the dialog is closed. We see a different method used on the other action as the dialog is non-modal. createMVCGroup is the most common way to build an MVC group instance. Notice that this action sets the modality to false. Also, the name of the group instance must be calculated explicitly, as there's the potential of multiple dialogs of the same type being visible at any given time.
Keep on Groovying!
