Yes, that is an obvious solution indeed. :-) How to actually get to the DOM element is the tricky part.
Thanks for that post. The solution I thought of (but was dreading) was something we had to do back in my Java Swing days which was to add a key up listener to the field and when the limit was hit, stop allowing input. But it's annoying because you still have to allow for the backspace and delete keys.
Short answer: There are good solutions already presented here - I can agree that this looks like a useful feature to add, but one that can be added without requiring that the library itself be modified. We aren't avoiding this, but it isn't quite as straightforward as just adding a setter method in the TextField class.
Really long answer (with my apoligies: once I got going on the topic, I apparently couldn't stop):
As to why we haven't made the change ourselves: From the perspective of users only directly manipulating the Widgets that extends TextField, its pretty easy - you just want a setter that modified this dom attribute so the browser takes care of it for you.
From an API perspective, this feature belongs in the ValueBaseField class, the root class from which TextArea, ComboBox, TextField, etc are started - these all have an InputElement somewhere in them that can be manipulated, or something very much like it.
Then you think about the Cells - really, most of the ValueBaseInputCells should support this so that they can be added directly to a ColumnConfig in a Grid/TreeGrid, a Tree, a ListView, or any Cell Widget in GWT itself. Since there isn't any logic typically involved, it truly does belong in the cell - its just details of how to put the elements and attributes on the page - no real Widget logic required. So we add it in the appropriate place in that type tree, and methods that allow it to be set from the Fields themselves.
But (anyone see yet where I'm going?) the DOM manipulation in a modern, re-themeable GWT library doesn't belong in either the Widget or the Cell subclasses. This kind of direct manipulation really belongs one step lower - the appearance, directly responsible for all initial drawing and updates, as well as checking for where events have occurred, and if they have a special meaning. So we move it there, and modify the API accordingly for all ValueBaseFieldAppearance subtypes. And this means that anyone who is building custom appearances for their own organization needs to go through and update all of their appearances for textfield, textarea, combobox, spinnerfield, datefield, numberfield, etc, whether or not they even use this feature.
API changes can't be taken lightly, and we've already been perhaps too abusive with our changes - even when we document them, there are several organizations that use GXT with their own internal themes that need to rebuild their appearances to fit our extra methods, arguments, etc. Likewise, we can't just add these new features where they will probably be used (i.e. in TextField itself), or we'll be hearing about the 'bad code smell' from anyone who has a NumberField or a ComboBox and wants this.
As with most interesting problems out there, if it was easy, we probably would have done it, or are just not aware of it. This is the Q&A forum, not Discussion, not Feature Requests, so some amount of latitude could perhaps be granted there as well. Okay - so long-winded abstraction rant out of the way, the feature itself:
MDN apparently indicates that this is a HTML5 feature , which makes me concerned that not all browsers will support this. I then tested a demo  in IE8, and found that while the <input> behaved as expected, the <textarea> did not. So for some browsers, our Cell will need event handlers specific to this, trying to make the behavior consistent.
Back to the demo  - this page indicates that Opera, which GXT supports, has an alternative implementation. Apparently instead of preventing the user from typing, an in-browser tooltip appears, warning the user that the entered (or pasted! there is another test case to have to handle, in all browsers...) text is too long and should be cut down.
So we're not avoiding this because we're lazy - we're targeting the bugs that are affecting users, and adding the features that won't break existing builds (at least for bugfix releases, 3.1 again may change some APIs), and we've got to take much more care with all browsers and all features than the answers provided in this section. If someone puts together a full solution dealing with all the addressed concerns (that I came up with testing two browsers and writing this in 20 minutes) and would like to sign a CLA to have it contributed, that is more than reasonable - it is welcomed!
Commonplace? Yes. Easy? No. Avoiding? No. No one wins if we just pepper in new features halfbaked and poorly executed, especially while we have a community that can present workarounds, as has happened here.
Last edited by Colin Alworth; 6 Nov 2012 at 2:26 PM.
Thanks for the feedback/information, quite helpful.
I am not a fan of a work-around being considered the solution to a problem by a vendor, since that means I may have to come up with another work around (or worse yet it fails to work completely) with a new release (including a simple bug-fix release) of the product. That being said, there is more to take into account, based on all the feedback you provided.