Hi Ian, > 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.
I agree, it shouldn't be too hard to tie validation into data binding, but... > 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.) I agree, I think that they should be loosely coupled or completely decoupled. One question that arises from this is, who's role is it to display error messages to the user? Should it be the data binding framework, the validation framework or something else? Personally, I think that a third library should come into play here that will be able to apply the appropriate formatting to widgets when they are invalid/valid. I think that these three components should be tied together with listeners or handlers or some other implementation of the observer pattern. I'm thinking something like this: Widgets changes => bean is updated by data binding => data binding broadcasts that something has changed => validation picks up change and validates the bean => validation broadcasts results => formatter library catches new validation and updates widgets accordingly I think that we should get Chris Ruffalo in on the conversation so that something like this could be coordinated between these two frameworks. I know that Ray said the GWT will be implementing something themselves (http://groups.google.com/group/Google-Web- Toolkit-Contributors/browse_thread/thread/8c611ab8bb076ead) but I'm sure what you and Chris have done will help the GWT team out a lot. Will you start a new Google Code project for this data binding framework? Regards, Arthur Kalmenson On Oct 7, 3:47 pm, "Ian Petersen" <[EMAIL PROTECTED]> wrote: > 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 -~----------~----~----~----~------~----~------~--~---
