> I'm not sure what you mean. Are you looking to avoid updating the > bean until sometime after the editor has changed?
Yes, I'm looking to avoid updating the bean automatically. I want to specify when the bean should be updated. 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 understand the converters as a way to map between a textual widget > and some non-String data type T. To me, a validator has as a first > assumption that the value it's validating is at least of the right > type. For example, validation on a birth date might require that the > birth date be before System.currentTimeMillis(), but the validator > would assume that it's validating a Date and not a String. In this > case, the converters are necessary as a first pass before the > validators. > > I haven't looked at the validators, though, so I'll have a look when I > get to the office and think it over some more. 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 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. > Thanks! And thanks for looking at it, too. Besides documentation > (and tests, I guess) another big thing that needs to be handled is > i18n. Right now, the best way to get nice labels for bound fields is > with the @Label annotation. That should probably go away and, > instead, the FormGenerator should spit out a Form implementation that > gets its labels from a properties file via a Constants subtype. I'm > not sure the best way to do that, though, because I haven't used GWT's > i18n facilities much. We'll try to take a closer look and see if we can help out. We need to get started on some of our projects, but this data binding framework would be very helpful since we build/will build a lot of form based applications. Thanks for sharing your code! On Oct 7, 10:20 am, "Ian Petersen" <[EMAIL PROTECTED]> wrote: > On Tue, Oct 7, 2008 at 9:28 AM, Arthur Kalmenson <[EMAIL PROTECTED]> wrote: > > - Is it possible to run the binding on demand instead of automatically > > with the attached listeners? Say I want to only run the binding after > > the user pressed the submit button, is that possible? > > I'm not sure what you mean. Are you looking to avoid updating the > bean until sometime after the editor has changed? > > > - the converters are useful for general data mapping, but they also > > seem to be performing the role of validator. Is it possible to use the > > validation framework from the incubator or the one proposed here: > >http://code.google.com/p/google-web-toolkit/issues/detail?id=343#c30. > > Or, should the converters continue to perform the role of converting > > the data to match the binded data type? The converters wouldn't be a > > problem if the binding could be delayed and allow validation to run > > it's course. > > I understand the converters as a way to map between a textual widget > and some non-String data type T. To me, a validator has as a first > assumption that the value it's validating is at least of the right > type. For example, validation on a birth date might require that the > birth date be before System.currentTimeMillis(), but the validator > would assume that it's validating a Date and not a String. In this > case, the converters are necessary as a first pass before the > validators. > > I haven't looked at the validators, though, so I'll have a look when I > get to the office and think it over some more. > > > - when executing Integer.parseInt() in the converters on non Integers, > > an exception should be thrown, but it seems to be getting caught > > somewhere. Where is that happening? > > I'm guessing without looking at the source code, but I think you're > talking about HasTextEditor<T, W>.widgetChanged(). There's some code > that looks roughly like this (the code might be different, and there > aren't as many comments): > > private void widgetChanged() { > try { > // calls converter.fromString(widget.getText()); > this.value = doReadValue(); > > if (this.listeners != null && !this.listeners.isEmpty()) { > // fire an EditorChangeEvent to notify listeners... > } > } > catch (ConversionException e) { > // I think this is the exception you're expecting and I'm swallowing > } > > // reformat and display the current value, > // which won't have changed if the user's > // input couldn't be parsed by the converter > doDisplayValue(); > > } > > HasTextEditor<T, W> wraps a widget of type <W extends Widget & HasText > & SourcesChangeEvents> and it attaches a ChangeListener to that widget > that, in onChange(Widget sender), invokes the appropriate > widgetChanged() method. The widgetChanged() method takes care of > parsing the user's input into a value of type T. If the user's input > can't be parsed, the converter will throw a ConversionException, but > the HasTextEditor<T, W> swallows that exception and just redisplays > its previous value. This behaviour forces the widget to always be > displaying a value of type T formatted according to the subclass's > instructions. > > > This framework looks very promising and well thought out. A less > > verbose binding mechanism would be nice, but I'm not entirely sure how > > it would be done. Thanks for the great work, I hope that this makes it > > into the incubator soon. > > Thanks! And thanks for looking at it, too. Besides documentation > (and tests, I guess) another big thing that needs to be handled is > i18n. Right now, the best way to get nice labels for bound fields is > with the @Label annotation. That should probably go away and, > instead, the FormGenerator should spit out a Form implementation that > gets its labels from a properties file via a Constants subtype. I'm > not sure the best way to do that, though, because I haven't used GWT's > i18n facilities much. > > Ian --~--~---------~--~----~------------~-------~--~----~ http://groups.google.com/group/Google-Web-Toolkit-Contributors -~----------~----~----~----~------~----~------~--~---
