On Tue, Oct 7, 2008 at 10:56 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote: > Yes, I'm looking to avoid updating the bean automatically. I want to > specify when the bean should be updated.
I see. I hadn't thought of that use case. As it stands, no, you can't do that. BoundFieldImpl<B, P> has a nested class Listener that implements EditorChangeListener<P>. BoundFieldImpl's getEditor() adds an instance of Listener as a change listener to the editor before returning it. That listener takes care of updating the bean when the editor changes and, as it stands, you can't not add the listener. When I designed the library, I thought of bound widgets as views on fields in a bean. If the bean changes, the widget is updated and if the widget changes, the bean is updated. If you created a "detached" editor that didn't automatically update the bean, what would you want to happen if the bean were to change behind the scenes? Right now, if the bean SourcesPropertyChangeEvents, the editors and viewers are updated onPropertyChange. Would you want a detached editor to ignore property change events from the associated bean? > It'll also be interesting to see what the performance implications are > of having the bean updated on any change. Does it work fine for forms > of 100+ fields? I haven't explicitly tested it with that many fields, but I'd expected it to be okay--only the property bound to a given widget will be updated when that widget changes. In the example I posted, the Person class has firstName and lastName properties. When you edit a given person, the firstName and lastName properties are bound to text boxes. If you edit the first name, only the firstName property is updated and likewise for the last name. Where there could be performance considerations is if you have "lots" of viewers and/or calculated fields all depending on the same property and then you edit that property. I don't know what would happen then--the UI would probably freeze until the updates were all complete. I'd be surprised if a real application had a single field with 100+ dependent viewers, though. > Hmm, that's a good point. However, the way the current Converters work > is that they remove the value that is entered by the user if it > doesn't convert properly. As you mentioned, this probably has to do > with the way exceptions are handled (putting back the previous value, > which happened to be empty). 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. The existing implementation of HasTextEditor<T, W> aims to be "convertable" at all times, so a conversion exception in widgetChanged() leads to redisplaying the previous value. You could do something else, like leave the invalid input but mark the field somehow. It's up to the application how it chooses to implement the Editor<T> interface. > I think that the validation that you have in mind is bean based > validation, which is being discussed already (http://code.google.com/p/ > google-web-toolkit/issues/detail?id=343). This is different from the > widget based validation which is currently in the incubator. Things > are all over the place right now, and I think we need some direction > from the GWT team. I have a lunch appointment earlier than I expected, so I haven't had a chance to look into validators or the link you just provided, but I'll look into them this afternoon. Ian --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
