PDA

View Full Version : Clarify : getCmp vs Up/down



EAHC-IT
6 Mar 2013, 1:46 AM
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 !== '***') {...}

vadimv
6 Mar 2013, 5:05 AM
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

EAHC-IT
7 Mar 2013, 1:26 AM
- 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...)

skirtle
7 Mar 2013, 4:40 AM
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.

EAHC-IT
7 Mar 2013, 5:22 AM
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();

vadimv
7 Mar 2013, 5:55 AM
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.

EAHC-IT
7 Mar 2013, 6:33 AM
Thanks vadimv and skirtle

EAHC-IT
7 Mar 2013, 6:40 AM
Well those two informations are leading to a better understanding (at least for me)

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.


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.

EAHC-IT
8 Mar 2013, 12:59 AM
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


Ext.widget('w_p_adm_addcntr').showAt(0,0);

- A button, that launch the window but with data, from update entry.


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,'-')

skirtle
8 Mar 2013, 4:28 AM
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.


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:


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:


var win = Ext.widget('w_p_adm_addcntr');

win.fn_load(1, 1, '-');

win.showAt(0, 0);

or even:


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:


Ext.define('MyApp.NavigationManager', {
singleton: true,

jumpTo: function(config) {
...
}
});

Then:


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.

EAHC-IT
8 Mar 2013, 5:12 AM
Thank you for all of this.

vadimv
8 Mar 2013, 6:34 AM
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.


Well, very true. Depends on the app, personally so far have had to deal with not shared stores. The one who asks on forum has to filter the suggestions according to his scenario.


Also regarding ComponentQuery, sometimes is good not to abuse of it too, or at least to try to write fast selectors, mostly in big applications where may be a lot of instantiated components at query time.

jemptymethod
8 Mar 2013, 12:57 PM
These are my two cents, or perhaps more appropriately, two words:

Event Bus

vadimv
9 Mar 2013, 8:32 AM
here you go : http://www.akawebdesign.com/2012/07/26/case-study-locating-extjs-components/ a nice post for you guys to understand better, in which I see the same opinion regarding slowness of CQ in big applicatioons.

devtig
10 Mar 2013, 11:44 PM
These are my two cents, or perhaps more appropriately, two words:

Event Bus

Your post is poetic and adds value to the discussion. If you would add a link to a nice tutorial then it would add actual value for newbies.

jemptymethod
28 May 2013, 6:05 AM
Your post is poetic and adds value to the discussion. If you would add a link to a nice tutorial then it would add actual value for newbies.

Yes of course I will get right to that, doing what Sencha should be doing all along.

Not.

jemptymethod
28 May 2013, 6:07 AM
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.


An "ImmutableStore" seems in order.