This version supports zooming for the XY chart: by dragging the mouse, you can select an area in the chart to scale the selected area up to full size of the chart. This allows you to have a close look at the selected data points.
JavaFX is a great UI toolkit. TestFX is a great library for testing the user interfaces written in JavaFX. Writing graphical tests with TestFX is simple and fast, but one challenge remains when you build your software using a headless build machine: how can you perform your UI tests in headless mode during your build?
Luckily, JavaFX 8 Update 20 will contain Monocle, which should allow us to run these headless tests.
First analysis using the latest beta of JDK 8u20 indicates that these tests are feasible, but require some changes in the TestFX library. We used a simple standalone JavaFX application for which we wrote a basic TestFX test class. We ran this test using the following command line options:
Unfortunately, this was not enough to make the test work. So we took a deeper look at the inner workings of TestFX and found that a working solution required the following changes:
refactor a part of the TestFX code such that different implementations of the org.loadui.testfx.framework.robot.ScreenRobot interface can be used. This allowed us to make test use an other robot implementation, in this case an adapter for MonocleRobot. The current TestFX implementation relies on java.awt.Robot, which uses the system event queue to move the system cursor. This, of course, does not integrate with Monocle in headless mode.
implement a ScreenRobot adapter for MonocleRobot. MonocleRobot is in internal package and thus not available via public API. In order to obtain an instance of this class, we had to call:
The following video shows a custom control in JavaFX that lets you select items from a list and position them in a grid. The items represent UI widgets, that is, JavaFX controls, with a defined size on the grid. The grid represents a page on which these widgets will be shown.
Based on these considerations from July, we gave FXForm2 a shot for generating forms from EMF models. It worked quite smoothly after we wrote the factories that defined how the custom data types used in our models should be displayed.
We found a few things that are worth noting:
Using Java Bean Validation
In order to validate our EMF models using the Java Bean Validation API (JSR-303) that comes with FXForm2, we wrote wrapper classes for those model elements that we wanted to add constraints to. We decided to not touch the generated code.
When you enter an invalid value into a field, FXForm2 won’t update the corresponding model attribute. The value you see in the form differs from the value in the model. The model thus always has a valid state.EMF validation typically works in a different way: you start the validation operation only after all model values were set. This allows for invalid states of the model.
An open issue seems to be (as least for us) the handling of a String-to-String Map attribute inside an EMF bean class that stores user-supplied key-value pairs which should be displayed as regular attributes of the bean. Antoine suggested a solution based on a custom control (with a factory and a skin), but it comes with a different visual appearance for the user-defined attributes. This is work in progress.
Software developer with experience in Java, JavaFX, EMF, OSGi, and a little bit of Swift. I live and work in Munich.
I use this website mainly as a journal and personal knowledge data base.
My PGP key is here. There are other keys listed for me, but I use this one exclusively.