Possible additions to JavaFX to facilitate forms and validations (original) (raw)

Daniel Zwolenski zonski at googlemail.com
Sat Dec 3 17:06:43 PST 2011

Hi,

This is my first post to this mailing list so please let me know if I do anything wrong or am posting in the wrong way or place.

I have been exploring the options for a 'form' framework built in JavaFX and there is a forum post with detail here: https://forums.oracle.com/forums/thread.jspa?threadID=2316760&tstart=0

In my opinion it is too early to include this form stuff in JavaFX as it needs to be put through its paces in some real world situations first. It works well as an open source library for now that can provide a reference implementation for possible later inclusion. There are however two core enhancements that I would like to see in the base JavaFX API that will simplify this form framework and also help out in other areas.

Here are the two proposals:

1. Node annotations

Extend the base Node class to include the concept of Node 'annotations' (i.e. visual markers on a Node, nothing to do with Java code annotations), where each Node can have arbitrary Nodes placed on top of them. In a form framework this would be used to add 'error icons' onto fields, but this same feature could be used to implement things like a 'help' icon that links to context sensitive help, or an 'arrow pointer' (e.g. for scripted walk-throughs of a UI) or 'fluro highlight' (e.g. for searching and highlighting on a screen), etc. I'm sure developers would find many other useful ways to use this feature.

I would see each Node having an 'anchor' constraint of type javafx.geometry.Pos which defines where the annotation should be layed out relative to the Node's bounds. The annotations should probably not affect the bounds, etc, and they should have a z-order that draws them above regular Nodes. They could also have x, y offset constraints, or the existing translateX/Y features could be used for this.

For reference, I have a crude version of this using a StackPane: http://code.google.com/p/jfxee/source/browse/trunk/jfxforms/src/main/java/com/zenjava/jfxforms/framework/AnnotatedNode.java

But it would be much cleaner if it was part of the core API rather than built ontop of it.

Unfortunately 'Node' is not a 'control' so it is not yet open sourced, so I can't submit a patch, but I would be happy to work with anyone on the JFX team to achieve this feature if it helps.

*2. Control Value Properties *

Currently the Controls API is very type specific when accessing the 'value' of a control. So the 'value' for a TextField is its 'textProperty', whereas for a CheckBox it is its 'selectedProperty' and for a ChoiceBox it is it's selectionModel's 'selectedItem', etc. It would be useful if the value concept was more generic and we then had a generic way to interact with the 'value' of all Controls.

Having a generic 'value' property would make it a lot easier to detect when a value has changed (which is important for form validation) as we could avoid a whole lot of if-then-else listener logic. I think this 'value' property would also simplify binding to fields, where a property can just be bound to the value of a property and not care whether that field is a CheckBox or a ComboBox so long as the 'value' is of the right type. Combined with some reflection, developers could probably create more generic binders between beans and fields, possibly facilitating cleaner PresentationModel patterns, etc.

I'd like to propose the addition of an interface along the lines of:

interface HasValue { ValueType getValue(); void setValue(ValueType value); Property valueProperty(); }

Which would then be implemented by every Control that has the concept of a 'value' to map their specific value (e.g. the textProperty in a TextField) to a generic Property instance.

As a point of reference, a crude helper class (providing read-only access currently) is here: http://code.google.com/p/jfxee/source/browse/trunk/jfxforms/src/main/java/com/zenjava/jfxforms/framework/ValueHelper.java

For ListView and TableView I would see the current selected 'row' as the value. Multi-selection has some additional challenges here, and I would be interested in other thoughts on this. One option is that these controls use List as their ValueType, another (and probably my preference) is that there is a separate interface called 'HasValues' for binding to multi-selection value controls, while still allowing simple binding to single-selection values.

If there is interest in this idea then I would put forward to this forum a list of controls and propose what the 'value' for that control would be and then look for comments, feedback on this list.

The code changes for this should all be contained to the 'controls' package so if there is general approval for this idea, I am willing to look at submitting some possible patches to implement this for review (once we have a way to actually build the code), though I would be looking for some input and support on some areas from you guys.

Cheers, zonski

More information about the openjfx-dev mailing list