1. #11
    Sencha Premium Member ethraza's Avatar
    Join Date
    Jun 2007
    Location
    Brazil
    Posts
    362
    Vote Rating
    3
    ethraza is on a distinguished road

      0  

    Exclamation


    Ohw, I'm glad to find this post.
    I'm passing by it right now using Ext 2.0.2 version. I destroy the field but the label remains.

    This fix is already on SVN or who wants to destroy/hide a form field do better overriding the FormLayout?

    Maybe is time to open a "bug by omission" ticket?


    ps. Thanks Animal!
    LAMPE (Linux / Apache / MySQL / PHP / ExtJs)

  2. #12
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,496
    Vote Rating
    44
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    No, Jack has not changed the FormLayout class. I assume there must be a reason for this.

  3. #13
    Sencha User jack.slocum's Avatar
    Join Date
    Mar 2007
    Location
    Tampa, FL
    Posts
    6,955
    Vote Rating
    16
    jack.slocum will become famous soon enough

      0  

    Default


    Unfortunately we can't make this change because it is not backwards compatible and might not be desirable in some scenarios.

    For example, I recently did a services project where we had a form with 2 modes, editable and non-editable. When non-editable, the fields were displayed as text and when editable they were a field. When switching between the 2 views, fields were destroyed and the text was again created. The labels and remaining markup always remained.

    I do however agree that an easier method of adding a removing fields, including labels, is needed. The solution may be in the field class itself, with a destroy (or beforedestroy) handler which does an up() call and removes undesired markup. The same can be applied to hide. Maybe implemented as a simple plugin?
    Jack Slocum
    Ext JS Founder
    Original author of Ext JS 1, 2 & 3.
    Twitter: @jackslocum
    jack@extjs.com

  4. #14
    Sencha - Ext JS Dev Team Animal's Avatar
    Join Date
    Mar 2007
    Location
    Notts/Redwood City
    Posts
    30,496
    Vote Rating
    44
    Animal has a spectacular aura about Animal has a spectacular aura about Animal has a spectacular aura about

      0  

    Default


    A mode flag for fields? actionMode: 'field' or actionMode:'wrapper'.

    Possibly actionMode:Ext.form.Field.FIELD or actionMode:Ext.form.Field.WRAPPER

    This could be a config of FormLayout, and could make both showing/hiding and destroying use the wrapper instead of the contained field.

  5. #15
    Sencha - Community Support Team Condor's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    24,246
    Vote Rating
    82
    Condor has much to be proud of Condor has much to be proud of Condor has much to be proud of Condor has much to be proud of Condor has much to be proud of Condor has much to be proud of Condor has much to be proud of Condor has much to be proud of

      0  

    Default


    That works for hiding and disableing fields, but not for destroying fields (Ext.Component.destroy() only checks for actionMode == "container").

  6. #16
    Sencha Premium Member ethraza's Avatar
    Join Date
    Jun 2007
    Location
    Brazil
    Posts
    362
    Vote Rating
    3
    ethraza is on a distinguished road

      0  

    Default


    Hi, I'm using that override but I passing by another problem.

    If I create a textfield (or any other) with disabled:true when I do a .enable() the field enables but x-item-disabled css remains on the field letting it grayed. There is a tune to this override to fix that or I'll need to take x-item-disabled out by hand?

    Thanks!
    LAMPE (Linux / Apache / MySQL / PHP / ExtJs)

  7. #17
    Ext User
    Join Date
    Mar 2008
    Posts
    60
    Vote Rating
    1
    joku is on a distinguished road

      0  

    Default


    I was having this problem and used the override. When I did something like:
    myPanel.cascade(function(cmp){ if(cmp.isFormField) myPanel.remove(cmp,true);});

    I was getting a some Container C[T] error...

    Then I switched to something like:
    myPanel.cascade(function(cmp){if(cmp.isFormField) cmp.destroy();});

    This removed the items from rendering on the panel, but the objects still existed in the myPanel.items.items array... and whenever I would call cascade on the panel, those components would be passed in.

    In my case, it was okay to add another container to the panel, so now I just create a FieldSet, populate that with my form fields and then add/remove the FieldSet from myPanel. This works.... but if there is something I'm missing or a better way to do things, please let me know. Thanks!

  8. #18
    Sencha User
    Join Date
    Mar 2007
    Posts
    210
    Vote Rating
    1
    KRavEN is on a distinguished road

      0  

    Default


    If the element that is being hidden is inside a fieldSet, how do you make the fieldset resize to not have empty space where the form element was located.

    If I destroy the element, the fieldset shrinks and there is no empty space.

  9. #19
    Sencha User
    Join Date
    Mar 2007
    Posts
    210
    Vote Rating
    1
    KRavEN is on a distinguished road

      0  

    Default


    Quote Originally Posted by KRavEN View Post
    If the element that is being hidden is inside a fieldSet, how do you make the fieldset resize to not have empty space where the form element was located.

    If I destroy the element, the fieldset shrinks and there is no empty space.
    Well, the answer is that as long as hideMode is the default, it should behave like I want. The problem I was running into is that the Ext.ux.RadioGroup extension I was using hadn't implemented support for hideMode. So once I put that in, everything works as expected.

  10. #20
    Sencha Premium Member
    Join Date
    Jun 2007
    Posts
    46
    Vote Rating
    0
    spaque99 is on a distinguished road

      0  

    Default


    Any news on making this part of the ext code in some kind of ways? The override seems to work fine for me, but I always like to avoid override of the core code...

    Thanks
    Seb