[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-openjfx-dev
Subject:    Validate Me
From:       richard.bair () oracle ! com (Richard Bair)
Date:       2012-02-24 21:04:25
Message-ID: 4F58B3D4-7830-4EFA-A506-6E0D9B7B0FF9 () oracle ! com
[Download RAW message or body]


> 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? 

Ha, hadn't thought of that :-). We want to make the code for handling pseudo class \
states public for 3.0, but it requires (currently) subclassing. Take a look at Button \
or ButtonBase for examples of how this works. The upside to the current design is it \
takes less dynamic footprint / memory, the downside is that each call to discover the \
current pseudo lass state requires a bunch of checks (if my memory matches the \
current impl!)

> 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?  

I don't think so, I know we did this at one point but it was very problematic. I \
believe the semantics we have now are the same as the web. Which is not to say it is \
the bees knees but, I think in this case we tried other ways in the past but they \
didn't work out (I don't remember if the problem was performance related or semantic \
related).

> 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).

Great point, we actually have a similar problem with focus indication. To me how to \
handle this is an open issue. I wonder if this is related to the text "billboard" \
feature people are asking about?

Richard


> 
> 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
> > > 
> 
> 


[prev in list] [next in list] [prev in thread] [next in thread]