Gelmiş geçmiş en büyük porno sitemiz olan 2pe de her zaman en kaliteli pornoları sunmayı hedefledik. Diğer video sitemiz olan vuam da ise hd porno ağırlıklı çalışmalara başladık.

  1. #1
    Ext GWT Premium Member icfantv's Avatar
    Join Date
    Sep 2011
    Location
    Superior, CO
    Posts
    411
    Answers
    20
    Vote Rating
    21
    icfantv will become famous soon enough icfantv will become famous soon enough

      0  

    Question Answered: Setting max length on TextField

    Answered: Setting max length on TextField


    Is there really no way to set the max length on a text field? I know I can use a max length validator but that doesn't prevent the user from entering more characters than is "allowed."

    There was a setMaxLength(...) in 2.x on the TextField object. Why was it pulled in favor of a validator?

  2. There is a way to set max length on a textfield.it passes the test to me.
    like this:

    public class MyTextField extends TextField {

    public MyTextField(){
    InputElement ie=this.getInputEl().cast();
    ie.setMaxLength(10);
    }


    }

  3. #2
    Sencha User PhiLho's Avatar
    Join Date
    Nov 2011
    Location
    Near Paris, France
    Posts
    139
    Answers
    2
    Vote Rating
    1
    PhiLho is on a distinguished road

      0  

    Default


    An obvious solution would be to set the maxlength attribute on the underlying input element, but I wasn't sure how to do it.
    I found a solution in a blog post:
    http://www.selikoff.net/2011/04/26/g...tfield-in-gxt/

  4. #3
    Ext GWT Premium Member icfantv's Avatar
    Join Date
    Sep 2011
    Location
    Superior, CO
    Posts
    411
    Answers
    20
    Vote Rating
    21
    icfantv will become famous soon enough icfantv will become famous soon enough

      0  

    Default


    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.

    I will use your posted solution. Thanks again.

  5. #4
    Ext GWT Premium Member icfantv's Avatar
    Join Date
    Sep 2011
    Location
    Superior, CO
    Posts
    411
    Answers
    20
    Vote Rating
    21
    icfantv will become famous soon enough icfantv will become famous soon enough

      0  

    Default


    Just getting back to this.

    In case anyone sees this in the future, here's what I've come up with - not sure if it's the "right" way, but it passes the smell test to me:

    public class BoundedTextField extends TextField {


    public BoundedTextField() {
    this(100);
    }


    public BoundedTextField(int maxLength) {


    super();
    if (maxLength <= 0) {
    throw new IllegalArgumentException("the max length must be positive: " + maxLength);
    }


    this.maxLength = maxLength;
    this.addValidator();
    }


    @Override
    public void onAfterFirstAttach() {


    XElement element = this.getInputEl();
    element.setAttribute("maxlength", Integer.toString(this.maxLength));
    }


    private void addValidator() {
    this.addValidator(new MaxLengthValidator(this.maxLength));
    }


    private final int maxLength;
    }

  6. #5
    Ext GWT Premium Member dardison's Avatar
    Join Date
    Apr 2008
    Location
    Buenos Aires, Argentina
    Posts
    168
    Vote Rating
    1
    dardison is on a distinguished road

      0  

    Default


    Hi,

    I would like to know what Sencha Team have to say about the issue.
    Anyone?

  7. #6
    Sencha Premium Member
    Join Date
    Jan 2012
    Posts
    8
    Vote Rating
    2
    SelzChi is on a distinguished road

      0  

    Default


    Hi,

    any news regarding this issue?

    Thanks,

    Selcuk

  8. #7
    Sencha User
    Join Date
    Jun 2012
    Posts
    1
    Answers
    1
    Vote Rating
    0
    Thunders is on a distinguished road

      0  

    Default Hi

    Hi


    There is a way to set max length on a textfield.it passes the test to me.
    like this:

    public class MyTextField extends TextField {

    public MyTextField(){
    InputElement ie=this.getInputEl().cast();
    ie.setMaxLength(10);
    }


    }

  9. #8
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default


    This should be made part of the TextField API, is there any reason Sencha is avoiding adding something a common place as this functionality with their components?

  10. #9
    Sencha - GXT Dev Team
    Join Date
    Feb 2009
    Location
    Minnesota
    Posts
    2,716
    Answers
    109
    Vote Rating
    87
    Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light Colin Alworth is a glorious beacon of light

      0  

    Default


    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:

    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.
    Last edited by Colin Alworth; 6 Nov 2012 at 2:26 PM. Reason: readability

  11. #10
    Ext GWT Premium Member
    Join Date
    Dec 2011
    Location
    Earth
    Posts
    243
    Vote Rating
    1
    nbuesing is on a distinguished road

      0  

    Default


    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.