Logarithmic scale strikes back in JavaFX 2.0

JavaFX provides an impressive chart API that allows to draw a wide range of charts. Unfortunately the only available scale for XY charts is a linear implementation.

As we did it two years ago for javafx 1, we defined the logarithmic axis for javafx 2.

We received some requests of developpers who need to use a logarithmic axis but thay are confronted to the understanding of how axis works in javafx 2 and the impossibility to extend the NumberAxis, since it’s final in the API. So the only way to have a logarithmic axis is to extend directly the ValueAxis abstract class. Below, we’ll see how to implement all required methods to make it works. At the end you’ll be able to have this kind of chart :

So let’s create our LogarithmicAxis class that extends ValueAxis and define two properties that will represent the log lower and upper bounds of our axis. 

Then we bind our properties with the default bounds of the value axis. But before, we should verify the given range according to the mathematic logarithmic interval definition.

Now we have to implement all abstract methods of the ValueAxis class.

The first one, calculateMinorTickMarks is used to get the list of minor tick marks position that you want to display on the axis. You could find my definition below. It’s based on the number of minor tick and the logarithmic formula.

Then, the calculateTickValues method is used to calculate a list of all the data values for each tick mark in range, represented by the second parameter. The formula is the same than previously but here we want to display one tick each power of 10.

The getRange provides the current range of the axis. A basic implementation is to return an array of the lowerBound and upperBound properties defined into the ValueAxis class.

The getTickMarkLabel is only used to convert the number value to a string that will be displayed under the tickMark. Here I choose to use a number formatter.

The method setRange is used to update the range when data are added into the chart. There is two possibilities, the axis is animated or not. The simplest case is to set the lower and upper bound properties directly with the new values.

In order to have an animated axis, we should declare two timelines that will set progressively the range and use them if the animate parameter is true.

We are almost done but we forgot to override 3 important methods that are used to perform auto-ranging and the matching between data and the axis (and the reverse).

Well it’s done! I hope that this article will help you to define your own logarithmic axis and don’t hesitate to give me your feedback on this implementation.

Full code is available here :

JavaFX 2.0, Forms and Bean Validation: FXForm2 is here!

...and we are back on our technical blog!

We started last year a project called FXForm providing automatic form generation in JavaFX 1.3. We have been using this library intensively in some of our applications. JavaFX 2.0 is now a public beta. It did not took too much time until we decided to migrate FXForm to this exciting new version of the JavaFX technology. Actually, it was not really relevant to convert the old code to JavaFX 2.0 code. Most FXForm code was about binding and this part of the API has be heavily modified in JavaFX 2.0 to fit the constraints of the Java langage. So we decided to write it again from scratch — and you know what? This was quicker than expected to achieve! The new JavaFX 2.0 API is intuitive and clear. By the way, some features of the Java ecosystem where much more easier to integrate such as the JSR 303 Bean Validation support. So we are proud to announce FXForm2. Check our Get Started page to create your first form! Many features and default controls are still coming, but any help is welcome! Feel free to contact us.

Netbeans JavaFX Composer: Designing a CustomNode

The JavaFX composer is a powerful tool to design interfaces but at first it’s not really obvious how to split a complex interface into several pieces and how to handle custom nodes. In this article I’ll present the approach that turned out to be the most efficient from my own experience after some months of work with this composer.

• Create a new desktop design file called Main.fx that contains the common design parts of your application.

• Now let’s say we have the following model object and its manager:

• Next step is to design the node responsible for rendering a Doo instance in the interface. Select New File > JavaFX Fragment Design File to create a DooNode.fx design file. This will create a design fragment that you can edit visually with the JavaFX composer. Let’s switch to the “Source” view and add a field to this class that will contain the Doo instance edited/rendered in our node.

• We can now design this node and bind it to the rendered object.

• Now the question is how to use this design file in the main interface? The composer generates a method called getDesignRootNodes() that gives you access to the parent nodes of the design file. Using this method to handle this node is not really handy since it’s not defined in any interface and it won’t be easy to switch from a renderer to another one. JavaFX define the concept of custom node through the CustomNode class. Why not using this class as parent class for our design file? Switch back to the source view and let DooNode extends CustomNode. Now just define the postinit method and insert the root nodes into the children of the custom node. Your class should look like this now:

• Our DesignNode class is now a classical CustomNode and can be manipulated in a transparent way in the main design file. Let’s insert a flow layout into the Main design class and bind it’s content to a sequence of DooNode associated to the doo’s defined in the manager:

And that’s it! If you run the application you should see something like this:

This approach provides a handy way to split the interface into several small pieces in a transparent way and to take advantage of the composer features.

Note: the Netbeans project is available in the CustomNodeDesign file attached to this post

Dude, Where is my form?

Building UI forms for editing model objects is a repetitive task. That’s why we have started a small project called FXForm to provide automatic form generation for JavaFX objects. The goal of this library is to easily create customizable forms for any JavaFX object.

A small example might be more talkative. Let’s imagine you have the following model class:

and you need a form to edit an instance of this class. FXForm allows you to generate this form with a few lines of code:

and you will get something like this:

Checkout the Usage page of the project wiki for more information!

JavaFX composer, dynamic layout and XScene

As I mentioned in a previous post, I was quite unsuccessful developing a resizable application with dynamic layout behavior using the beta release of the Netbeans composer. An Amy Fowler’s post about Growing, Shrinking and Filling reminded me that I should give another try - dynamic sizing behavior is a great thing.

Moreover, some interesting changes have been introduced in the RC1 version of Netbeans. Let’s see how to do this:

• Create a new design file. By default the design file creates a javafx.scene.Scene. Unfortunately, this scene does not dynamically resize it’s child nodes to it’s current size.  This is exactly what the org.jfxtras.scene.XScene does. However, in the beta version of Netbeans Composer it was not possible to replace the default Scene by the one provided by JFXtras. Netbeans RC1 has introduced a cool feature: the Class Name Property. This allows to customize the class used in the generated code for a given component. This is a very interesting feature, bringing flexibility without overloading the composer’s interface. This way you can customize any component handled by the composer (as long as it’s using the same properties). In our case, just set “org.jfxtras.scene.XScene” as class scene for the scene component.
• Next step is to add a layout manager to the scene. Let’s use the Grid container, which is now supported by the RC1 version of the Composer! You can then add components to the layout and manage the number of rows and columns of the Grid layout. Notice that a new property has been introduced in the layout properties of the components: “Grid Hor. Span”. This allows to control the spanning of a component over multiple columns. For example, in the attached screenshots, the bottom button is spanned over two columns. The left button switches it’s Vertical Fill property, automatically adapting it’s size to the new constraints.

You can now start building your application with dynamic sizing and layout using the JavaFX Composer - a big step forward!

IoC in JavaFX

loC frameworks are very useful when you develop modular applications. I’ve been working with Guice and Tapestry IoC (which is an independent module of the Tapestry project) in the past, but I had to abandon them when I switched to JavaFX since none of them seemed to be compatible with JavaFX.

The main issue was about the use of annotations. They are both heavily depending on annotations to define the injection mechanisms - and JavaFX unfortunately does not allow us to use annotations…

However, the Tapestry framework provides another way to access services by requesting them directly to a registry without using annotations. (I didn’t find something similar in Guice, but it doesn’t mean that there is no way to get Guice working with JavaFX).

To play with tapestry injection, the first thing you need is to define an interface describing your injected service, let’s call it TestInterface:

https://gist.github.com/420814

(actually it’s an abstract class, since JavaFX does not use interfaces, but it doesn’t matter)

Next step is to define a concrete implementation of this interface that will be injected, for example TestInterfaceImpl:

https://gist.github.com/420816

The core concept of Taspestry IoC framework are the modules. Basically a module define some bindings between interfaces and their implementations. Let’s define a pure JavaFX module binding our injected service:

https://gist.github.com/420820

(Note that the concept of “autobuilding” will not be working, since it requires to define a “bind” method, which is a reserved keyword in JavaFX - not idea how to fix this for the moment)

We can now set up a registry with the defined module:

https://gist.github.com/420821

Well, we are now ready to request the service corresponding to the TestInterface simply by asking it directly to the registry:

https://gist.github.com/420822

And you should get the instance of TestInterface you defined in the corresponding module!

Finally, to get things a bit cleaner you can move all the registry stuff the a separate class:

https://gist.github.com/420844

This way, IoC.registry will give you an access to your registry in your application. Just make a call at IoC.init() before using it. This is not as “beautiful” as annotations, but still much better than no IoC. Let me know if you get a more elegant solution!

Note: This article is not intended to be a tutorial for taspestry-ioc, you will find more documentation about it in this howto and on the official website. Moreover, there might be other IoC frameworks that work with JavaFX, just let me know if you are successfully using another one!

Note 2: Tapestry IoC is following a strict “fail-fast” policy and building the registry will fail if your module contains unrecognized methods. This is a bit problematic with JavaFX modules. Actually, all JavaFX classes implements the com.sun.javafx.runtime.FXObject interface. So a JavaFX class contains systematically a bunch of methods inherited from this interface, that tapestry does not recognize. This will lead to an error message like this when you try to register your JavaFX module into the registry: “java.lang.RuntimeException: Module class injectiontest.services.TestModule contains unrecognized public methods: public boolean com.sun.javafx.runtime.FXBase.getAsBoolean$(int,int),[…]”. There is a corresponding jira entry. You can get the patch from this ticket to solve this issue for the moment.

Developing a business application with JavaFX Composer

When we started developing our first business application, I’ve hesitated a long time whether we should give a try to the Netbeans JavaFX composer. I am not a big fan of such gui design tools, especially because you usually get stuck sooner or later as your application grows. But I decided to give a chance to this new tool and got really convinced by the tutorials. So we started developing our application with this tool and we have now reached our first release. So let’s have a review:

• The first main question is about resizable layout. You can edit all the required layout information using the composer, but for the moment it’s clearly more oriented for static layouts. So we decided to develop a fixed-size application. I hope future releases of JavaFX and of the composer will facilitate the development of resizable applications (for example by providing a resizable scene like the JFxtras’ XScene)
• The composer is designed to work with a single design file, i.e., your whole interface code is stored in a single JavaFX class. We quickly reached a point were we got a “code too large” error, due to the size of the class which is limited by the compiler. At this point I really thought I would stop using the composer, since I couldn’t figure out how to split the design file without loosing the advantages of the composer. I have finally found an approach which proved to be quite handy using placeholders panels to integrate the nodes of separate design files. I’ll post a separate blog article about this.
• Another big drawback of the Composer is that you can’t work with custom nodes (for examples with JFXtras controls). It would be really interesting to be able to manipulate custom nodes with the composer. For the moment the solution is to use a placeholder and to insert your component manually. As long as you use mostly standard JavaFX components this is not too annoying, but it can be quickly annoying if you work with many custom nodes or controls.
• The state system is robust and provides a very nice way to manage the view according to the logic of the application. It’s very easy and powerful to work with the states. The only point that was sometimes problematic is that you often edit some properties unintentionally in a specific state instead of in the master state. The “set to master” button is then really helpful.
• Some minor features are still buggy. For example the edition of the Tooltip of a node does not work for the moment, clicking on the add button just lead to some Netbeans errors. However, this can still be done manually.
• The auto-completion is unfortunately not provided when you edit the code of a binding through the property dialog, that would be handy.
• Refactoring does not work in the code managed by the composer. So if your gui is bound to a model object and that you refactor the name of this object, the managed code won’t be updated and you will have to do it manually through the composer gui.

To conclude I must admit that I’ve been really impressed by the Composer tool. It’s stable and robust. The resulting JavaFX code is clear and remains clean even after hours playing with the composer. Some of the drawbacks and limitations I’ve enumerated are clearly annoying, but finally the composer is very very promising. I wouldn’t have bet one month ago that we would have developed a business application with this tool. Now it’s done, and I’m not sure I would be able to give up this composer so easily.