Validate Me

Daniel Zwolenski zonski at googlemail.com
Mon Feb 20 12:15:02 PST 2012


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
>


More information about the openjfx-dev mailing list