IntegerBox not restricting input to integers in GWT 2.4.0

[Wayne Marsh]

Am I missing something? It just acts like a normal TextBox for me. Here's the simplest example:

import com.google.gwt.core.client.EntryPoint;

import com.google.gwt.user.client.ui.IntegerBox;

import com.google.gwt.user.client.ui.RootPanel;

/**

 * Entry point classes define <code>onModuleLoad()</code>.

 */

public class IntegerBoxExample implements EntryPoint

{

public void onModuleLoad()

{

IntegerBox box = new IntegerBox();

RootPanel.get().add(box);

}

}

I can type letters into it. Is it just broken (perhaps related to the notice "Experimental API: This class is still under rapid development, and is very likely to be deleted. Use it at your own risk." note in the documentation)?

[Alfredo Quiroga-Villamil]

If I am not mistaken that class is as the description you found says: "Not completed". Parent constructor is as follows:

  protected ValueBox(Element element, Renderer<T> renderer, Parser<T> parser) {

    super(element, renderer, parser);

    // BiDi input is not expected - disable direction estimation.

    setDirectionEstimator(false);

    if (LocaleInfo.getCurrentLocale().isRTL()) {

      setDirection(Direction.LTR);

    }

    assert InputElement.as(element).getType().equalsIgnoreCase("text");

  }

The assertion is for "text" and I don't see any validators for say Integer. So at first glance, didn't look to see if there is more going on behind the scenes, yeah, it's incomplete.

Regards,

Alfredo

--
You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.
To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/zGmwodizajMJ.
To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

--
Alfredo Quiroga-Villamil

AOL/Yahoo/Gmail/MSN IM:  lawwton

[Thomas Lefort]

Yes I have the same problem, also for other boxes like DoubleBox. I am pretty sure it used to work fine.

[Jens]

Everything that extends ValueBox (or better ValueBoxBase) like IntegerBox, DoubleBox, etc. allows you type everything you want into that boxes.

The difference to an ordinary TextBox is that ValueBoxBase has a getValue() and getValueOrThrow() method:

1.) getValue(): returns the defined type (e.g. Integer, Double, ...) if the content of the box is parseable to that type (see IntegerParser, DoubleParser, ..). If its not parseable or the box is empty then null is returned.

2.) getValueOrThrow(): does the same as getValue() but if the content is not parseable you can catch the ParseException.

So in case of an IntegerBox you can type everything, but once you call getValueOrThrow() you will see if its really an Integer in that box or not.

If you want to disallow letters in an IntegerBox you have to implement that yourself. In general I found it easier to just give some visual feedback that the content isn't parseable anymore. Maybe for live feedback something like:

integerBox.addKeyUpHandler(new KeyUpHandler() {

   void onKeyUp(...) {

      try {

        getValueOrThrow();

        clearErrorCss(integerBox);

      } catch(ParseException e) {

        setErrorCss(integerBox);

      }

   }

});

So these boxes are not broken. They are working as designed but you just expected something different.

-- J.

[Alfredo Quiroga-Villamil]

I respectfully see this slightly different. An IntegerBox should prevent the user from typing non-integers from the start with ways to customize the error message, etc... It's nice that it's generified, but one might expect it to have a validator built-in. Not that it would be terrible to add one as you point out, but it should be built-in since in this case the name is IntegerBox. If it would have been a NumberField or something along those lines, then the same could have been accomplished like GXT does by setting a property editor that could be Integer, Double, etc. So I don't see it doing 100% what it should do.

I see this as a potential feature request. An easy one to add, nevertheless, not one that the user should have to implement.

Best regards,

Alfredo

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/kaR928iw2dQJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Thomas Broyer]

On Friday, April 20, 2012 5:50:54 PM UTC+2, Alfredo Quiroga-Villamil wrote:

I respectfully see this slightly different. An IntegerBox should prevent the user from typing non-integers from the start with ways to customize the error message, etc... It's nice that it's generified, but one might expect it to have a validator built-in. Not that it would be terrible to add one as you point out, but it should be built-in since in this case the name is IntegerBox. If it would have been a NumberField or something along those lines, then the same could have been accomplished like GXT does by setting a property editor that could be Integer, Double, etc. So I don't see it doing 100% what it should do.

I see this as a potential feature request. An easy one to add, nevertheless, not one that the user should have to implement.

The problem is it's really hard to get it right given the discrepancies in keyboard events between browsers. 

[Jens]

I respectfully see this slightly different. An IntegerBox should prevent the user from typing non-integers from the start with ways to customize the error message, etc... It's nice that it's generified, but one might expect it to have a validator built-in. Not that it would be terrible to add one as you point out, but it should be built-in since in this case the name is IntegerBox. If it would have been a NumberField or something along those lines, then the same could have been accomplished like GXT does by setting a property editor that could be Integer, Double, etc. So I don't see it doing 100% what it should do.

Beside the fact that its not that easy to implement this behavior in a cross browser fashion as Thomas said, you should also keep in mind that GWT is a Toolkit and in my opinion a Toolkit should give developers a more general solution which can be further specified by developers and their requirements (validation behavior) instead of providing a too specific solution that you maybe can't modify well.

-- J.

[Alfredo Quiroga-Villamil]

I've been using NumberField for years in GXT. I seem to recall it working pretty well if my memory serves me right. There I can specify pretty easily the type as I previously mentioned, Integer, Double, etc.. perhaps I got spoiled, who knows. Recently I've been slowly switching to using a GWT only approach (GWT UI Widgets that is. I've obviously been using GWT for years)

I always try to keep in mind that GWT is a tool kit. However, when a class is named IntegerBox, to be used in a UI, yeah I expect it to be type safe and also do what its name implies in the UI as well as programmatically. In this case only allow Integers to be typed in.

In any case, I'll hang on to this email and instead of talking more, perhaps when I have some free time I'll just get to it and see if I can add the implementation for it, test it across browsers and submit it for a patch review. No promises since I am really busy these days, but we'll see.

Appreciate the responses.

Alfredo

-- J.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/RLtrB5vaIJQJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Andrei]

Alfredo,

What you propose is a bad design - from a usability perspective. When
a user presses a button and nothing happens, many users would assume
that your app is broken (they did press a letter for some reason!)
It's much better to give those less-than-sophisticated users a chance
to type a letter and then provide some feedback that this field only
accepts numbers.

Also, this way you can be consistent throughout all widgets. For
example, you can't prevent people from typing letters or numbers in
the DatePicker field. But they can type something which can't be
parsed into a date. When they do, the DatePicker turns red. You can
have exactly the same behavior with the IntegerBox - and any other
user input.

On a side note, I wish the GWT was itself more consistent with their
implementations - like having IntegerBox, LongBox, DoubleBox, and
DatePicker react in the same way to parsing errors.

Andrei

[Jens]

I always try to keep in mind that GWT is a tool kit. However, when a class is named IntegerBox, to be used in a UI, yeah I expect it to be type safe and also do what its name implies in the UI as well as programmatically. In this case only allow Integers to be typed in.

Some years ago when doing ordinary desktop applications I would probably expect the same. But today developing web applications my mind shifted and I found it more important to be liberal on the user input but tell the user if they have done something wrong. This just feels more like things work on the web and I want to preserve this feeling even in web applications because thats what people are used to when using the web.

Also inexperienced users may think their keyboard is somehow broken if nothing happens when typing a letter into an input box because its just so uncommon on the web to swallow user input.

In any case, I'll hang on to this email and instead of talking more, perhaps when I have some free time I'll just get to it and see if I can add the implementation for it, test it across browsers and submit it for a patch review. No promises since I am really busy these days, but we'll see.

Maybe it can be as easy as:

IntegerBox() {

 this(false); //makes sure that, by default, you get the same behavior as of today

}

IntegerBox(bolean strictMode) {

 super(Document.get().createInputElement(), IntegerRenderer.instance(), IntegerParser.instance(), strictMode ? IntegerInputValidator.instance() : null);

}

along with an additional constructor in ValueBox -> ValueBoxBase taking the input validator. If an input validator is present, ValueBoxBase attaches a key handler and routes key events through the validator (which can decide to swallow the key). That way you can opt-in to your desired behavior (you dont change behavior of existing apps) and you pretty much only have to implement input validators.

 

Appreciate the responses.

You are welcome 

-- J.

[Stefano Ciccarelli]

This is exactly what we have done. 

Turning every field red when it is invalid in real time (as a key is pressed) is definitely better. 

-- 
Stefano Ciccarelli

Sent with Sparrow

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

[Alfredo Quiroga-Villamil]

@Jen:

Your code and something along the lines to what you proposed would certainly work and be flexible enough.

@Andrei:

"When a user presses a button and nothing happens, many users would assume
that your app is broken (they did press a letter for some reason!)"

You always know when/what the user typed. The app would not look broken if upon the keydown and read of the key you know that it doesn't meet the specification and right away let the user know that "You can only type xxxx here"

Alfredo

-- J.

--

You received this message because you are subscribed to the Google Groups "Google Web Toolkit" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-web-toolkit/-/PG8WHFAnWBEJ.

To post to this group, send email to google-we...@googlegroups.com.
To unsubscribe from this group, send email to google-web-tool...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Craig Mitchell]

I implemented a filter that stop users entering the wrong thing.  I figured if TextBox.setMaxLength does it, then why not.

However, as Thomas pointed out, it's hard to do properly.  I ended up allowing the invalid input and then removing it in a scheduleDeferred command.  Not ideal as the user sees the invalid input flash up, but it at least works on all browsers.

Alfredo

To post to this group, send email to google-web-toolkit@googlegroups.com.
To unsubscribe from this group, send email to google-web-toolkit+unsub...@googlegroups.com.

For more options, visit this group at http://groups.google.com/group/google-web-toolkit?hl=en.

[Julio Feferman]

I'm running into the same issue but agree that IntegerBox should be a more general solution. Although this post is old I believe it is still relevant. I'm attaching an IntegerTextBox class I created which subclasses IntegerBox. This class uses a KeyDownHandler to verify when a number key or a numeric pad key is pressed. It also allows required keys for operation of the text box, such as backspace, delete, left and right arrow keys, etc and cancels other keys. You could add some CSS3 trickery or some other form of visual cue to warn the user if unsupported keys are pressed.

Best,

- Julio