Validate Me

[Jeff McDonald]

Brilliant comments here. There's a big design opportunity here to
define hooks in the UI for representing validation feedback
notifications and input guiding cues.

+1 validation events
+1 css pseudo classes

Using css offers a lot of flexibility for giving visual feedback, most
developers would be happy with being able to layer an icon over or
under a field or change the background color, however there's a huge
opportunity to display novel feedback by using animations or attaching
a dynamically generated node. For example ... the Login screen on Mac
OS X will shake if you enter the an invalid user name or password
(See: http://www.youtube.com/watch?v=hcuJUzOalgU). On a mobile device
the vibrator could be turned on ... using vibration could even be
considered an assistive technology.

Nodes have more than one understanding of bounds. What you're thinking
of is the layout bounds which is what the layout managers use. There
is also a visual bounds that I don;t think affects the layout. I could
be wrong on the details, but the Node API has the ability to handle
drawing associated with a node and has the ability to draw overlays
without affecting the layout bounds.

The issue of resetting a css style value is already an issue Jira
(See: http://javafx-jira.kenai.com/browse/RT-9784).

After having done some research into different validation frameworks,
there are some nice ones out there, I'd prefer to see JavaFX work with
a wide range of validation frameworks rather than add a new one as my
original post was going on about.

Cheers,
Jeff

On Tue, Feb 21, 2012 at 4:40 PM, Daniel Zwolenski <zonski at googlemail.com> wrote:
>
> Hey Richard,
>
> The pseduo class idea is a good one, but what about making it even more 'plumbing' oriented? Would it be possible for us to just add arbitrary psuedo classes in code and these are then in the CSS. So we don't need an explicit 'invalid' ''warning' styles hard coded into JFX, but rather I can just call Node.setPseudoStyleClass("invalid") or Node.setPseudoStyleClass("my-custom-pseudo-class")  - or we can add/remove them if a node can have more than one pseudo class at once? That way if I want more levels of invalidation (or anything else) I'm free to do so. Would there be any drawbacks to this approach?
>
> Your mention of CSS pseudo classes reminded me of the other plumbing problem I faced when implementing the validation stuff: it's not possible to remove a style once it's been added. You can remove the style class from the list of styles applicable to the Node but this doesn't actually 'revert' the styles that were applied by that class being added.
>
> For example if I call node.getStyleClass().add("error") and that had -fx-background-color: red, my node will be updated to have a red background. If I then call node.getStyleClass().remove("error"), the class is removed, but the field stays red.
>
> The only way to really get rid of the red background is to apply the inverse style, so in my validation framework I have to define background-color: red for "error", and then background-color: white for "non-error". This is definitely not ideal and is prone to error. I assume people will have to do something similar with your pseudo class proposal as well? Does it have to be this way? Is it not possible for the removal of the style to revert the style attributes?
>
> With the overlay layer one thing to consider as well is the issue of bounds. The overlay often wants to extend past the edge of the bounds of the control (e.g. I want to put a big red X on the top right corner of my text field, extending slightly above and to the right). Most of the times this should always appear above the nearby components. If the node is in a framed container however - something like a scroll pane, or maybe a tab pane or title pane, I think most users would expect that container to clip the overlays as well. And then we have things like transforms (scaling, translates, etc) - need to decide whether the overlays are affected by these or not (probably yes, but worth thinking about).
>
> Cheers,
> Dan
>
>
>
> On Wed, Feb 22, 2012 at 4:48 AM, Richard Bair <richard.bair at oracle.com> wrote:
>>
>> I think there is definitely code that needs to live on the UI Controls to make building validation frameworks atop of it nice and clean. For example, it would be fantastic if there were validation events and validation state pseudo classes built into the controls. In such a case, an invalid control would have both some property indicating that it is invalid (and it would be some object containing information on why, for example). Also a pseudo class would change ":valid" and ":invalid" based on what the state of that property was. It is then up to some higher level application code to modify the validation state on the control.
>>
>> When we add masked edit capabilities to text field (or a formatted text field or whatnot), that will allow for restricting input, but doesn't overlap much with validation (other than it would be nice if the formatting mask  could be derived automatically based on formats supplied on the bean property via JSR 303).
>>
>> If JSR 303 becomes part of JavaSE (I believe it is an EE spec at this time?) then we would certainly add built-in support for it. In the meantime, I like the idea of frameworks being able to build on top of the basic support built into controls, such that they define the validation lifecycle (when validation happens, etc). With CSS pseudo classes, it is possible to show/hide notifications from CSS, which is also good.
>>
>> And we do need to add a nice way to layer content on a control, such as something behind the control or above the control. What form that API takes is TBD but I agree having something like that would be great.
>>
>> What you could then do is basically take a TextField, add a layer that displays validation events, and from CSS wire the visibility of the validation layer (and perhaps its colors and icons) based on the validation state of the control (maybe we have ":valid", ":invalid", ":invalid-warning", ":invalid-error", or whatnot). That seems to supply a lot of power with very little in terms of API commitment, which is usually right where I like it to be :-).
>>
>> Richard
>>
>> On Feb 20, 2012, at 12:15 PM, Daniel Zwolenski wrote:
>>
>> > I started a thread on this a while back with my thoughts on this (which
>> > still hold):
>> >  https://forums.oracle.com/forums/thread.jspa?messageID=10012233&#10012233<https://forums.oracle.com/forums/thread.jspa?messageID=10012233�>
>> >
>> >
>> > In my first post there is an initial working example:
>> >  http://zenjava.com/demo/form/forms.html
>> >  http://code.google.com/p/jfxee/source/browse/trunk/jfxforms/
>> >
>> > I've since improved on this code base and am using the improved code in my
>> > current project with reasonable success. I'm currently considering if/how
>> > to open source this code. I could bundle it into JFX Flow but I'm thinking
>> > it might be better in a separate open source project. I'd be more than
>> > happy to collaborate with others in this space if there was interest.
>> >
>> > I'm a big fan of JSR303 Bean Validation for this as it is very rich, pretty
>> > standard and is an active JSR, with some tooling support. It works equally
>> > well in UI and server code, which is a definite requirement for me, since
>> > when doing a desktop client-server app we need to validate on the client
>> > for presentation reasons, but also validate on the server for security
>> > reasons (since you can never trust that the client app is your app). My
>> > preferred validation framework is basically a JFX based presentation layer
>> > on top of JSR303.
>> >
>> > This brings us back again to the issue of what is 'core' and what is higher
>> > level as it uses a third party library (although it is a JSR, so perhaps
>> > that helps). I noticed when I first raised the topic that while JSR303
>> > seems awesome to me, others had some concern about the need to validate a
>> > whole 'bean' rather than just simple, individual field validation built
>> > into Controls. This would not work for me, but I can see the appeal with a
>> > simple API so we once again have more than one 'acceptable' approach. There
>> > was also some concern about JSR303 using annotations, the Scala people had
>> > trouble with this I think (although I'm personally not sure that's a good
>> > reason not to use it). So we hit that question again of whether JFX should
>> > provide an out-of-the-box solution or just plumbing that an open source
>> > project (or projects) can build upon to provide higher level utilities.
>> >
>> > Looking at just the low level plumbing aspects, the things that JFX was
>> > lacking that would make my specific validation framework easier to
>> > implement are discussed in this thread:
>> > http://mail.openjdk.java.net/pipermail/openjfx-dev/2011-December/000048.html
>> >
>> > The ability to visually annotate or mark up a node (or control) is the key
>> > one for me. This would be useful both for validation frameworks but would
>> > also have much wider applications (which is a good test of 'plumbing' in my
>> > mind), such as marking up nodes for 'live help' or highlighting nodes when
>> > doing a guided walk-through of an application in 'tutorial mode'.
>> >
>> > After our discussions in that thread I've personally come to the conclusion
>> > that a consistent 'value' property is not actually a strong requirement but
>> > that some of the controls (i.e. ChoiceBox) were just lacking a value
>> > property and I believe this has been is or is being addressed.
>> >
>> > Additionally to the earlier issues, the other big plumbing thing that was
>> > not up to the level needed yet was the JFX Tooltip API. The current tooltip
>> > mechanism is very simple and I really would have benefited from being able
>> > to specify specific tooltip timings and features on a per-control basis
>> > (i.e. when a field has an error I want to be able to show the tooltip
>> > instantly when the field has focus and keep it visible, but without an
>> > error, the tooltip can go back to normal). There is an existing JIRA
>> > request for this sort of thing: http://javafx-jira.kenai.com/browse/RT-17324
>> >
>> >
>> > On Tue, Feb 21, 2012 at 5:07 AM, Jeff McDonald <deep.blue.6802 at gmail.com>wrote:
>> >
>> >> As part of the App kernel frameworks discussion Richard has discussed the
>> >> need for a validation frameworks. I'm breaking out the discussion on
>> >> validation because the topic is broad enough to benefit from a focused
>> >> discussion.
>> >>
>> >> My random thoughts:
>> >> - All of Java can benefit from validation, and not just JavaFX. Where
>> >> should a validation frameworks fit into the Java ecosystem?
>> >>
>> >> - Thinking about validation there are two categories that I can think of
>> >> (1)passive validation - this is the most obvious. A users types in a value
>> >> and submits it and validation is performed and either the input is bad or
>> >> it's good. (2) active validation - input is evaluated and validated during
>> >> the input process. As an example: Let's say you have a field that accepts
>> >> an email address. With passive validation the user could be informed that
>> >> they entered an invalid email address. In an active validation system the
>> >> field could restrict the user from entering invalid characters or stop
>> >> accepting input once a maximum size is reached.
>> >>
>> >> - JavaFX can benefit from both passive and active forms of validation. The
>> >> important question becomes how to implement validation into the UI. Where
>> >> to place the hooks and response behavior in the UI code.
>> >>
>> >> - What things work great in existing validation frameworks? What sucks?
>> >>
>> >> - What libraries do you use? Why did you pick that library?
>> >>
>> >> - What is missing from existing validation frameworks?
>> >>
>> >> Cheers,
>> >> Jeff
>> >>
>>
>