Possible additions to JavaFX to facilitate forms and validations

[Daniel Zwolenski]

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> {
   ValueType getValue();
   void setValue(ValueType value);
   Property<ValueType> 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<ItemType> 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