Tag Archives: model

JavaFX Forms Framework Part 5


Tilghman Island

Tilghman Island

This is the final part in a five part series of entries creating a proof of concept for a JavaFX forms framework.  Here, I will conclude with some thoughts relating to using JavaFX to build a forms framework. If you are here for the first time I recommend going to the beginning: Part 1 “What is a Forms Framework?.  By now we should know why it is very important to understand the MVC architectural pattern and how it applies when building applications (especially form type applications). The forms framework helps provide manageable code and clear boundaries for both the designer role and developer role. This allows a designer to focus on the usability (look and feel) of the application meanwhile allowing the developer to focus on the service components and business logic. Next, I want to talk about the popular and ambiguous acronym ‘RIA’ (better known as rich internet application).  You are probably wondering what does RIA have anything to do with a MVC forms framework?  Well, let me try to explain. To some people ‘RIA’ is a buzzword and to some people its actually a tangible software development platform. I have a hunch that some people are not convinced they should jump on the bandwagon or not.  But whatever you choose to agree with, I believe as we slowly become convinced what RIA is and how it fits into our domain an MVC forms framework should always be considered when building larger scale forms based applications. I want to begin by discussing RIA from a Swing/Web/Enterprise developer point of view (considering that’s my background).

Swing/Web/Enterprise Developer

Like most of us who had previously come from an enterprise background noticed the Web 2.0 looking applications getting lots of attention.  Whenever I hear the word RIA, I really think that it should be called  “Rich Applications” and drop the ‘I‘ because all clients should look and feel great regardless if they were connected to the Internet or not. So, usability is key to making client side applications connect with users. This year I was fortunate to go to JavaOne 2009 and experience all things rich client (some enterprise) and one of my last sessions was about Craftsmanship in Software from Ben Galbraith. He mentions “the most important aspect of software creation: crafting an amazing user experience.” This makes me realize that as applications become richer, consumers will demand richer content (a vicious cycle).  But,  I still believe enterprise-y looking applications (not so flashy)  using Swing will still have its place in the world of rich client. When developing rich clients I’ve found Swing GUI development to be quite pleasant to work with, however at times certain things  seem pretty hard to do such as animation, binding, and validation.

Martin Jet Pack

Martin Jet Pack


If you are like me who enjoys software development will learn over time some good proverbs and principles that surface. One saying I’ve heard was “Letting Go of Your Bananas”, which can be applied to your life and not just software. In terms of software I feel its OK to let go of some things and embrace other things. So, it’s healthy to be early adopters, but always keeping in the back of your mind past concepts that are tried and true.  An example would be “Swing/Web Frameworks” where everyone created their own or used the vast number of open-source libraries out there.

Rocket man - melbourne show (Fir0002/Flagstaffotos)

Rocket man - melbourne show (Fir0002/Flagstaffotos)


As the JavaFX community matures I believe forms based frameworks, GUI tools and application frameworks should start appearing, making many developers’ jobs much easier. I think there will be a day where Java developers around the world will not think ‘Swing is Hard‘, but say ‘JavaFX is extremely Easy‘. I encourage you as the reader to explore and learn as much as you can about JavaFX because it’s not every day that you can start from the beginning to learn a soon-to-be-popular language. Enjoy!

JavaFX Forms Framework Part 4


(Updated)** Added JavaFX Script code to represent a display panel mapping instead of the XML format example in the ‘User of the API (Application Developer)’ section.

(Thanks! Andres Almiray)

This is the forth installment of a series of blog entries relating to a proof of concept for a JavaFX Forms Framework.

Chairman and Co-Founder, Sun Microsystems. (person on the left)

Chairman and Co-Founder, Sun Microsystems. (person on the left)

If you missed the beginning of the series you may go to Part 1, Part 2 and Part 3. Before we discuss this section I want to recap for those who have been following along. Part 1 explains “What is a Form based framework?” and a demo application. Part 2 describes the requirements and design. Part 3 are the implementation details. As we near the end of the series in Part 4 we will discuss enhancements that could be added to improve the FXForms framework. Below is a summary of the features from two user perspectives, first being the ‘User of the API’ and secondly the ‘User of the application’. I will only explain in detail the ‘User of the API‘ perspective.


User of the API (Application Developer)

  • Mapping files (forms to beans)
  • GUI Component factory – make use of other controls

User of the application (User experience)

  • Icon error, warn, info indicators overlay
  1. Override images to load and position when validation occurs.
  2. Error / Exceptions / Global errors
  3. Tooltips
  • Transitions to forms (fading, sliding, etc)
  • Focus Policy
  • User feedback (block gui visually) busy, indeterminate state.
  • Skinning and Themes for Forms
  • Context sensitive help
  • Sound effects

User of the API (Application Developer)

The goal here is to make life easier for the Application developer developing JavaFX Forms.

The features are as follows:

  • Mapping Files – This provides custom bindings to field elements and bean properties. Also provides mappings for actions and controls.
  • GUI Component factories – Display panel managers (form manager) to assemble and wrap components to provide presentation model pattern behavior.

1) Mapping files (forms to beans) – Display panels (forms) will be mapped to a particular Java Bean class. Each field will be mapped based on the bean property ‘name’ and the GUI widget’s ‘id’ attribute. When defining a display panel in XML it is a good idea to create a DTD or Schema, but for brevity I will not create them, and I will describe each XML element in detail such as default values, enumerated types, etc. an object representing fields and their corresponding bindings and actions will be called a ‘Display Panel Metadata’ object.

When mapping fields and controls here are situations you will encounter:

  • Nested properties – Nested objects ie: Person references an object Address with a property called city. (use  ‘address.city‘)
  • Mapping bean properties with different GUI component ids. ie: Person bean property is ‘fName‘ and the TextBox’s id is ‘firstName
  • Custom bindings (list models single select, multi-select and contains all). ie: ListBox containing all objects in a collection owned by Person.
  • Action mappings to events and controls. ie: Buttons are mapped to functions in modules (script level functions).

Below is an example of an XML mapping file might look like:

Please skip this mapping file and go to JavaFX script code right after it. XML mapping file is replaced by JavaFX script code.

  **** NO LONGER IN USE, DEPRECATED,                                  *****
  **** Please DISREGARD.
  **** REPLACED WITH JavaFX DisplayPanelMetadata class                *****
  - Full Name Form Display Panel -
  This describes all gui widgets and actions.
    * Text control bound to a different named bean property 'fName'
    * Radio buttons bound to bean property 'likesFood'
    * Spinner control bound to bean property 'dateOfBirth'
    * Spinner control bound to bean property 'shoeSize'
    * List or combo control bound to nested bean property 'address.state'
    * List box control bound to nested bean property 'contacts' (collection)
    * List box control bound to nested bean property 'relatives' (collection)
    * Button control bound to action handler 
  <displayPanel id="FullNameForm" 

    <!--First Name Field -->
    <textControl id="firstName" name="fName"/>

    <!-- Likes Food (yes or no)-->
    <radioButton id=”no”
    <radioButton id=”yes”

    <!--Date of Birth Spinner control-->
    <spinner id=”dob”

    <!--Shoe Size Spinner control-->
    <spinner id=”shoeSize”
      bindingType=”NUMBER” />

    <!--US State Drop Down List control-->
    <listModel id="address.state" 
      displayName="${name}" />

    <!--Contacts List Box control-->
    <listModel id="contacts" 
      displayName="${firstName} ${lastName} – (${id})" 
      bindingType="MULTIPLE_SELECT" />

    <!--Relatives List Box control-->
    <listModel id="relatives"
      displayName="${firstName} ${lastName} – (${id})" 
      bindingType="CONTAINS_ALL" />

    <!--Save Button control-->
    <action id=”saveAction” 


Line 15-19 Defines a form or display panel.

Line 22 Maps a text field when a bean property and GUI control are named differently. Framework should assume if the name and id are the same and at text control developer doesn’t need to map. This keeps the XML mapping file smaller.

Line 24-32 Custom binding for radio controls. Other scenarios exist, but for a simple boolean value selection the ‘BOOLEAN_TYPE’

Line 34-38 Custom binding for a JSpinner. The bean property is a java.util.Date.

Line 41-47 Custom binding for a JSpinner. The bean property is an int.

Line 49-52 Custom binding for a dropdown list. The bean property is a java.lang.String. Notice the nested properties. When a form displays a nested property on the same form.

Line 54-58 Custom binding for a List box. This is not bound to a bean property but a populated list allowing the user to select multiple items.

Line 60-65 Custom binding for a List box. This is bound to a bean property referencing a collection of objects. Notice the “CONTAINS_ALL” which means all items in the list box are synchronized inside the collection.

Line 67-72 Action mapping for a button on the form. They are named so actions can be reused such as menu or toolbar.

Disregard the XML mapping file above. The same representation is below in JavaFX script code defining a display panel.

**IMPORTANT NOTE: Since JavaFX is a declarative language which can achieve the same thing as a mapping file, I have re done the XML in JavaFX below:

var displayPanelMetadata:DisplayPanelMetadata =  DisplayPanelMetadata {
  id: "FullNameForm"
  className: "com.company.forms.FullNameForm"
  reuseForm: true

  // Custom bindings to field elements
  customBindings: [
    // First Name Field 
        id: "firstName"
        name: "fName"

    // Likes Food (yes or no)
    RadioButtonMetadata {
        id: "no"
        name: "likesFood"
        selectedValue: "false"

    RadioButtonMetadata {
        id: "yes"
        name: "likesFood"
        selectedValue: "true"

    // Date of Birth Spinner control
    SpinnerMetadata {
        id: "dob"
        name: "dateOfBirth"
        bindingType: "DATE_TYPE"

    // shoe size
    SpinnerMetadata {
        id: "shoeSize"
        name: "shoeSize"
        defaultValue: "5"
        minimumValue: "2"
        maxValue: "18"
        stepValue: "1"
        bindingType: "NUMBER_TYPE"

    // state selection
    ListModelMetadata {
        id: "address.state"

    // contacts List Box control (not bound to bean)
    ListModelMetadata {
        id: "contacts"
        displayName: "${firstName} ${lastName} – (${id})"
        bindingType: "MULTIPLE_SELECT"

    // relatives(family) List Box control
    ListModelMetadata {
        id: "relatives"
        name: "relatives"
        displayName: "${firstName} ${lastName} – (${id})"
        bindingType: "CONTAINS_ALL"
  ] // custom bindings sequence

  // Save Button control
      ActionMetaData {
      name: "saveAction"
      module: "com.company.domain.forms.personactions"
      functionReference: "updatePerson"

    ] // actions

} //displayPanel

Line 0-3 Defines a form or display panel.

Line 8-11 Maps a text field when a bean property and GUI control are named differently. Framework should assume if the name and id are the same and at text control developer doesn’t need to map. This keeps the metadata mapping info smaller.

Line 14-19 Custom binding for radio controls. Other scenarios exist, but for a simple boolean value selection the ‘BOOLEAN_TYPE’

Line 29-34 Custom binding for a JSpinner. The bean property is a java.util.Date.

Line 37-45 Custom binding for a JSpinner. The bean property is an int.

Line 48-52 Custom binding for a dropdown list. The bean property is a java.lang.String. Notice the nested properties. When a form displays a nested property on the same form.

Line 55-60 Custom binding for a List box. This is not bound to a bean property but a populated list allowing the user to select multiple items.

Line 63-69 Custom binding for a List box. This is bound to a bean property referencing a collection of objects. Notice the “CONTAINS_ALL” which means all items in the list box are synchronized inside the collection.

Line 74-77 Action mapping for a button on the form. They are named so actions can be reused such as menu or toolbar.

2) GUI Component factory – make use of other controls

Forms can be retrieved and populated using convenient factory functions. When assembling a form and mapping properties the underlying implementation may have a configuration file to have modular ways to specify what controls will be used for binding controls.

var personForm = FormManager.retrieveForm(personBean, 'FullNameForm');


While some features of the ‘User of the Application‘ perspective may seem debatable, I believe a forms framework should at least have all the features described in the ‘User of the APIs‘ perspective. As a framework implementer one should design a plug-able architecture for custom components. Components should be wrapped and registered when assembling a form. I’m sure there are many features I have not mentioned.  As JavaFX matures I believe GUI builders providing WYSIWYG development will eventually allow third party GUI controls to be added to their control palette. Next, I will discuss Part 5 Concluding thoughts.

Like always, any comments are welcome!

JavaFX Forms Framework Part 3


Matthew 7:13-14

Matthew 7:13-14

This is the third installment of a series of blog entries relating to a proof of concept for a JavaFX Forms Framework. If you missed the beginning of the series you may go to Part 1 and Part 2. We will take a look at code snippets relating to how the FXForms Framework was implemented. If you want to jump right into the code you may download it here or browse the source code here from the JFXtras Samples area. To those who are following the series will notice similarities to JGoodies Bindings and Validation libraries, it is because of those libraries and presentations which basically inspired me to create this MVC forms framework in JavaFX.

Disclaimer: Most of the code snippets will deal with the user of the API’s perspective as opposed to the implementer of the API’s perspective in order to keep the blog entry short. I will try my best to touch on areas regarding the framework’s underlying implementation. I advise people to check the code project out, review it and run it.

A thing I’d like to bring to your attention is that I decided to refactor the code a little and add a new feature to the FXForms Framework. I refactored the form to reference an instance of a presentation model instead of inheriting from it. As I mentioned in Part 2 the form will be independent of the presentation model. This provides different validation contexts while reusing the same form. An example of this situation is when a user uses a form to ‘Add’ information versus an ‘Edit’ of the form information. The new feature added is the ability to validate a field as the user is typing into the text box and positions an icon to indicate an error, warning or information to the user. Another feature might be to add tool tips when the mouse hovers over the icon similar to JGoodies’ IconFeedbackPanel behavior in Java Swing. Before going further into the implementation details you may want to launch the demo to get a feel for the behavior of the entry form with validation and icon indicators.




  • Enter numbers or symbols into the first, last and middle name field.
  • Click on the check box to swap the JavaBean for the form.
  • Observe the underlying bean values changing.

Next are the steps on how to develop the demo using the FXForms Framework.

Developer Steps

  1. Create a JavaBean representing a domain object.
  2. Create a Presentation Model with validation for a Form.
  3. Create a Form
  4. Associate a Presentation Model to Form
  5. Use the Form in an application

Detailed Steps

Step 1. Create a JavaBean representing a domain object.

// Java
public class PersonBean extends DomainModel{
    public static final String FIRST_NAME_PROPERTY = "firstName";
    public static final String MIDDLE_NAME_PROPERTY = "middleName";
... // more strings naming properties
    private String firstName;
    private String middleName;
... // more attributes

     * Returns first name of the person.
     * @return
    public String getFirstName() {
        return firstName;

     * Sets the first name of the person.
     * @param firstName
    public void setFirstName(String firstName) {
        String old = this.firstName;
        this.firstName = firstName;
        firePropertyChange(FIRST_NAME_PROPERTY, old, firstName);
... // the rest of the methods.

PersonBean.java – A domain object containing property change support.

DomainModel.java – Abstract base class containing property change support.

Step 2. Create a Presentation Model with validation for a Form

As I mentioned earlier about reusing the same form with different presentation models. Below you will see an ‘Add Form’ with validation on the Last Name field. The error icon indicates that the last name may not contain symbols and numbers, but allowing letters, apostrophe or hyphen in the name. You will notice the red error icon beside the ‘last name’ text field.

Add Form validation on last name field.

Add Form validation on last name field.

    // JavaFX
    var personForm:NameForm = NameForm{
    personForm.presentationModel.jBean = new PersonBean();

Next, you will see an ‘Edit Form’ with no validation on the ‘Last Name’ field. But, there is validation on the ‘First Name’ field. The warning icon indicates that the first name can contain symbols and numbers, letters, apostrophe or hyphen, but isn’t recommended. You will notice the yellow warning icon beside the ‘first name‘ field.

Edit Form no validation for Last Name field

Edit Form no validation for Last Name field

    // JavaFX
    personForm.presentationModel = domain.model.personpresentationmodel.EditPersonPM{}
    personForm.presentationModel.jBean = personBean2;

*Note: The examples above are two hypothetical use cases, I mocked up those forms to help illustrate different validation contexts. The demo app uses an edit presentation model that does validate on the ‘last name‘ field.

Edit Person Presentation Model w/Validation

// JavaFX
public class EditPersonPM extends fxforms.model.model.PresentationModel {

   /** Validate the first name field */
   var validateFirstName =  Validator{
       public override function validate(value:Object){
           return validateName(value, PersonBean.FIRST_NAME_PROPERTY, "Warning");
... // more validators
   postinit {
// Script level function
 * Using regular expression allow letters, apostrophe, hyphen
function validateName(value:Object, propName:String, messageType:String){ // use friendly names, short names, etc.
    var results = ValidationResult{};
    var strValue:String = value as String;
    var found:Boolean = Pattern.matches("^[a-zA-Z,'.\\-\\s]*$", strValue);
    if (not found) {
        var message:FieldMessage = FieldMessage{
            errorMessage:"No symbols in names except - or ' (apostrophe)"
    return results;

Line 01: Class EditPersonPM extends fxforms.model.model.PresentationModel
Line 04: var validateFirstName is an instance of a Validator
Line 12: Adds all Validators to the presentation model
Line 21: Script level function to be used in each validator
Line 24: Regular expression to allow letters, apostrophe and hyphen characters only.
Line 26: Creation of the message when Validator validates.

personpresentationmodel.fx – The edit presentation model for a person name form.

model.fx – Contains presentation model and value model implementation.

validation.fx – Contains the validator, message, result classes.

Step 3. Create a Form

Edit Person Form (Screen mockup)

0 full name panel
+-1------------------------+ // VBox with 3 things
! +-2--------------------+ ! // HBox with 2 things
! ! [ 3 ] [ 4           ]! ! // Label(section) and Label(title)
! +----------------------+ !
! +-5--------------------+ ! // HBox with 2 things
! ! [ 6 ] [ 7  ]         ! ! // Label(spacer} and Text(instructions)
! !                      ! ! // wrapping text abilities
! +----------------------+ !
! +-8--------------------+ ! // HBox with 2 things
! ! +-9---+ +-10-------+ ! ! // VBox_9(labels) Vbox_10(textbox)
! ! ![11] ! ! [15]     ! ! ! // Label(lastname) TextBox()
! ! ![12] ! ! [16]     ! ! ! // Label(firstName) TextBox()
! ! ![13] ! ! [17]     ! ! ! // Label(mi)  TextBox()
! ! ![14] ! ! [18]     ! ! ! // Label(suffix)  TextBox()
! ! +-----+ +----------+ ! !
! +----------------------+ !

NameForm inherits from Form
Form inherits from CustomNode

// JavaFX
public class NameForm extends fxforms.ui.form.Form {
   public override function create():Node{
        // 0 main panel
        var mainPanel:Panel = Panel{
        ... // more layouts and widgets

        var firstLabel:Label = Label {
            text: "First Name"
            font : Font {
                size: 18
            layoutInfo: LayoutInfo { minWidth: 100 width: 150 maxWidth: 200 }
        ... // more code
        var lastNameTextBox:TextBox = fxforms.ui.controls.MyTextBox {
        var miNameTextBox:TextBox = fxforms.ui.controls.MyTextBox {
        ... // more fields

        // *** NOTE: This is for easy lookup. And relating to Scene.lookup(id) bug in 1.2.
        guiFields = [lastNameTextBox, firstNameTextBox, miNameTextBox, suffixNameTextBox];
        return mainPanel;
    } // create()
} // NameForm

NameForm.fx – This represents a Form containing a person’s name information.

form.fx – This is the base class which contains the presentation model for forms binding behavior.

controls.fx – This contains all registered GUI controls for observing value model value changes. Currently only one control exists the TextBox control.

*Note: The ideal way to build forms is using the JFXtras MigLayout library. To learn more take a look at Dean Iverson’s blog entry called “MigLayout for JavaFX Reloaded“.

Step 4. Associate a Presentation Model to Form

// JavaFX
var personForm:NameForm = NameForm{
    translateX: bind slideFormX
var personBean2:domain.model.PersonBean = new domain.model.PersonBean();

// set presentation model with domain object
personForm.presentationModel.jBean = personBean2;

Line 02: Associate presentation model to form
Line 05: Create an instance of a JavaBean
Line 12: Bind bean to presentation model and form

Once the presentation model and form are assembled binding an existing Java object is a snap. In part 4 on enhancing this process would be to create a factory to obtain meta information of the form to retrieve nested properties within a POJO/JavaBean off of the JavaFX main thread (desktop profile is the EDT). This effort will help alleviate from the dreaded Hibernate lazy init exception when using detached objects. So, making sure you don’t block the GUI thread is a big deal when it comes to user experience.

Step 5. Use the Form in an application

    var switchPersonButton:CheckBox = CheckBox {
            text: bind personToSwitchText
            width: 100
            translateX: 5
            translateY: bind mainScene.height - switchPersonButton.height - 5
            allowTriState: false
            selected: false
            override var onMouseReleased = function(e:MouseEvent):Void {
                if (selected){
                   personToSwitchText = "Sponge Bob";
                   personForm.presentationModel.jBean = personBean1;
                } else {
                   personToSwitchText = "Squidward";
                   personForm.presentationModel.jBean = personBean2;

    var mainScene:Scene = Scene {
        fill: LinearGradient {
                    startX: 0
                    startY: 0
                    endX: 0
                    endY: 1
                    stops: [
                        Stop { offset: 0.1 color: Color.ORANGE },
                        Stop { offset: 1.0 color: Color.YELLOW },
        content: [personForm, switchPersonButton, backButton, nextButton]

Main.fx – The main application file to launch the application

Value Model

The ‘Value Model‘ is probably the most important aspect of how the Forms binding works. The value model is a model that holds a single value that notifies registered listeners that a value has changed. Registered listeners will likely be GUI controls and JavaBean properties. Bidirectional binding occurs when a bean property value changes, which notifies the value model which updates the  GUI control value. This holds true when going in the other direction too, such as the user changes the value of the GUI control which notifies the value model which updates the JavaBean property value.

model.fx – Contains presentation model and value model implementations.


I feel the implementation of the fxforms framework using JavaFX was extremely easy and is a lot less code compared to a Java equivalent of a Swing/SWT forms framework, also carrying additional overhead using 3rd party libraries for binding and validation. As JavaFX matures with more controls the forms framework would need to be flexible enough to add any controls to handle custom bindings such as list models.  Next we will look at Part 4 Enhancements . As always any feedback is welcome!


Validation presentation by Karsten Lentzsch – http://www.jgoodies.com/articles/validation.pdf

JGoodies: http://www.jgoodies.com/

JGoodies Support: http://www.jgoodies.com/products/purchase.html

The Unknown JavaBean by Richard Bair – http://weblogs.java.net/blog/rbair/archive/2006/05/the_unknown_jav.html

JavaFX – JMS Unexpected Null Pointer Exception http://blogs.sun.com/clarkeman/entry/javafx_jms_unexpected_null_pointer

JFXtras Community Site – http://jfxtras.org/portal/home

JavaFX Forms Framework Part 2

Full Name Form with Validation

Full Name Form with Validation


This is the second installment of a series of blog entries relating to a proof of concept for a JavaFX Forms Framework. Before I specify the requirements and a simple design of the FXForms Framework, I want to follow-up on comments about tough issues relating to enterprise application development and JavaFX. If you recall in Part 1 we discussed about MVC form based technologies. I listed many technologies that may only provide a means to separate content from presentation, but they don’t necessarily deal with real plumbing problems such as Threading, Binding, Validation and Transactions.  I believe these issues are one of the most important areas that must be understood in the JavaFX world, thus positioning itself as a premiere enterprise development platform (not just rich client a hint to Oracle).  As Richard Obaldeston mentions in the comments regarding enterprise level support for JavaFX controls similar to Swinglabs / SwingX. I cannot speak of the future concerning Swing & Swinglabs, but I believe the JavaFX teams are well aware of them, (very much so) due to the fact that the same project owners of the SwingX-WS are leads on the JavaFX teams (I don’t mean to put them on the spot).  Many of these difficult issues are mostly solved in the Browser based Web Application Development world and can also be done in the JavaFX world (Check out Exadel). Of course I can’t answer all the hurdles faced in just one blog entry especially because every enterprise application has varied types of architectures such as (Corba, RMI, EJB, Soap, RESTful, JSON, Jini, JMS, DAO, JDO, JDBC, JNI, etc). It would literally take a book or two. But, I will try to address some of them later in this blog as we discuss JavaFX and Java interoperability. One should always re-evaluate one’s architecture to adhere to best practices or industry standards and conventions. However, some standards seem to stall or are slow to be accepted (JSR-296 or JSR-295) with many reasons of course. It is often the nature of the beast when it comes to new technology solutions and refactoring that subsequently boils down to when and how you want to pick your battles. As readers of this blog for the first time who might be new to JavaFX or Java Swing I strongly encouraged you to explore and learn about the pitfalls of thread safety, asynchronous behaviors, best practices, and UI concepts like (UI blocking, disabling, progress bar, etc.) . So, let’s get started with requirements and the analysis phase of our FXForms Framework.


My main goal of these series of blog entries are to share with others my experience with creating an application called iSF86 which hopefully will end up in the Java App Store and make tons of cash so I can quit my day job like Ethan (wishful thinking). iSF86 is an application which contains many form elements to capture a person’s information to apply for a job doing classified work for the United States Government. When dealing with so many forms I thought of building a mini Forms Framework where domain objects can be mapped to forms. The application will save a person’s SF86 information locally as an XML file. This is purely a client-side application which doesn’t involve any server-side communications. Each form would be bound to domain objects in a bi-directional way. A domain object that is bound to an existing form can be swapped out with a different domain object, thus making the old bean ready to be garbage collected and unbound to the form. Important Note: One requirement is that the domain objects will be JavaBeans (see disclaimer below).

Disclaimer: For brevity, the requirements are for JavaBeans (change support) and not POJOs (there is a difference)! Yes, I know I said POJOs in Part 1, because I wanted to tackle the problem using byte code engineering for boiler plate code for property change support on POJOs, but it would be beyond the scope of the blog series’ goal. So, this tutorial is really geared for people migrating Swing/SWT applications to JavaFX applications.

FX Forms Framework Requirements:

  1. It shall bind JavaFX Forms to JavaBeans as domain objects
  2. It shall enable JavaBeans to be swapped in a JavaFX Form
  3. It shall provide validation on property values
  4. It shall provide Action bindings to controls

To keep the framework simple shown below is a list of features that the framework does not provide.  Interesting features will later be discussed in Part 4 Enhancements.

What the FX Forms Framework does NOT provide:

  • Application Framework Features (like JSR-296)
    • Application Lifecycle
    • Resource injection
    • Task Monitoring
    • Saved Preferences
    • Thread Pool
  • Forms Building
  • RCP Features
    • Window Docking
    • Menu bar
    • Etc.


Before going into the design I want to mention other technologies which provide beans to forms binding or RIA MVC capable. The mentioned technologies are primarily Java based. Some of my classes will use similar names because I’ve taken a lot of ideas from these frameworks in the past.  Here are just a few that come to mind:

As a reminder regarding rapid application development that there are two main areas on building applications quickly ‘Forms building’ and ‘Forms binding’. We will only focus on ‘Forms binding’. Ok, already! Let’s get to the designing.

User of the API

At times when it comes to API development I’m a fan of user driven design and the user of the API is who I’m targeting. So, I pretend the FXForms Framework is ready to be used. Below is the developer obtaining a JavaBean and setting it into some Form.

// normally loaded from external source
var personBean1:PersonBean = new PersonBean(); // change support enabled

// generate a form and bind to bean. Req #1
var personForm:NameForm = NameForm{

// subsequent time another domain object is loaded Req #2
var personBean2:PersonBean = … // loaded from external source.
personForm.jBean = personBean2; // old person bean is no longer attached

// set property to an invalid value. Req #3
// validator will fire to output error message

// create navigation panel area Req #4
var mainButtonForm:PresentationModel = MainButtonForm {
var nextButton:Button = mainButtonForm.getControl(‘nextButton’);
// simulate a mouse press to test action binding

Let’s step through the code to see what is happening and what the FXForms Framework will provide.

Line 1: Creating domain object or loading from external source. Notice the new on the PersonBean (Java Object).

Line 8: Instantiating a Form to use the current JavaBean loaded. All the properties will be bound to form elements bi-directionally. Changes in the GUI will affect properties and changes to the bean properties will change the GUI fields. (Requirement #1)

Line 14: Swapping a domain object with the existing form. Old bean is disconnected from the form and replaced with new bean. Presentation Model Pattern (Requirement #2)

Line 17: Validation of a property when set with invalid data. The user can type into the textbox to fire the validator code. ValueModel updated (Requirement #3)

Line 20-25: A button panel form has buttons mapped to actions. Command Pattern. Yes, this is strange but I will explain later. (Requirement #4)

You will notice the comment on line 25 where you could test a control such as obtaining a button independent of the application being launched (testing individual forms).  This brings up a good point when using MVC Frameworks.  In  the Swing world I highly recommend using FEST Swing a tool to test Swing applications with ease. Also, the team is working on FEST for JavaFX with a joint effort with the JFXtras team.

JavaFX and Java Interoperability

While the user of the API appears simple, it is the behind-the-scenes work that some may consider unorthodox when using a combination of Triggers, Bindings, Reflection, Threading, etc. Until the JavaFX teams expose (with JavaFX blessed code) better interoperability against Java and JavaFX, I will resort to techniques that are known and official. When using triggers on properties this enables us to follow the basic proxy pattern: where a property is changed you will have an opportunity to intercept the change and update value models, which also updates GUI widgets mapped to them. One concern is that object-based memory leaks could occur with inverse bind (Maybe we need a unbind keyword). Another problem is properly populating a form on or off the JavaFX’s main process thread (EDT on the desktop environment) without blocking the GUI thread or causing some race condition.  What follows are the necessary classes to implement the FXForms framework.

Class Design

// Java
DomainModel <abstract Java class>

// Java
PersonBean extends DomainModel <JavaBean>

// JavaFX
FieldSetter <mixin class> Adapter

// JavaFX
MyTextBox extends TextBox, FieldSetter

// JavaFX
ValueModel <adapter class>

// JavaFX
PresentationModel extends PropertyChangeListener <mixin class>
propertyValues: Map <String, ValueModel>
propertyValidatorMap: Map <String, List<Validator>
jBean: DomainModel // java class javabean inherit
propertyChange(changeEvent: PropertyChangeEvent):Void

guiControls:[] // Scene.lookup(id) is currently a bug in jfx 1.2

// JavaFX
NameForm extends CustomNode, Form, PresentationModel <JavaFX node>

// JavaFX

// JavaFX

// JavaFX


You will notice the NameForm inherits the PresentationModel mixin class which provides the controller functionality mixed in with the view. I’ve done this to make the example short Sometimes I’m not a big fan of inheritance especially in this case and decided to refactor in order to separate the “Presentation Model” from the “View Form” for form reuse.  There are situations such as reusing the same GUI form for “Adding” and “Editing“, but the validation of the form data is different. Developers may also create a concrete presentation model that inherits from the mixin class to be independent of the view so that it decouples the Form and the Presentation Model. An EditPresentationModel and an AddPresentationModel should be created to have two different validations using the same GUI form.  Again for a slim down version I’ve omitted the ability to consume an XML file detailing the form metadata and mappings such as actions, mandatory fields, validators, and custom bindings; the named property is the same name as the ‘id’ attribute on the JavaFX GUI form element (TextBox). I will discuss in Part 4 Enhancements. Relating to validation at some point I would like to provide a way to display warnings and error icons beside fields whenever a Validation Result is updated. The validation results will contain the error messages to be displayed. One last thing to mention is GUI component factories aren’t in the design. You will also notice when creating a TextBox I needed additional behavior, so I simply created a MyTextBox instead of something like var field1 = WidgetFactory.create(valueModel, “TextBox”) to wrap, return and put it into form.


This is surely not a thorough or complete design, but an attempt to demonstrate how to make a simple forms framework from scratch. Hopefully, I’ve captured the requirements and articulated the object relationships within the textual design (No UML sorry). Next, we will look into how to implement the FXForms Framework in Part 3. Please be advised that this design is subject to change as any development shop would.

Personal Note: Sometimes I wonder if Sun had focused on finishing the often highly controversial JSR 295 Beans Binding and Java Properties before JavaFX would it render this blog entry totally useless.

Any comments are welcome. Thanks!



JavaFX w/JMS 307-311 JavaFX RIA book Server Call Back- James Clarke updates code for JavaFX – Developing RIA book regarding Code Recipe for JMS pages 307-3011 http://tinyurl.com/lzej5x

Best practices: http://www.greggbolinger.com/blog/2008/11/11/1226423940000.html

Fuse http://weblogs.java.net/blog/joconner/archive/2007/11/index.html

Exadel, http://mkblog.exadel.com/ria/javafx-and-spring-crud/

Swing worker / swing/ http://java.sun.com/javase/6/docs/api/javax/swing/SwingWorker.html

Beans Binding: https://beansbinding.dev.java.net/

RESTful : http://jnb.ociweb.com/jnb/jnbAug2009.html

jfxtras JFXWorker http://jfxtras.googlecode.com/svn/site/javadoc/release-0.5/org.jfxtras.async/org.jfxtras.async.JFXWorker.html

Java Properties: http://tech.puredanger.com/java7#property

Fxbuilder: http://www.jroller.com/aalmiray/entry/griffon_gfxbuilder_fxbuilder_side_by

Disable Swing Container:http://weblogs.java.net/blog/alexfromsun/archive/2007/06/_enablingdisabl_1.html

Java Properties without Getters and Setters: http://www.artima.com/forums/flat.jsp?forum=270&thread=247837

Beans Binding (JSR 295) & Properties on JDK7: http://www.javalobby.org/java/forums/t101998.html

JSR 295: http://jcp.org/en/jsr/detail?id=295

RCP Spring rich- http://spring-rich-c.sourceforge.net/1.0.0/index.html


Oracle buys Sun : http://www.oracle.com/us/corporate/press/018363

JavaFX Forms Framework Part 1

Full Name Form with Validation

Full Name Form with Validation


Software developers creating form based applications will inevitably stumble across the single most important architectural design pattern “Model View Controller” or “MVC in short. This concept has paved the way for many frameworks which provide true separation of concerns. The main idea of these MVC frameworks are to separate content from presentation. In layman’s terms I call them “Forms Framework“. When building enterprise applications with a forms framework the ability to achieve rapid application development and developer productivity will increase greatly. I would like to create a series of blog entries (five parts) detailing a simple proof of concept of a mini forms framework. Below is a brief summary of the five part series:

Part 1 – What is a Forms Framework? Also a quick demo of a simple form application.
Part 2 Requirements and design
Part 3 Implementation details
Part 4 Enhancements
Part 5 Concluding thoughts

Other Form based technologies

Although the form based technologies listed above use vastly different ways to build form based applications, they all are basically using the MVC based architectural pattern. My intent is reuse existing Java domain objects POJOs while using JavaFX as a front-end thus providing a return on investment on legacy system domain models. While mature Java technologies like JAXB, EJB and Hibernate still dominate the Java enterprise the idea is to reuse what we already have.  JavaFX was developed from the ground up with MVC in mind such as the “Designer-Developer Workflow“. So, with a forms framework a Java Bean would bind to a Presentation Model and a JavaFX Form. I will call the mini forms framework “FXForms” framework throughout the series.


A form containing JavaFX textbox components to capture a person’s full name.


  • Check Box to toggle two people using the same form
  • Type and change information in fields, thus changing the underlying bean
  • Click on Next for a transition to next form.
  • Click on Back to return to form

Click here to run demo


Many who have already read my entry regarding JavaFX Presentation Model Pattern Using Binding. Here, I have decided to kick it up a notch and actually develop a mini forms framework to make forms development easier than ever.  JavaFX is an excellent choice to create nice looking GUI forms that will easily bind to your domain model. Next Part 2, we will take a look at requirements for a forms framework.