FXForm2 sampler

We are pleased to announce that we provide now some FXForm2 samples using the FXSampler.

These samples were designed to help you using FXForm2 and to discover all of its features. FXForm2 can be highly customized to generate most of the forms you need; this sampler should help you to understand which features you need and how to configure your form.

We have covered some frequent cases we use here at dooApp, but feel free to ask for more examples!

How to test it?

• Clone the FXForm2 repo
• Run mvn exec:java in the samples directory
• Enjoy

There is some capture

FXForm: two releases and a lot of new features

We have added a bunch of cool features to FXForm, let's have a look!

Get ready for JavaFX 8

FXForm is now ready for JavaFX 8. We have adopted the following versioning conventions:

• FXForm 2.2.x for JavaFX 2.2 (latest version: 2.2.4)
• FXForm 8.0.x for JavaFX 8.0 (latest version: 8.0.1)

The version 8.0 of FXForm comes with the support of new types: LocalDate and Color using the new DatePicker and ColorPicker controls.

Improved data validation

We have improved the data validation layer of FXForm by adding the support of class level constraint and a finer granularity in constraint handling.

Class level constraint validation

FXForm now support class level constraints. This can be used to specify cross-field constraints.

The class level constraint violations are reported in the form. See below an example with the validation of a repeat password field:

In this case, our bean was simply annotated with the @PasswordMatch annotation which is a custom constraint validating that both password fields are equals. See Creating custom constraints for more informations about this.

Strict constraint versus warning constraint

Sometimes you want a constraint to be strict, sometimes you want it to be just a warning. FXForms allows you to specify this in your constraint declaration by using the group attribute of the constraint. By default a constraint is considered as strict. If you want your constraint to be a warning, use the Warning group provided by FXForm: 

In this case the @Max constraint will be treated as a warning. The main difference between a warning and a strict constraint is that with a warning, the model value will be updated even if the user input violates the constraint, which is not the case for as strict constraint.

Elements in the form that violates a constraint get a different style class for strict constraints and warning, so that the user feedback can be different in both cases.

In this example, the element editor is red and its label is bold when a strict constraint is violated and the element editor is orange when a warning is violated.

Multiple bean source

You can now edit multiple beans in the same form using the MultipleSourceBean

All features work as for a simple bean, including filters (reorder, exclude,...) and custom factories.

@Adapter

A custom adapter can now be specified directly on a field using the @Adapter annotation. If specified, FXForm will use the adapter provided by the annotation to bind the field property with the view property. See customizing bindings in FXForm2 for more informations about adapters.

Better handling of bound and read-only properties

FXForm introduces a notion of "editable" on the Node (see FXFormNode) which indicates whether a Node manipulated by FXForm allows the user to provide input.

FXForm now automatically disables editable nodes when bound to a property that is already bound or that is read-only. If the node is not editable (for example a Label), then it remains enabled.

New NodeSkin

FXForm now provides a NodeSkin. This NodeSkin can be used if you want to be responsible for creating the view of your form. You can then give your Node to the NodeSkin and FXForm will lookup for the required nodes and bind them to your bean. The lookup is based on the node ids. See wiki to understand how FXForm does the mapping between bean fields and nodes.

If your view is implemented in FXML, you can still use the FXMLSkin.

ListProperty support

Certainly one of the most funny (and useful!) feature of the latest release. FXForm now creates a TableView for ListProperty fields. Columns are populated automatically by analyzing the generic type of the ListProperty and extracting fields. When you click on a row, a popup shows, with -guess what- an FXForm :) This popup allows the edition of the selected item.

This feature is pretty powerful, since you can now edit pretty much your whole tree of model objects using just an FXForm. We might also add a default support for SetProperty and MapProperty in the future.

You can find the full release notes here. Thanks to usander, peterbecker and pjean for their appreciated feedback on the project.

Have fun with FXForm :)

Natural language search in FXML

I'm pleased to introduce "Natural Language Code Search", an IDE plugin straight out of our R&D lab that might be useful for you too!

Traceability

This plugin is the result of a collaboration between dooApp and the INRIA (French public science and technology institution). We investigated a new way to automatically recover traceability links between specifications and code elements. Establishing traceability links is very important for many reasons:

• program comprehension,
• maintenance,
• requirement tracing,
• impact analysis,... 

If you are not familiar with software traceability, have a look at this introduction on Wikipedia and at this excellent paper.

Classical approach

Most classical approaches to retrieve links between specifications (in natural language) and code involves analyzing code symbols (e.g. class names). It raises two issues:

• the developers might not always use the exact and precise domain terminology
• the code and the specification (e.g. a regulation) might be in different languages

Our approach

In our work, we introduced a new approach based on the analyze of the UI labels. Our idea is that the specifications lead most of the time to texts displayed to the user in the user interface and that these texts will use a precise domain terminology. Then it's possible to retrieve the UI label usage in the code, to identify the pieces of code you are looking for !

Process

We designed a three-step process:

• Index resource bundles using Apache Lucene
• Query the indexed bundles in natural language and retrieve the best matching labels and associated keys
• Retrieve code elements by analyzing key usages (either statically by analyzing code or dynamically by registering stacktraces of calls to ResourceBundle.get())

IntelliJ plugin

We have tested and evaluated our approach; the promising results of the evaluation lead us to develop an IntelliJ plugin wrapping the whole process. Check it out directly from the IntelliJ repository if you want to give a try !

And what about JavaFX?

At this point, you might wonder why we published this article under the JavaFX category? 

Actually, when you are developing a JavaFX application, your bundle keys are not used directly in the code but rather in FXML files. So, our plugin also lookup for key usage in the FXML file.

So, we realized that our plugin can also be used to easily retrieve FXML files associated to user interface labels, even if the query is approximate !
Don't lose time anymore trying to identify which FXML file to open when you want to modify the user interface ! Type in what you are looking for (e.g. some words that you see in the user interface) and let the plugin find it for you!
This is really handy for developers starting working on an existing project or for maintenance.

Try it yourself

The best way to understand how this plugin can help you is to try it on your own codebase:

• Install the plugin from IntelliJ
• Type "Ctrl+Shit+S" to open the input dialog
• Type your query in natural language
• Explore the results !

FXBinding, the binding you need

JavaFX 2 brings the Properties and Bindings concepts. If you don't know what I am talking about, I suggest you to have a look here : binding

I have an List ObservableList<XYChart.Data<Number, Number>>. I want to compute the average value of XValueProprerty for all Data contained into the list :

Without FXBinding :

See full code here

As you can see, it doesn't work :/

The binding is invalid only when the list changes, so when the XValue of a Data changes, nothing append.

I have to register every XValueProperty() into the bind() method :

See full code here

Now it works for all Data that was into the list at the beginning, but not for all added (or removed) Data after the init of the Binding

Let's make it work :

See full code here

While the complexity of your model is growing, you will have to register many listeners and the code is going to be less readable, less maintainable and less bug proof.

With FXBinding

Now let's replace our DoubleBinding by a magical FXDoubleBinding, it's 4 time step :

• Replace new DoubleBinding() by new FXDoubleBinding()
• Change the method name from computeValue() to compute()
• Remove {bind(...)} and replace it by the configure() method
• In the configure() method call addObservable() instead of bind()

See full code here

Every time the binding is becoming invalid, we will reconfigure it, so it's always a cool binding.

We will never have to add a listener even in a very complex model

An other example :

See full code here

Get FXBinding here

ListProperty vs ObjectProperty

In the world of JavaFX, when you need to use an ObservableList with the Property pattern, you write the following :

ObjectProperty<ObservableList<T>>

To be notified when the list content is modified, you can register a ListChangeListener on the ObservableList referenced by the ObjectProperty using the getter.
You can also register a ChangeListener on the ObjectProperty to be notified when the instance of ObservableList referenced by the ObjectProperty is modified.

You will end up with something like that :

• If you add an element or more, your ListChangeListener will be notified.
• If you change your ObservableList instance, your ChangeListener will be called.

But if the ObservableList instance referenced by the ObjectProperty has changed, and you try to add some elements to the new list instance, you won't be notified. This is because your ListChangeListener  is still registered on the previous ObservableList instance. So in your ChangeListener you have to unregister your ListChangeListener from the old ObservableList instance and register it to the new one. It's a little bit boring to do each time...

A major issue we discovered, is that if you replace an empty ObservableList by an other empty ObservableList, the ChangeListener is not notified, as we can see on this unit test, so that you can't correctly re-register the ListChangeListener on the new instance:

Why ? cause the equals method implementation return true between the two ObservableList.

So as you see... using an ObservableList with the Property pattern, is not really cool.

This is a problem, isn't it ??

Oh Legolas wants to help us. So listen what he says:

Replace our ObjectProperty<ObservableList<T> by a ListProperty<T>. ListProperty implements both Property<ObservableList> and ObservableList and makes the whole wrapping really transparent for the developer, taking care of the previous ListChangeListener manipulation automatically !

With that, if you want to be notified when the content of the List is modified, you just need to register the ListChangeListener once.

Like that :

When you do this, adding an element will notify the listener, and changing the ObservableList instance will call the listener to. And if you add an element after changing the list instance, no problem! the listener will also be notified of the change in the new list instance. No need to register a new Listener on the new List, the ListProperty manages it for you !

This unit test show us the ListChangeListener is called 5 times, once on each change.

Now you are ready to replace your ObjectProperty<ObservableList> by ListProperty ! Have fun

FXML + FXForm2 = Developing forms has never been so easy!

We just released a major version of FXForm2 (0.2.0) that includes FXML support.

This new version introduces the brand new FXMLSkin:

• write your model bean
• design your form in FXML
• FXForm2 do the rest!

How does it work? The FXMLSkin lookups all required nodes in the FXML file using their id and bind them automatically to the model bean. This skin offers a new flexible way to create complex forms without the pain of writing all the controllers logic. See wiki to know how to construct node ids.

How do I use it? form.setSkin(new FXMLSkin(form, my_file.fxml));

What about the original skins? Don’t worry, the original Default and Inline skins are still here and will still build the whole form for you! They are still very useful if you don’t need to customize your form too much and allow you to get quickly a functional form.

Feel free to give us feedback about this new feature!

Note: This release implied some architectural refactorings in FXForm2 and the form API has been slightly modified. If you have developed custom skins or custom node factories for a previous FXForm2 version, you will need to migrate them. An article will be published soon to help you do this very easily.

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.

JavaFX chart API and logarithmic scale

JavaFX provides an impressive chart API that allow to draw a wide range of charts. Unfortunately the only scale that is available for XY charts is a linear implementation.  Since the javadoc of the API is sometimes a bit rough it took me some times to get figure out how to get a logarithmic scale. After a discussion on mix.oracle.com it turned out that there where to approaches: 

• the first one is to transform your data with the logarithmic function before injecting it into the chart and to adjust the formatting of the labels to “simulate” a logarithmic scale. Since I don’t really like the idea of manipulating the data to get the expected representation I prefer the second approach:
• the second one is to provide your own implementation of a logarithmic Axis. Let’s see how to do this:

Extend the ValueAxis class. There are two methods to implement:

public getDisplayPosition(value: java.lang.Object) : Number 

 will do the mapping between a data value and its visual position. For a log axis, the implementation will look like this:

protected abstract updateTickMarks() : Void  will define which tick marks should be displayed. The javadoc does not say much about this function. It looks like the main idea is to update the tickMarks sequence of TickMark. The fields of TickMark are weirdly flagged as public-read package, so in oder to instantiate TickMark for our implementation we first need to define a class extending TickMark, let’s say CustomTickMark, and to put it in the package javafx.scene.chart.part in order to be able to set the required fields. After that you just need to update the sequence of tick marks with the marks you want to see on your chart, which can look like this:

Well, you’re now ready to use this LogAxis with your chart. The following example demonstrate the use of this LogAxis as x-scale of a chart.

Draggable nodes in XTreeView

I recently played around with XTreeView the tree component of JFXtras. It’s a nice component with a clean boundary between control and view so that was quiet easy to add a draggable behaviour to the nodes. By the way I’m really grateful to Rakesh Menon for his clear post about Drag and Drop in JavaFX.

The main idea is to wrap a renderer into a draggable wrapper that will encapsulate the created nodes into a SwingDragSource.

Checkout the demo: 

You will find the source and the eclipse project in the attached zip.

[[posterous-content:AEJvlcJRhkIFG0D5yfRT]]

JFXtras available in Sonatype OSS Repository

We have recently worked on a mavenization process of the JFXtras project to make it easily usable in a maven project. The project now has a pom and the current version (0.7-SNAPSHOT) is hosted at the Sonatype OSS repository.

To use JFXtras in your maven project, make sure that your maven environment has access to the Sonatype repository and just add the following dependencies to your pom:

EDIT: artifacts names have changed, they are now prepended with “jfxtras-“

https://gist.github.com/372473

https://gist.github.com/372475

Hope this helps using this great lib!

Just bind it

The javafx binding concept is nice and powerful. But sometimes it might be a bit difficult to figure out how to use it.

Let’s assume you have the following bean

https://gist.github.com/337407

and you need a variable bound to the sum of x*y for a sequence of those beans. Actually this problem can be expressed more generally: how to bind a variable to the result of a function applied to a sequence of elements (i.e. have it updated each time the sequence is modified or a field of a bean is modified). In java you would required tons of PropertyChangeListener registered correctly. With javafx you can write it in a more concise way using the bind keyword andbounded functions. But the first time I wanted to write it, I had to fight a little bit with the syntax. So I wanted to share this small unit test demonstrating a way to achieve this:

https://gist.github.com/337408

Unit testing your javafx application

In my last post I described how to set up a maven-javafx project using the jfrog-javafx plugin. One essential point was still missing in the configuration: the execution of javafx unit tests. By default, the jfrog-javafx plugin is not configured to handle a test folder. So let’s see how to do that:

• Create a src/test/javafx folder in your project
• Put a unit test in this folder. Note that javafx does not support annotations, so the test must be written according to junit 3 rules. (however, you can use junit 4 in your dependencies, since it’s backward compatible)

https://gist.github.com/332948

• Update the configuration of the jfrog-javafx plugin to compile both the main and the test javafx folders. We define two executions for this plugin. Themain execution will process the javafx resources and compile the javafx code in src/main/javafx during the compile phase. The test will compile the javafx code in src/test/javafx during the test-compile phase. You might also notice that junit is declared as a dependency of the plugin to fix a classpath issue since the jfrog-javafx plugin does not include the dependencies with test scope during compilation

https://gist.github.com/332954

• Now your javafx test should be executed during the test phase of the maven lifecycle like a regular java unit test. You can now let hudson run your javafx unit tests at each build!

MediaPlayer keeping quiet

According to the javafx media tutorial, playing a sound is simple. JavaFX provides a MediaPlayer to easily play any media source. You just need to define your Media by it’s URI, so this should looks like:

https://gist.github.com/336526

This seems very easy, but if you tries this, you might here nothing!

Then you are certainly in one of the two following cases:

• Your sound resource is packaged within your jar. This is not supported for the moment, see javafx faq
• You are trying to play a short sound sample. The first time I tried to play a 2s sound sample, my speakers kept desperately quiet. So what happened? A look at the Improve Media Performance tutorial put me on the way to the solution: according to this article, “for faster playback of a streaming media that is progressively downloaded, it helps to initialize the engine first by using the same media behind the scenes”. So, when you call the play function of the MediaPlayer, that playback engines “crunches” the first seconds of the sound sample during it’s initialization. For a long sound, you just almost don’t notice it, but a short sound sample might totally vanish. Unfortunately the MediaPlayer does not provides an init method, and the only way you can do it for the moment is to set your player to mute, play your media once and then rewind and unmute. It’s quiet ugly, but it’s the “official” solution proposed in the previous article. If you have a better solution, I’d be happy to hear it. Or just hope that javafx 1.3 will add an init method to the MediaPlayer.

Spice up your JavaFX project with maven

MavenFX.zip Download this file

JavaFX is a promising technology for nice Rich Internet Applications (RIA). However this is a quiet recent product (it was introduced by Sun at JavaOne, May 2007) and still lacks at integration with continuous development environments like hudson. Continuous integration is great because it reduces the gap between the development process and the release phase. With continuous integration, the work made by the developers is continuously compiled and tested against unit tests. This helps detecting many problems very early and simplifies the whole development process.

Hudson is an integration server that works very nicely with maven projects. So the first step to integrate a JavaFX project into our continuous integration environment was to “mavenize” the project. Jfrog has developed a javafx pluginfor maven that integrates the compilation of the javafx sources into the maven lifecycle. Moreover it can generate a jnlp to launch the project. 

However, this plugin is by default configured to work with artifactory. For some reasons you might want to use it without artifactory, and that’s possible. Just checkout the attached project to see how to configure it. Since artifactory takes care of some jnlp deployment issues, some additionnal plugins are required in this case: the dependency-plugin will copy the dependencies at the codebase directory of the jnlp and the jar-signer plugin will sign these jars.

At this step your project is fully integrated in the maven world. The last step is to deploy automatically the jnlp and required jars on a server to test your project. This can be achieved with the wagon plugin and its ftp extension (see attached project for an example of configuration). Then hudson can automatically deploy your application after each build by calling the mvn:deploy target. Enjoy!

Note: in the attached project, we use profiles (see profiles.xml) to configure the project dynamically whether this is intended to be run locally or deployed on a remote server. The “dev” profile allow you to run the project locally (using mvn clean package jfrog-javafx:excute) and the “prod” profile if for deployment (mvn -P-dev,prod deploy)