I see there are lot\'s of examples in Ext JS where instead of actually creating Ext JS objects, an object literal with an xtype
property is passed in.
What
I asked the same question as Joe, but I found the answer. If you use xtype
, one approach is to also specify an itemId
in the same object:
{ itemId: 'myObject', xtype: 'myClass' ... }
Then you can find it with getComponent()
as in
this.getComponent('myObject');
xtype
is a shorthand way to identify particular components: panel
= Ext.Panel
, textfield
= Ext.form.TextField
, etc. When you create a page or a form, you may use these xtypes
rather than instantiate objects. For example,
items: [{
xtype: 'textfield',
autoWidth: true,
fieldLabel: 'something'
}]
Moreover, creating pages in this manner allows Ext JS to render lazily the page. This is where you see a "performance gain." Instead of creating a large number of components when the app loads, Ext JS renders components when the user needs to see them. Not a big deal if you have one page, but if you exploit tabs or an accordion, many pages are initially hidden and therefore the app will load more quickly.
Furthermore, you may create and register new components creating xtypes of your choosing. Ext JS will similarly render your components lazily.
You may also retrieve components by ID. Since your component (as well as the Ext JS components) may provide a bunch of nice behavior, it is sometimes convenient to search for and retrieve a component rather than a simple DOM element or node.
In short, xtypes identify components and components are a key aspect of Ext JS.
If you declare a class and give it an xtype, you can query it later with Ext.ComponentQuery.query()
For example:
Ext.create('MyApp.view.MyButton', {
xtype: 'mybutton',
.....
});
Later in your code, if you do:
var buttonArray = Ext.ComponentQuery.query('mybutton');
then buttonArray
will contain an array of components of that class type. If you create components inline, your component query will be more complex.
Another advantage of xtypes is that if you move your classes around (let's say, you add another subdirectory under "view": MyApp.view.button.MyButton
), then your component queries can still remain the same, since your xtype doesn't change. Once your project gets large, you will start creating subdirectories and moving classes around.
An xtype
is simply a name given to represent a class. It is a
definition object which don't need to be instantiated when used in
any part of application.
While registering a xtype
, we simply use this syntax: Ext.reg(<xtype name>,<classname>)
. But, we don't use the new
keyword with the class name because the Component Mgr will automatically create instance of this class only if needed eg. in response to an event like click.
We don't need to get an instance manually because after registering an xtype
, the 'Component Mgr' will automatically create an instance for the class represtented by that xtype
only if it is used anywhere in the application or it simply don't instantiate that class if not used elsewhere. Component Mgr runs this code:
create : function(config, defaultType){
return new types[config.xtype || defaultType](config);
}
xtype
don't instantiate the class when Ext.Ready
runs. But, new Ext.Container()
will create all instances when Ext.Ready
runs. So, using xtype
is intelligent for large applications to get rid of garbage objects.
I'm new to Sencha/Ext JS but I think at this point the odd notion of having a shorthand definition identifier string for only UI components must be to satisfy legacy users.
Look at the "List of xtypes" here: http://docs.sencha.com/touch/2-0/#!/guide/components
Is there any good reason to use a similar-but-not-quite-the-same string identifier as the "class" name as the shorthand definition identifier? I don't think so.
Check the following sample of some xtype to class name mappings for Sencha touch:
video
- Ext.Video carousel
- Ext.carousel.Carousel carouselindicator
- Ext.carousel.Indicator navigationview
- Ext.navigation.View datepicker
- Ext.picker.Date Some of the arguments above for xtype were that it allowed deferred instantiation of components. I think that is completely irrelevant - what allows deferred instantiation is the fact that Sencha/Ext JS supports the specification of a string identifier in place of an instantiated component in a view hierarchy.
The mapping of a particular string to a particular component that might be instantiated later is completely arbitrary - and in the case of Sencha/Ext JS, unfortunately silly (see examples above).
At least just follow a sensible pattern - for example why couldn't a Ext.Label have an "xtype" of Label
? Too simple?
In reality I know why - it's because they made xtype names that read well - there are many repeated class names that wouldn't work (Ext.Panel and Ext.tab.Panel), and pickerDate
would just sound stupid.
But I still don't like it - it's an odd little inconsistent shortcut that obfuscates more than it helps.