1. #1
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Luxembourg
    Posts
    193
    Answers
    2
    Vote Rating
    1
    EAHC-IT is on a distinguished road

      0  

    Question Unanswered: Clarify : getCmp vs Up/down

    Unanswered: Clarify : getCmp vs Up/down


    Hello,

    I am wandering what is the most efficient the getCmp or the up/down method?
    The added value of the up/down is that it avoid the use of id/itemid.
    The added value of getCmp is that you can evoke at any place any component.

    Let says that I have something like:
    Window (id/itemid = 'mywin')
    --Toolbar
    ----Button 'Save'
    ----Button 'Close'
    --Form (id/itemid= 'myform')
    ----Textfield 'Register number' (id/itemid = 'tfreg')

    The handler (onClick) on the save, obviously, will send the form data:
    1) Ext.getCmp('myform').getForm().submit(...)
    or
    2) button.up('window').down('form').getForm().submit(...)

    The handler (onClick) on the close, will close the window:
    1) Ext.getCmp('mywin').close();
    or
    2) button.up('window').close();

    In extension, I can do check on the textfield on the save like:
    1) if (Ext.getCmp('tfreg').getValue !== '***') {...}
    or
    2) button.up('window').down('#tfreg').getValue !== '***') {...}

  2. #2
    Sencha Premium Member vadimv's Avatar
    Join Date
    Sep 2010
    Location
    Chisinau, Moldova
    Posts
    642
    Answers
    21
    Vote Rating
    25
    vadimv will become famous soon enough vadimv will become famous soon enough

      1  

    Default


    Quote Originally Posted by EAHC-IT View Post
    Hello,

    I am wandering what is the most efficient the getCmp or the up/down method?
    The added value of the up/down is that it avoid the use of id/itemid.
    The added value of getCmp is that you can evoke at any place any component.
    - Up and Down uses ComponentQuery, as argument here you can use any selector you want according to the ComponentQuery
    - getCmp searches in ComponentManager's hash map only by id

    So you can't compare them because are used in different scenarios even if both return components

  3. #3
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Luxembourg
    Posts
    193
    Answers
    2
    Vote Rating
    1
    EAHC-IT is on a distinguished road

      0  

    Default


    Quote Originally Posted by vadimv View Post
    - Up and Down uses ComponentQuery, as argument here you can use any selector you want according to the ComponentQuery
    - getCmp searches in ComponentManager's hash map only by id

    So you can't compare them because are used in different cases even if both return components
    So the question is: when using one or the other (in term of best practice, recommended practice, performance...)

  4. #4
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,499
    Answers
    527
    Vote Rating
    283
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      2  

    Default


    Best practice is to avoid the use of fixed ids. In most cases this rules out Ext.getCmp.

    The added value of getCmp is that you can evoke at any place any component.
    If creating implicit singletons (i.e. global variables) is acceptable then sure... but if you care about best practices then don't go near it. A well-architected application should establish the links between its components without resorting to globals, the same as in any other environment.

  5. #5
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Luxembourg
    Posts
    193
    Answers
    2
    Vote Rating
    1
    EAHC-IT is on a distinguished road

      0  

    Default


    Quote Originally Posted by skirtle View Post
    Best practice is to avoid the use of fixed ids. In most cases this rules out Ext.getCmp.
    If creating implicit singletons (i.e. global variables) is acceptable then sure... but if you care about best practices then don't go near it. A well-architected application should establish the links between its components without resorting to globals, the same as in any other environment.
    It is was I am doing in our app (reduce the use of getCmp).
    But I still need ID's (I think) (so getCmp) to link window or pass parameters to a window. Except is there is another way.
    The globals are set a custom properties of APP.

    I.E.
    -window (modal=true)
    --gridpanel (id=myGP)
    ----toolbar
    ------button:
    --------onClick -> Ext.widget('mywform').show();
    -window (id=mywform,modal=true)
    --form
    ----textfield
    ----button
    ------onClick ->button.up('form').getForm().submit();
    ......................Ext.getCmp('myGP').getStore().load();
    ......................button.up('window').close();

  6. #6
    Sencha Premium Member vadimv's Avatar
    Join Date
    Sep 2010
    Location
    Chisinau, Moldova
    Posts
    642
    Answers
    21
    Vote Rating
    25
    vadimv will become famous soon enough vadimv will become famous soon enough

      1  

    Default


    A few suggestions:
    1. In this concrete case you can use just Ext.getStore('store's_name_bound_to_myGP').load();
    2. Use a controller, which means to use ComponentQuery
    3. Store/link the reference of first window in a property of the second one.
    4. Use ComponentQuery

    When to use each one depends on the scenario. As wrote, for your example I would use 1, if is only to load the store, if is more then see if you can use a controller.

  7. #7
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Luxembourg
    Posts
    193
    Answers
    2
    Vote Rating
    1
    EAHC-IT is on a distinguished road

      0  

    Default


    Thanks vadimv and skirtle

  8. #8
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Luxembourg
    Posts
    193
    Answers
    2
    Vote Rating
    1
    EAHC-IT is on a distinguished road

      0  

    Thumbs up Two good

    Two good


    Well those two informations are leading to a better understanding (at least for me)
    Quote Originally Posted by skirtle View Post
    Best practice is to avoid the use of fixed ids. In most cases this rules out Ext.getCmp.
    If creating implicit singletons (i.e. global variables) is acceptable then sure... but if you care about best practices then don't go near it. A well-architected application should establish the links between its components without resorting to globals, the same as in any other environment.
    Quote Originally Posted by vadimv View Post
    A few suggestions:
    1. In this concrete case you can use just Ext.getStore('store's_name_bound_to_myGP').load();
    2. Use a controller, which means to use ComponentQuery
    3. Store/link the reference of first window in a property of the second one.
    4. Use ComponentQuery

    When to use each one depends on the scenario. As wrote, for your example I would use 1, if is only to load the store, if is more then see if you can use a controller.

  9. #9
    Ext JS Premium Member
    Join Date
    Dec 2010
    Location
    Luxembourg
    Posts
    193
    Answers
    2
    Vote Rating
    1
    EAHC-IT is on a distinguished road

      0  

    Default


    Quote Originally Posted by skirtle View Post
    Best practice is to avoid the use of fixed ids. In most cases this rules out Ext.getCmp.
    If creating implicit singletons (i.e. global variables) is acceptable then sure... but if you care about best practices then don't go near it. A well-architected application should establish the links between its components without resorting to globals, the same as in any other environment.
    Let say that I have a window (with a form) that can be invoked "differently";
    - A button, that launch the window but no data will be loaded in the form, for new entries
    PHP Code:
    Ext.widget('w_p_adm_addcntr').showAt(0,0); 
    - A button, that launch the window but with data, from update entry.
    PHP Code:
    Ext.widget('w_p_adm_addcntr').showAt(0,0);
    Ext.getCmp('w_p_adm_addcntr').fn_load(1,1,'-'); 
    How can I avoid the use of IDs and getCmp?

    It would be great if we could access component through such notation:
    myApp.app.w_p_adm_addcntr.fn_load(1,1,'-')

  10. #10
    Sencha Premium Member skirtle's Avatar
    Join Date
    Oct 2010
    Location
    UK
    Posts
    3,499
    Answers
    527
    Vote Rating
    283
    skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future skirtle has a brilliant future

      1  

    Default


    Quote Originally Posted by vadimv View Post
    1. In this concrete case you can use just Ext.getStore('store's_name_bound_to_myGP').load();
    Personally I tend to avoid Ext.getStore too for the same reasons as Ext.getCmp. It isn't quite as bad as getCmp but sharing stores can lead to erratic results if you aren't very careful. If a store is only loaded once and the filters/sorting don't change then sharing it is sometimes ok: it's much better than repeatedly loading exactly the same data from the server.

    The MVC encourages this kind of singleton nonsense. Both the stores and refs properties are guilty in my opinion. They work for small apps but as soon as you scale up they effectively equate to getStore and getCmp.

    Quote Originally Posted by vadimv View Post
    3. Store/link the reference of first window in a property of the second one.
    This is the key. Even using component queries and controllers you've got to establish the links between the components.

    The simplest way is just:

    Code:
    win1.myOtherWindow = Ext.widget('w_p_adm_addcntr')
    This isn't CQable but it does allow you to get from one window to the other. Of course this only makes sense if you don't want to load the data immediately, in which case you can just do:

    Code:
    var win = Ext.widget('w_p_adm_addcntr');
    
    win.fn_load(1, 1, '-');
    
    win.showAt(0, 0);
    or even:

    Code:
    Ext.widget('w_p_adm_addcntr', {
        myData: [1, 1, '-'] // The window should contain code to load this
    }).showAt(0, 0);
    Another alternative is to add the window to a suitable container. That has other ramifications but it is CQable. It may not be applicable for a modal window but for something like a window within a tab it works nicely, allowing the window to be accessed easily by CQ from elsewhere in the tab.

    Establishing relationships between components starts with figuring out what the relationships should be. Whose window is it? You can then build up from there.

    If you absolutely have to create a singleton component (and even if you think you do, you probably don't) then follow the golden rule for writing hacky code: encapsulate the hack in one place behind a decent API.

    So, for the sake of argument, imagine an application with a navigational tree on the left and tabs on the right. Occasionally one of the tabs wants to activate another tab by selecting a node in the tree. Rather than grabbing the tree directly and doing all kinds of mischief, instead you can create a singleton class for handling navigation:

    Code:
    Ext.define('MyApp.NavigationManager', {
        singleton: true,
    
        jumpTo: function(config) {
            ...
        }
    });
    Then:

    Code:
    MyApp.NavigationManager.jumpTo(...);
    Inside jumpTo you can then grab the tree by whatever horrid means you like (preferably CQ). Any other requirements for grabbing the tree from the ether should go through this same access point, keeping the nastiness isolated. If appropriate you could make this class a controller and use refs to grab the tree.

    However, I cannot stress enough how rare it is to need to treat components like this. It might happen once or twice in a large application, for things like a fixed header or a main navigational section.