Page 1 of 2 12 LastLast
Results 1 to 10 of 15

Thread: [CLOSED]panel / formPanel: buttons cannot be retrieved anymore

    Thank you for reporting this bug. We will make it our priority to review this report.
  1. #1
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Cologne, Germany
    Posts
    27
    Vote Rating
    0
      0  

    Default [CLOSED]panel / formPanel: buttons cannot be retrieved anymore

    In ExtJS 4, buttons defined in config via buttons[] Array cannot be retrieved anymore, because there is no method for easily accessing buttons.

    In ExtJS 3, buttons defined in config-section via buttons[] Array

    Code:
    buttons: [
                {   itemId: 'btnSave',
                    text: 'itemId = btnSave'
                },
                {   itemId: 'btnCancel',
                    text: 'itemId = btnCancel'
                }
            ]
    could be retrieved easily via:

    Code:
    mypanel.getFooterToolbar().getComponent('btnSave')

    In ExtJS 4, there is no FooterToolbar anymore and thus no 'getFooterToolbar()'.
    That means there is no method to retrieve buttons defined in config section.

    Please provide a method for easily accessing buttons defined in config section.
    Since handlers not making use of anonymous functions need to be assigned to buttons in initComponent(), it is necessary to have access to the buttons defined in the config section.

    Thanks!

  2. #2
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,211
    Vote Rating
    1005
      0  

    Default

    This isn't a bug. tbar/fbar/bbar Have been deprecated in favour of dockedItems:

    Code:
    Ext.require('*');
    
    Ext.onReady(function(){
        new Ext.Panel({
            width: 400,
            height: 400,
            renderTo: document.body,
            dockedItems: [{
                dock: 'bottom',
                xtype: 'toolbar',
                ui: 'footer',
                items: ['->', {
                    text: 'I am a button'
                }]
            }]
        });
    });
    Also, the buttons config is available for backwards compat:

    Code:
    Ext.require('*');
    
    Ext.onReady(function(){
        new Ext.Panel({
            width: 400,
            height: 400,
            renderTo: document.body,
            buttons: [{
                text: 'Foo'
            }]
        });
    });
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  3. #3
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Cologne, Germany
    Posts
    27
    Vote Rating
    0
      0  

    Default

    I think it is a little bit too early to mark this one as closed:

    When comparing the lines of code in your two examples, I have to say that the last example using config-section buttons[] is much more readable (less code) and applies to probably 90 % of all FormPanels. At least I have not seen too many forms where the save / cancel buttons where at the top or on the left or right.

    In a form, buttons are typically at the bottom, like it used to be the default with Ext JS 3.

    While I really do appreciate the flexibility that comes with Ext JS 4 (being able to position top, left, right, bottom), I think it is a step backwards to now always have to use this explicit way of configuring buttons for FormPanels (because otherwise buttons cannot be retrieved easily since there is no method available).

    Why is it not possible to provide a method for accessing buttons defined in config-section of a form panel?

    If buttons[] definition in config-section is deprecated, it needs to be marked so. The current Ext JS 4 documentation still has a long way to go, there is a lot of room for improvement. (sorry for saying that, but it's frustrating as hell to work with the current docs)

    If buttons[] definition in config-section is deprecated, Ext JS 4 does not support the DRY-principle (Don't Repeat Yourself), because it forces developers for 90% of all cases (buttons at the bottom of the form) to write the same code (toolbar definition) again and again.

    Does it really make sense to deprecate the buttons[] config section and not to provide a method for easily accessing buttons in bottom toolbar?

    Thanks (I appreciate all the hard work you are putting into Ext JS 4)

  4. #4
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Cologne, Germany
    Posts
    27
    Vote Rating
    0
      0  

    Default

    well, looks like retrieving a button defined in buttons[] is relatively easy with the new Ext JS 4 Ext.ComponentQuery

    http://dev.sencha.com/deploy/ext-4.0...nentQuery.html

    as pointed out here: http://www.sencha.com/forum/showthre...8-Ref-Property

    So to address a button defined in

    Code:
    buttons: [
                {   itemId: 'btnSave',
                    text: 'Save'
                },
                {   itemId: 'btnCancel',
                    text: 'Cancel'
                }
            ]

    one can use

    myComponent.query('#btnSave')

    which returns an Array with found components with itemId 'btnSave', i.e. the button reference will be
    myComponent.query('#btnSave')[0].

    While it is not ideal I can live with that.

    This still leaves the question, whether it makes sense to mark buttons[] config section as deprecated.

  5. #5
    Sencha Premium User evant's Avatar
    Join Date
    Apr 2007
    Location
    Sydney, Australia
    Posts
    19,211
    Vote Rating
    1005
      0  

    Default

    Code:
    // Selects a single item
    panel.down('#foo');
    
    // or
    var toolbar= panel.getDockedItems().itemAt(index);
    It will be added to the upgrade guide that it's been deprecated.

    I don't really agree that this is any violation of the DRY principle. The docked items can apply to ~any~ panel, not just a form panel. You're isolating a very specific case. Writing:

    Code:
    buttons: [{
        text: 'Foo'
    }]
    vs

    Code:
    dockedItems: [{
        dock: 'bottom',
        xtype: 'toolbar',
        items: [{
            text: 'Foo'
        }]
    }]
    Is only a couple of lines more and infinitely more flexible. It also gives greater granularity in how the toolbar is laid out which was much more difficult previously.
    Twitter - @evantrimboli
    Former Sencha framework engineer, available for consulting.
    As of 2017-09-22 I am not employed by Sencha, all subsequent posts are my own and do not represent Sencha in any way.

  6. #6
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Cologne, Germany
    Posts
    27
    Vote Rating
    0
      0  

    Default

    I doubt that I am isolating a very specific case.
    When it comes to working with forms, the 90% case in a form is: buttons at the bottom.

    So 'flexibility' in this case is NOT what a form developer needs.
    Rather more a convenient way to
    • define buttons
    • access buttons for attaching handlers when the component gets initialized

    is required.

    With the buttons[] config being deprecated in Ext JS 4, I now need to build a solution myself since the example you provided makes it obvious that it's not easy to identify buttons immediately, i.e. at first sight when looking at the code.

    It's not a question of agreeing or disagreeing, it's just a fact that

    Code:
    buttons: [
                {   itemId: 'btnSave',
                    text: 'Save'
                },
                {   itemId: 'btnCancel',
                    text: 'Cancel'
                }
            ]
    is self-explanatory (shows at first sight what the buttons are) and needs little code, while

    Code:
    dockedItems: [{
        dock: 'bottom',
        xtype: 'toolbar',
        itemId: 'button_toolbar',
        items: [
           {
            itemId: 'btnSave',
            text: 'Save'
           },
           {
            itemId: 'btnCancel',
            text: 'Cancel'
           }
        ]
    }]
    is not only more code but also less self-explanatory.

    I appreciate flexibility, but when it comes to working with forms I dislike always having to build a workaround for the 90% case only to get flexibility for the 10% where it's needed.

    A good framework from my point of view is one, that makes it easy / convenient to solve the 90% case. Currently Ext JS 4 is flexible, but it does not make it easy / convenient to solve the 90% case when it comes to working with forms (and having buttons at the bottom).

    Just my 5 cents....

  7. #7
    Sencha User Seana's Avatar
    Join Date
    Jun 2010
    Posts
    82
    Vote Rating
    0
      0  

    Default

    Quote Originally Posted by jan.harmsen View Post
    I doubt that I am isolating a very specific case.
    When it comes to working with forms, the 90% case in a form is: buttons at the bottom.

    So 'flexibility' in this case is NOT what a form developer needs.
    Rather more a convenient way to
    • define buttons
    • access buttons for attaching handlers when the component gets initialized

    is required.

    With the buttons[] config being deprecated in Ext JS 4, I now need to build a solution myself since the example you provided makes it obvious that it's not easy to identify buttons immediately, i.e. at first sight when looking at the code.

    It's not a question of agreeing or disagreeing, it's just a fact that

    Code:
    buttons: [
                {   itemId: 'btnSave',
                    text: 'Save'
                },
                {   itemId: 'btnCancel',
                    text: 'Cancel'
                }
            ]
    is self-explanatory (shows at first sight what the buttons are) and needs little code, while

    Code:
    dockedItems: [{
        dock: 'bottom',
        xtype: 'toolbar',
        itemId: 'button_toolbar',
        items: [
           {
            itemId: 'btnSave',
            text: 'Save'
           },
           {
            itemId: 'btnCancel',
            text: 'Cancel'
           }
        ]
    }]
    is not only more code but also less self-explanatory.

    I appreciate flexibility, but when it comes to working with forms I dislike always having to build a workaround for the 90% case only to get flexibility for the 10% where it's needed.

    A good framework from my point of view is one, that makes it easy / convenient to solve the 90% case. Currently Ext JS 4 is flexible, but it does not make it easy / convenient to solve the 90% case when it comes to working with forms (and having buttons at the bottom).

    Just my 5 cents....
    I'm going to disagree with you on a couple of points.

    #1) When working with forms, in your usage it maybe 90% you need Buttons at the bottom, However in my current project all of the form submit/clear/cancel buttons are on a Toolbar at the top of the panel because that's where they "flow" in the layout. So in my case the 3.x buttons: [] style is 100% useless and this goes for the last two projects that I've worked on.

    #2) On the explanation front: I'm looking forward to the dockedItems config as it is far more versatile, and with the exception of coming from a "purely Previous ExtJS background" is far more explanatory than buttons:[] which tells you only that they are buttons, not that they are docked, nor where they reside in the layout.

    The point that I'm looking to make here is that while in your context these uses maybe the 90% case they aren't necessarily the global 90% let alone the global majority. Should it really be that much of an issue, a simple subclassing of Panel that handles a buttons:[] style config array and defines the expected use for getFooterToolbar() should be simple, very little time to write and that class is instantly available to you 100% of the time to use.
    Sean

  8. #8
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Cologne, Germany
    Posts
    27
    Vote Rating
    0
      0  

    Default

    Nothing wrong with disagreeing :-)

    But let's look at some facts:

    • In the western world, text is written from left to right and from top to bottom, like this thread / post.
    • Due to this, in the western world forms get filled out from top to bottom.
    • Unless screen size is restricted, it is thus natural for users filling out a form to find buttons for saving (submitting) / canceling right at the bottom of the form


    Thus this is not an isolated case but applies to probably more than 90% of all forms on the web being viewed by PCs / Macs (note, I'm excluding phones here since phones have restricted screen space). In the western world it is just a common best practice to place buttons for submitting / canceling a form at the bottom of the form, based on the way people work.

    Of course a designer / developer is free to put the buttons wherever he/she wants: At the top or on the left or on the right. And there are cases where this makes sense. But for the western world and PC / Mac clients, usability principles recommend to place buttons where a user filling out a form expects buttons -- and this is at the bottom due to the workflow described above. Period.

    Last but not least:
    Yes, you are right.
    It is a piece of cake of subclassing FormPanel and making it the way I need it.
    And there will be many others subclassing FormPanel, now that buttons[] is gone. That's the way the cookie crumbles ;-)

  9. #9
    Sencha User Condor's Avatar
    Join Date
    Mar 2007
    Location
    The Netherlands
    Posts
    24,246
    Vote Rating
    132
      0  

    Default

    This is something for the legacy .js file:
    It should add the getTopToolbar(), getBottomToolbar() and getFooterToolbar() methods and the 'tbar', 'bbar', 'fbar' and 'buttons' properties to Ext.panel.Panel.

  10. #10
    Sencha User Seana's Avatar
    Join Date
    Jun 2010
    Posts
    82
    Vote Rating
    0
      0  

    Default

    Quote Originally Posted by jan.harmsen View Post
    • Unless screen size is restricted, it is thus natural for users filling out a form to find buttons for saving (submitting) / canceling right at the bottom of the form
    When using ExtJS I always have restricted screen size, because I'm building an application not a web page, while for strait web pages I whole heartedly agree with your flow.

    ExtJS is an Application Framework, and if MFC ever taught me anything, Frameworks always have places that you wish you could change 'em

    And I agree, there's nothing wrong with disagreeing
    Sean

Page 1 of 2 12 LastLast

Similar Threads

  1. [CLOSED]Component.ref does not work anymore
    By htammen in forum Ext:Bugs
    Replies: 5
    Last Post: 23 Feb 2011, 3:06 PM
  2. Replies: 9
    Last Post: 17 Aug 2009, 12:12 AM
  3. [CLOSED] Reordered Sequence Cannot be Retrieved in TreePanel
    By nyklogistics in forum Ext GWT: Bugs (2.x)
    Replies: 1
    Last Post: 25 Jun 2009, 5:32 AM

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •