<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Times New Roman \(Body CS\)";
panose-1:2 11 6 4 2 2 2 2 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Courier New";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">I think this functionality belongs to the application-level code, not in the platform. It's the application that knows which parts of a form need the visual feedback and which do
not. In my opinion, there is no APIs that are missing in order to implement a validation framework of any level of complexity.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">Not responding to programmatic changes is easy: disable validation logic when setting values.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">The validation and subsequent user feedback may happen at the time of form submission, or as a result of a short timer expiring. The timer should be restarted upon each update of
the value properties being validated.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">In any case, this problem has a well-defined solution and, in my opinion, does not require a change in the core platform.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">Cheers,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New"">-andy<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Courier New""><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">openjfx-dev <openjfx-dev-retn@openjdk.org> on behalf of Michael Strauß <michaelstrau2@gmail.com><br>
<b>Date: </b>Sunday, March 26, 2023 at 17:49<br>
<b>To: </b>openjfx-dev <openjfx-dev@openjdk.org><br>
<b>Subject: </b>Allow input controls to indicate significant user interaction<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Many form-based applications require some sort of data validation for<br>
input controls. It is also often desirable to visualize the validation<br>
state of a control directly in the user interface, for example by<br>
showing a red border to indicate a validation failure.<br>
<br>
However, simply validating the current value of a control and<br>
rendering a validation decorator often leads to an undesirable user<br>
experience: for example, in many cases an empty form field shouldn't<br>
indicate a validation failure unless the user has significantly<br>
interacted with the field, or validation was explicitly requested by<br>
pressing a "submit" button.<br>
<br>
The first of these validation conditions, "significantly interacted<br>
with the input control" is quite popular on contemporary web forms,<br>
and offers a balanced user experience compared to immediately and<br>
eagerly validating every control, or delaying validation until the<br>
very end of the form submission process (see also the proposed<br>
:user-valid/:user-invalid CSS pseudo-classes).<br>
<br>
Unfortunately, this is very hard to implement in JavaFX since controls<br>
have no way of signalling when they were significantly interacted<br>
with. In particular, we don't want to count programmatic<br>
initialization of field values as a significant interaction. What<br>
constitutes a significant interaction is dependent on the type of<br>
input control. For example, a text field might define a significant<br>
interaction as the sequence of gaining focus, receiving a new text<br>
value, and losing focus. A slider might define a significant<br>
interaction as the sequence of pressing the mouse button, dragging the<br>
slider thumb to a new value, and releasing the mouse button.<br>
<br>
The information of how an input control changed its value is only<br>
really knowable by its skin and associated behavior classes, both of<br>
which are basically black boxes for a JavaFX application. In order to<br>
expose this information, I propose to add the following new interface<br>
in the "javafx.scene.input" package:<br>
<br>
public interface InputNode {<br>
ReadOnlyBooleanProperty userModifiedProperty();<br>
boolean isUserModified();<br>
void setUserModified(boolean value);<br>
}<br>
<br>
This interface identifies a node that can receive user input. It is<br>
implemented by the following controls: ButtonBase, ChoiceBox,<br>
ComboBoxBase, Slider, Spinner, and TextInputControl.<br>
<br>
The associated skins and behaviors are modified to invoke<br>
setUserModified(true) on the control when a significant user<br>
interaction is detected. Once this flag is set on a control, it can<br>
only be unset programmatically from application code by invoking<br>
setUserModified(false).<br>
<br>
You might note that userModifiedProperty() returns<br>
ReadOnlyBooleanProperty, while a public setter is availabe. The reason<br>
for this is that while applications should be able to set or clear the<br>
userModified flag programmatically, they shouldn't be able to bind the<br>
property to prevent it from being set by skins.<br>
<br>
Note also that it is not a goal of this proposal to add a data<br>
validation framework to JavaFX (this is best left to third-party<br>
libraries instead). The goal is to expose a crucial piece of<br>
information that is not easily accessible otherwise.<br>
<br>
I'm interested on your thoughts on this idea.<o:p></o:p></span></p>
</div>
</div>
</body>
</html>