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