Hi Arthur, On Tue, Oct 7, 2008 at 1:51 PM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote: >> I don't mean to nitpick, but it's actually the editor that puts back >> the previous value, not the converter. The converter just throws a >> ConversionException if the String couldn't be converted. It's up to >> the editor to decide what to do with the ConversionException. > > Ah, sorry, I misunderstood how it was working. Thanks for clearing > that up. This also deals with the original use case I proposed above > (not updating the model right away). I only thought of that case > because it kept trying to convert and reverting the field to it's > previous value, which prevented validation from running its course. > I'll just create my own editor and leave the field the way it was.
I read your comment on issue 343 (http://code.google.com/p/google-web-toolkit/issues/detail?id=343#c31). I haven't finished reading the Bean Validation JSR yet, and I haven't looked at Chris Ruffalo's code, but I have dipped my toe into using Hibernate validation in my own server-side code. I *think* validation could be tied into the data binding framework in a pretty straightforward way by extending Editor<T> and Viewer<T> to be validation-aware. At the moment, Viewer<T> and Editor<T> just provide simple interfaces to view (and edit) a value of type T. If there was some way to talk about the validity of a given value, Viewer<T> (and, by extension, Editor<T>) could be extended to provide feedback to the user when the value it's displaying changes from invalid to valid or valid to invalid. I assume that Hibernate validation-style validation requires some kind of "validation service" that is external to the beans being validated. (As opposed to the beans themselves somehow performing validation and reporting the results.) If that's the case, a BoundField could listen to its editor for EditorChangeEvents and filter the new value through validation before/after/around updating the related bean. If you perform validation at that time, you have access to the editor that changed, the bean that's (in)valid, the property that's (in)valid, and the validation state. You could probably give very rich feedback to the user about that particular property, and there are a number of rational ways to handle an invalid value. Handling multi-property validation is a little more complex but, assuming the validation "service" can provide enough feedback, the bound field may be able to co-ordinate with its containing BoundForm to manage the related fields, or it could just punt and disallow the field change that prompted the switch from valid to invalid, depending on what works in context. As for validation "events" that happen "behind the scenes", perhaps bound fields could somehow observe the validation service using their knowledge of bean type and property name. I think data binding and validation probably need to be aware of each other (or, at least, data binding needs to be aware of validation), but I think they're separate concerns. To me, data binding is just a way of automating the display and update of a bean's properties via some widgets. Validation, on the other hand, is a way of making sure that a property is within some bounds, or some combination of properties together follow some rules. Data binding impacts validation because the user could transform a bean into or out of a valid state, and validation impacts data binding because you usually need to give the user feedback about the validity of the bean being edited, but I think the relationship between data binding and validation is probably best mediated through a thin interface that keeps things loosely coupled. What do you think? (Or anyone else, for that matter.) > Ian, I think this data binding framework is really excellent. It's > really well thought out and I think it'll be a major contribution to > GWT. I hope it makes it into the incubator soon. Thanks for your hard > work. Thank you for the compliments and for taking the time to look into the code and come up with questions and concerns--I'm sure you'll find more as you dig deeper. Ian --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
