Setting max length on TextField

[progmate]

I achived maxlength through ComponentPlugin.
I don't like to extend controls.
Did not yet decided which way is better.

public class MaxLengthComponentPlugin implements ComponentPlugin<ValueBaseField<?>> {
    int maxLength = -1;
    public MaxLengthComponentPlugin(int maxLength) {
        this.maxLength = maxLength;
    }
    @Override
    public void initPlugin(final ValueBaseField<?> component) {
        if (component.isRendered() && maxLength > 0) {
            getInputEl(component).setAttribute("maxLength", "" + maxLength);
        }
        component.addAttachHandler(new AttachEvent.Handler() {
            @Override
            public void onAttachOrDetach(AttachEvent arg0) {
                if(maxLength > 0) {
                    getInputEl(component).setAttribute("maxLength", "" + maxLength);
                }
            }
        });
    }
    protected XElement getInputEl(ValueBaseField<?> component) {
        return XElement.as(component.getCell().getInputElement(component.getElement()));
    }
}

[traviter]

The workaround on setting on the InputElement does not seem to work. I assume this is because the input element is overwritten every time the cell is rendered.

I delved down the Cell/Appearance rabbit hole and managed to get maxlength working with some very messy render overrides. This is definitely something that just belongs in the API.

The key would be adding maxlength to the FieldAppearanceOptions (or more correctly - a new text-specific subclass since this shouldn't affect some fields such as checkboxes). If the change is made there, it won't break anyone's existing code because it just adds getters and setters for maxlength on the options, cells, and fields. The default cell and appearance render methods would need to be updated to call setMaxLength() and getMaxLength() respectively to/from the FieldAppearanceOptions. But this still doesn't break anyone with custom cells and appearances. Even entirely custom render methods will still work - they just won't support maxlength without an update. So yes, you're still getting the "bad code" smell in that regard, but there's not much you can do to stay in sync when such a large and fundamental piece such as render() has to be overridden. Anyone who does so should know that changes at that level carry a certain level of risk and technical debt. Hence, this is why I'd like to reduce my own risk, and just see it in the API.

In any case, those are my thoughts. I can probably contribute code if I can get set up to do so.

[icfantv]

@traviter, we've been using the input element solution for several years now from beta2 to 3.0.5 and haven't had any issues.

It is possible that the way you are setting the max length attribute is being clobbered by a re-render. This could happen if you are doing it programmatically at some point in your code that would allow this behavior to occur.

As Colin noted, there are several (and I count at least three) solutions that work in this thread. Surely one of them will work for you. If not, please post your code and we would be happy to try and assist you further.

[Colin Alworth]

I'm not going to touch on the feasibility of the current solutions /workarounds without a code sample that follows one of those paths and *doesnt* work correctly (icfantv seems to be better versed than I on them anyway), but I wanted to comment again on including a solution in GXT itself. If you wish to propose a solution, make sure it works cross browser, and not just in one or two widgets - someone will eventually point out that the feature definitely needs to work in IE 6-8 and opera, and definitely needs to work on TextArea as well as TextField. Quoting from myself earlier in this thread:

First, my references for this:
[1] https://developer.mozilla.org/en-US/...attr-maxlength
[2] http://wufoo.com/html5/attributes/03-maxlength.html

MDN apparently indicates that this is a HTML5 feature [1], which makes me concerned that not all browsers will support this. I then tested a demo [2] 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 [2] - 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.

[fasfsfgs]

I was using NumberField and I wanted this maxLength feature like you all do.

My solution (all working so far) is this:

new NumberField() {
    @Override
    public void setMaxLength(int m) {
        super.setMaxLength(m);
        if (rendered) {
            getInputEl().setElementAttribute("maxLength", m);
        }
    }

    @Override
    public void onRender(Element target, int index) {
        super.onRender(target, index);
        getInputEl().setElementAttribute("maxLength", getMaxLength());
    }
};