It looks like that it is enough to comment out the if statement in the
ValueboxBase it solved the issue for me. But I am not sure what
collateral damages that imposes to the request factory way of things.
The patch did not break any test (?!?), and the fact that the
TextBoxBase does "undo" this behavior is a bit scaring:
ValueBoxBase:
/**
* Return the parsed value, or null if the field is empty or parsing
fails.
*/
public T getValue() {
try {
return getValueOrThrow();
} catch (ParseException e) {
return null;
}
}
/**
* Return the parsed value, or null if the field is empty.
*
* @throws ParseException if the value cannot be parsed
*/
public T getValueOrThrow() throws ParseException {
String text = getText();
T parseResult = parser.parse(text);
/* patched to fix inconsistent behaviour
if ("".equals(text)) {
return null;
}
*/
return parseResult;
}
TextBoxBase:
@Override
public String getValue() {
String raw = super.getValue();
return raw == null ? "" : raw;
}
On 20 Aug., 08:45, "P.G.Taboada" <pgtabo...@googlemail.com> wrote:
> That was the missing piece for me: the editor framework uses
> getvalueorthrow!
>
> The issue is here:
>
> http://code.google.com/p/google-web-toolkit/issues/detail?id=6713
>
> On Aug 19, 11:02 pm, Jens <jens.nehlme...@gmail.com> wrote:
>
>
>
>
>
>
>
> > Ok after digging around in GWT's source code:
>
> > TextBox uses the generic ValueBoxEditor (see link in my previous answer) and
> > does not have its own TextBoxEditor. The ValueBoxEditor knows the TextBox
> > (but as ValueBoxBase<T>, because the ValueBoxEditor is generic) and
> > calls ValueBoxBase.getValueOrThrow() to get the editor value. This call
> > returns null for empty Strings as mentioned before. Thats why you got null
> > for TextBoxes.
>
> > But I can see your point. TextBox overwrites ValueBoxBase<String>.getValue()
> > and changes null to an empty String. But it does not
> > overwrite ValueBoxBase<String>.getValueOrThrow(). So you end up having two
> > methods that return the value but they have a different result for an empty
> > String in the wrapped input element:
>
> > - getValue() returns an empty String (called by you in your example)
> > - getValueOrThrow() returns null (called by the editor framework)
>
> > In addition to these both methods you also have TextBox.getText() which
> > returns the text via a DOM operation. This method never returns null for an
> > empty TextBox so maybe thats why Google has overwritten getValue() to act
> > the same way. Unfortunately they forgot getValueOrThrow() which is used by
> > the Editor Framework. So I think its a bug in TextBoxBase: getText(),
> > getValue() and getValueOrThrow() should all act the same way.
>
> > Maybe you can open an issue and ask to align both getValue methods so that
> > they return the same for an empty string in the wrapped input element.
>
> > Hope that helps.
>
> > -- J.
--
You received this message because you are subscribed to the Google Groups
"Google Web Toolkit" group.
To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to
google-web-toolkit+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/google-web-toolkit?hl=en.
