Allow input controls to indicate significant user interaction

[mkpaz]

I can compare this with Vuetify framework, generally because it uses 
good abstractions. It provides the three types of validation.

1. Eager - an input is validated immediately after loading (adding to 
the scene). Usually it's initialized with some default valid value to 
not disturb user.
2. Input - an input is validated after a user interaction (lazy 
validation). It puts the input to the *dirty state* and that state is 
used to trigger the validation.
3. Submit - an input is validated after the form submission.

While it's already possible to implement the second option, one "simply" 
need to subscribe to all focus, keyboard and mouse events and manage the 
dirty state manually, it seems reasonable to delegate this work to the 
skins. The question is what should be considered as a "significant 
interaction". Some implementations set dirty state immediately after the 
input loses focus state, others require some actual keyboard input.

On 3/27/23 04:48, Michael Strauß wrote:
> Many form-based applications require some sort of data validation for
> input controls. It is also often desirable to visualize the validation
> state of a control directly in the user interface, for example by
> showing a red border to indicate a validation failure.
>
> However, simply validating the current value of a control and
> rendering a validation decorator often leads to an undesirable user
> experience: for example, in many cases an empty form field shouldn't
> indicate a validation failure unless the user has significantly
> interacted with the field, or validation was explicitly requested by
> pressing a "submit" button.
>
> The first of these validation conditions, "significantly interacted
> with the input control" is quite popular on contemporary web forms,
> and offers a balanced user experience compared to immediately and
> eagerly validating every control, or delaying validation until the
> very end of the form submission process (see also the proposed
> :user-valid/:user-invalid CSS pseudo-classes).
>
> Unfortunately, this is very hard to implement in JavaFX since controls
> have no way of signalling when they were significantly interacted
> with. In particular, we don't want to count programmatic
> initialization of field values as a significant interaction. What
> constitutes a significant interaction is dependent on the type of
> input control. For example, a text field might define a significant
> interaction as the sequence of gaining focus, receiving a new text
> value, and losing focus. A slider might define a significant
> interaction as the sequence of pressing the mouse button, dragging the
> slider thumb to a new value, and releasing the mouse button.
>
> The information of how an input control changed its value is only
> really knowable by its skin and associated behavior classes, both of
> which are basically black boxes for a JavaFX application. In order to
> expose this information, I propose to add the following new interface
> in the "javafx.scene.input" package:
>
> public interface InputNode {
>      ReadOnlyBooleanProperty userModifiedProperty();
>      boolean isUserModified();
>      void setUserModified(boolean value);
> }
>
> This interface identifies a node that can receive user input. It is
> implemented by the following controls: ButtonBase, ChoiceBox,
> ComboBoxBase, Slider, Spinner, and TextInputControl.
>
> The associated skins and behaviors are modified to invoke
> setUserModified(true) on the control when a significant user
> interaction is detected. Once this flag is set on a control, it can
> only be unset programmatically from application code by invoking
> setUserModified(false).
>
> You might note that userModifiedProperty() returns
> ReadOnlyBooleanProperty, while a public setter is availabe. The reason
> for this is that while applications should be able to set or clear the
> userModified flag programmatically, they shouldn't be able to bind the
> property to prevent it from being set by skins.
>
> Note also that it is not a goal of this proposal to add a data
> validation framework to JavaFX (this is best left to third-party
> libraries instead). The goal is to expose a crucial piece of
> information that is not easily accessible otherwise.
>
> I'm interested on your thoughts on this idea.