At the beginning of my previous post I mentioned that I was stuck in the implementation of the calendar picker, because I was using one listener for 42 ToggleButtons, and I could not find out which of the 42 ToggleButtons was actually clicked. The code I have looks like this:

class Skin
{
	/**
	 * create the skin by using other controls
	 */
	private void createNodes()
	{
		for (int i = 0; i < 6 * 7; i++)
		{
			ToggleButton lToggleButton = new ToggleButton();
			lToggleButton.selectedProperty().addListener( iSelectedListener );
			...
		}
	}

	// one listener for all 42 buttons
	final private InvalidationListener<Boolean> iSelectedListener = new InvalidationListener<Boolean>()
	{
		@Override public void invalidated(ObservableValue<? extends Boolean> observableValue)
		{
			// selected or deselected
			boolean lSelected = observableValue.getValue();

			// TODO: which ToggleButton was pressed?
		}
	}
}

After having dropped this at the JavaFX people I went into pause, assuming the InvalidationListener API would be extended to include the origin of the event (like Swing events do). After some time Richard Bair came back to me and explained that extending the API with a reference to the bean would mean additional bytes for each property. My initial reaction was; so??? It’s just a few bytes? But then I realized that JavaFX is not about controls, but about graphics; controls are just a subset in which I’m very interested, but the real focus of JavaFX is much more basic and raw. There will be applications with thousands of nodes, and then a few bytes per property quickly become megabytes and the rise of the mobile devices suddenly make memory important again. So it became clear that extending the InvalidationListener API is not wise indeed. (more…)

After Swing, JavaFX 1.x and the iPad, now JavaFX 2.0 is candidate for the calendar picker shake down. Using MigLayout I’ve setup the basic day picking logic, but currently am stuck in build b21, because the events on the selected property in ToggleButton do not tell me which togglebutton was actually pressed, which is quite handy if you have 42 of them on screen. So I decided to focus a bit on binding instead.

My binding experience comes from JGoodies used in connecting Swing components to business model bean properties, usually using JGoodies’ BeanAdapter (which takes away the need to rebind every single property when the business model bean is changed underneath a Swing screen). Since I’m primary focussed on JavaFX’s controls at the moment, I wanted to see if I could bind my calendar picker to a business model. I’m also going to assume future 2.0 in which the properties on the business model also are using JavaFX properties. So I constructed a dummy business model with one property:

	class BusinessModelBean
	{
		final public ObjectProperty iCalendarObjectProperty= new ObjectProperty();
	}

(more…)

Oracle rebooted JavaFX and finally positioned it as what I for a long time have been longing for; Swing 2.0. Let’s not kid ourselves; JavaFX is a new UI library for Java, using the API lessons learned from Swing and taking it to the next level with animations and effects. The concept is powerful enough to even go into the 3rd dimension soon. And more importantly; JavaFX2 finally has a good integration (and therefor migration path) with Swing, so it actually has an existing user base which can easily be persuaded to take a peek. Not to mention the fact that it now uses Java instead of JavaFX script, so the EDI support is great right from the start. (Well done Oracle!) But if this doesn’t sound like Swing 2.0, I don’t know what will.

So what is JavaFX2 like? Well… I like it. The API is clean and intuitive. Since it uses a different approach, making everything from simple lines to complete tables just a node in a tree, it means that I still have to really get my head around that. Fact remains that this approach allows to easily add effects and animation on anything, being it on a square or complete screen (they’re all just nodes after all). But I know I will initially use JavaFX in existing Swing applications, so my primary interest is in the controls. In order to make my life easier, I decided that porting MigLayout could be a good idea.

I must say that the initial results in my opinion are not bad at all. Below is an example of a simple test involving a TextBox and Rectangle:

public class MigPaneTest1 extends Application {

    public static void main(String[] args) {
        Launcher.launch(MigPane.class, args);
    }

	@Override
	public void start(Stage stage) {

        // root
        MigPane lRoot = new MigPane(new LC(), new AC(), new AC());

        // add nodes
        lRoot.add(new TextBox(10), new CC());
        lRoot.add(new Rectangle(30,30, Color.YELLOW), new CC());

        // create scene
        Scene scene = new Scene(lRoot, 600, 300);

        // create stage
        stage.setTitle("Test");
        stage.setScene(scene);
        stage.setVisible(true);
    }
}

This results in the following layout:

(more…)