FX Experience Has Gone Read-Only

I've been maintaining FX Experience for a really long time now, and I love hearing from people who enjoy my weekly links roundup. One thing I've noticed recently is that maintaining two sites (FX Experience and JonathanGiles.net) takes more time than ideal, and splits the audience up. Therefore, FX Experience will become read-only for new blog posts, but weekly posts will continue to be published on JonathanGiles.net. If you follow @FXExperience on Twitter, I suggest you also follow @JonathanGiles. This is not the end - just a consolidation of my online presence to make my life a little easier!

tl;dr: Follow me on Twitter and check for the latest news on JonathanGiles.net.

The recent 1.2 release of JavaFX included our first set of UI Controls. We talked about these recently at JavaOne. We’ve uploaded our slides to the controls portion of the talk. Unfortunately, the slides don’t contain all of the “filler” text you get when presenting the slides, so I’ll provide a little context here.

When designing the APIs for JavaFX, we wanted to focus on a couple core principles. First, we wanted to make the API simple and approachable. One of the things that Swing always struggled with was the steep learning curve. We wanted to put extra effort into making the JavaFX APIs easy to learn, and this carried into the UI Control API design as well.

But a simple API doesn’t mean a simplistic API. We wanted our API to also be very practical and useful. Jasper and I both have a background as application developers and that experience very strongly influenced the FX API design.

Finally, our API designs should be rich. There should be a lot of nice functionality built in for free (without burdening the API with conceptual overhead). There should be rich visual effects and interaction models. As engineers, we also want our APIs to be rich enough and flexible enough that you can really customize it.

On the 4th and 5th slides I show an architectural diagram. At first looking at the design you might just say “hey, its MVC!”. Well, yes, pretty close. The Control is basically the model, the Skin is basically the view, and the Behavior is basically the Controller. But there are some differences between our architecture and the “official” MVC architecture. The difference is that Controls are Nodes that can be placed in the scenegraph, so really they are part of the “view”¬†hierarchy. However, Controls delegate their visuals to their Skin, so while they are part of the scenegraph, they really are mostly just models.

Most of the other slides are self explanatory. You might want to cross reference what you see in the slides with the official documentation.