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.

12 thoughts on “JavaFX Forms Framework Part 1

  1. Richard Osbaldeston

    How are you doing JavaFX binding with domain POJOs? I was wondering how you wire up PrestentationModels of remote beans, talking to an EJB/RMI backend – possible disconnected JPA beans in a simple two-tier app? AFAIK JavaFX objects arent really POJOs and dont support classic serialization, so no passing over EJB/RMI and binding a Java POJO would require all the hidden jfx binding support.

  2. carldea Post author

    My series will explain how I bind to domain POJOs.
    My current implementation will use simple reflection and making sure to be on the correct thread when setting properties on beans. Regarding JavaFX and serialization I am not using JavaFX objects as pojos at all. Also, as far as EJB/RMI I will address them in the other series. I want to keep things pretty simple for now and i’m kind of aware of the various persistent/rmi strategies hurdles. The detached object problem (hydration or better known as lazy init exception) maybe resolved with making sure your persistent framework can properly handle transaction management such as when to close your session, dirty reads, when to commit, etc. A similar solutions modeled after Web frameworks like Spring or plain Servlets is to use a servlet filter to proxy the beginning of a session to the end (http response). A similar approach would be taken on the JavaFX world.

    I hope this makes sense. If I am not clear please let me know. (oh, and be gentle with me my day job isn’t all Java, so I’m a little rusty)
    I will try my best to address these hard problems (which are often solved in the Web world). That’s is why I have called it a mini-forms framework to assist in building forms based applications quickly.



  3. Richard Osbaldeston

    That sounds like a much more worthwhile and interesting set of tutorials then Carl 😉 I’ve often complained in the past about the lack of ANY serious mention of the plumbing/threading/asynchronous (knockon latency, ordering concerns) headaches – I wanted swingx-blueprints to cover this kind of area. Seriously things like getting Swing talking to EJBs? not covered in any Swing books, ever. which is odd if you consider how important they are to server side Java. About as good as you get is endless two-tier/client-server JPA examples that execute all the logic on the EDT – hopeless. In many ways its a shamethe design of JavaFX has done little to ease this pain, EDT abuse is still the easiest path to take (if not even easier due to bindings) and proper EDT handling the hardest.. that relationship really ought to be reversed. Hope your not second guessing the JavaFX teams promised enterprise level support.. of which there’s little sign..? so well done kicking something off.

    Such articles/blueprints have been mooted before, but didnt really happen. Some of the comments may prove useful: check parts 1,2 & 3: and some of my reservations on reflection/dynamicproxy binding:

    – Richard

  4. carldea Post author


    Thanks for the encouragement. Although, my blog was really meant for gaming and GUIs, I also hope to help others learn how to build real business applications too. As far as Swing/SwingX I believe resources (able bodies) and priority shifts, tend to muddy the road map for Swing or All things Client. Imo companies often build their own frameworks and take OSS and not likely contribute back to the community in a big way. It appears Sun was doing most of the contributing. Regarding books that don’t want to cover these serious topics: I hope I can try to change that by creating real life examples like the ones you mentioned. Relating to EDT abuse, I believe the Forms Framework should theoretically shield the developer from having to mess with all the details of validation, callback behaviors, syncing etc. Relating to JavaFX teams promises: I wouldn’t say that I’m second guessing, but I would say higher level frameworks will fill in the gaps where they are not mature (Similar analogy when using Jdk 1.3/1.4 with Apache Commons APIs). I’m just happy there’s an HttpRequest facility. Regarding the BCEL strategies (enhancers, proxy handlers, etc) I may touch on it a little. To keep things simple I want assume the property change support is already there. I think depending what you are refactoring will depend on what strategy you will take. Example: Using domain objects from a Web application or using domain objects from a Swing application.

    Yeah, nice discussions with that blog entries from Gregg.


  5. Thom

    It would be good to have dynamic binding too, where the UI can bind to a different model members. Chris Oliver had a post about Lazy Binding, this may be helpful.

  6. carldea Post author


    I want to keep things simple for now, but later in the series I will discuss how it could be enhanced such as a Distributed MVC Model where forms, mappings and metadata can be dynamically sent to the client to be assembled. After all JavaFX is a declarative language. Yes, I’ve seen Chris Oliver’s entry and as far as I know lazy binding is a work in progress. Lazy binding has really a lot to do with scalability and performance. I’m pretty sure lazy binding for sequences aren’t supported in JavaFX 1.2 and JavaFX uses them heavily. If you are interested please take a look at page 91 of the JavaFX Developing RIAs book, which explains it pretty well.

    I think what would be nice is to have a keyword called ‘unbind‘. Of coarse I’m not a language expert but its not an easy thing to do.

    Thanks for the suggestions.

  7. Pingback: Java desktop links of the week, August 10 | Jonathan Giles

  8. Pingback: JavaFX Forms Framework Part 3 « Carl’s FX Blog

  9. Pingback: JavaFX Forms Framework Part 5 « Carl’s FX Blog

  10. Mick Dee


    Darn. I was hoping the demo would be automatic. I get a dialog box that tries to download a .jnlp file.

    Is that a hint that I’d be wasting my time developing a Java FX app if my browser won’t run it? Seems like if you wanted to sell Java FX, your demo would also automatically tell me why my browser can’t run Java FX.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s