ExtJS - learn to write components correctly
I want to open a short series of articles devoted to the problem of creating custom components in ExtJS. In them I want to share my experience in this field with Habr readers, I will describe in detail all the subtleties of this process, what you should always pay attention to, what mistakes await novice programmers and how to avoid them.
Sooner or later, the time comes when the standard ExtJS components cannot meet the needs of the developer. Or, in the process of refactoring an application, it becomes necessary to move a part of the interface (several components, form, table, tab) into a separate component. In both cases, you have to resort to creating custom components.
The basics of this process have been discussed and described many times, I will not paint them, but I will depict them schematically:
But behind the apparent simplicity hides many nuances. First of all, how to choose a suitable ancestor? Novice developers use the following approach - they select the inherited component so that as a result they write as little code as possible, and only within the framework of the constructions they know. They are frightened by onRender, creating elements, hanging event handlers. I will not admit, in certain cases, this approach is certainly correct and justifies its simplicity. You need a field with a button next to it - inherit Ext.form.TriggerField, you need a field with a drop-down list - inherit Ext.from.Combobox, you need to build in a visual editor - inherit Ext.form.TextArea. But there are also quite “contingency” situations in which the choice of the inherited component must be performed carefully and deliberately.
Consider the following practical example. For the admin panel of one site with a video gallery, I needed to create a control to enter the duration of the clip. It should contain three input fields (hours, minutes, seconds) in one line and contain a single input / output (setValue / getValue methods), which would operate with a duration in seconds.
A year and a half ago, when I was still a beginner ExtJS developer, I would solve this problem like this:
Yes, the component would work, give / set values. True, his code would be terribly ugly, and the getValue () method would constantly access the fields and recount the total duration (even if the values in the fields did not change). But this is not so bad. In the future, when it would be necessary to validate the form or use the methods of serializing / loading forms (getValues / setValues, loadRecord / updateRecord), I would inevitably run into problems. The form would simply “forget” about the existence of the component as such, persistently would not recognize it as its field. As a result, I would have to write a bunch of “crutches”, copy-paste the code from Ext.form.Field to make the component work as a form field.
Therefore, at present I adhere to the following principle: any component that will have to work as a form field and participate in serialization and validation processes must be inherited exclusively from Ext.form.Field or any of its descendants.
First, create a new component, inheriting Ext.form.Field:
Each form field renders its own element by default. In standard form component fields, this is either an input field or a checkbox. The input field element is stored in the el property after rendering. It also automatically resizes when the component container is resized.
Since our component contains three fields inside, we will create as a default element a div into which our three fields and their labels will be “wrapped”. To change the tag and properties of an element by default, we define the defaultAutoCreate property:
Now you can create the internal structure (“frame”) of our input field. Put 6 divs in a row. Three of them will be containers for spinner controls (for entering hours of minutes and seconds), and the other three will contain corresponding labels. For clarity, we will create them not using Ext.DomHelper, but using the Ext.XTemplate template engine. All user renderer is placed in the inherited onRender method, after calling the parent method:
So that the "frame" of the component is located as we need it - in one line, write and connect the following css table:
For ease of implementation, I took the size of the fields fixed - 50 pixels.
The wireframe of the component is ready. To complete the rendering procedure, it remains only to create and display the field components. First, using Ext.query, we find the DOM elements of their containers, and then create instances of the components, telling them to render to the appropriate containers:
Note that the components themselves, after rendering, are stored in the properties of this.xxxField, which allows us to easily and conveniently access them (instead of the furious constructions described in a couple of paragraphs above).
The visual part of the component is ready, it remains to complete the functional - getValue / setValue methods and support for validation / serialization.
So that the getValue method does not recount the number of seconds each time, proceed as follows:
Add methods to the component
and when creating input fields, set onTimeFieldsChanged by the handler of all possible change events:
As you can see, when updating the value, we also relay the change event received from the input fields. This is still useful for us to support validation.
To set the value, write the setValue method. I used to work with many custom components from third-party developers and in the implementation of most of them I had to fix the same glitch: an error while trying to call setValue if the component has not yet rendered. The developers simply forgot to check this and immediately turned to the this.el property (which has not yet been created). In our component, we will take this into account, and we will also additionally initialize the value to zero if it was not specified during creation:
As you can see, when you try to set the value of the component before rendering, it will only be saved in the this.value property, and the actual substitution of the necessary values in the input fields will be delayed until the component is finally rendered (by installing a one-time afterrender event handler)
And to give the component a "presentation" all that remains is to take care of validation and serialization.
To implement validation, we will go the standard way Ext.from.Field, namely:
When monitoring an event, buffering is applied. If we change the value faster than this.validationDelay (default is 250) ms, then only one call to the handler (for the last event in the series) will occur. This is a standard approach to monitoring validation events; it is used in all components.
To make the component normally serialize, you have to go to tricks. At the moment, loading values into it will be normal, the get / setValue methods will work without problems. But during serialization, it will give instead of a single value with the number of seconds three values at once. This is because, in order to be compatible with the standard submit, forms are not serialized by accessing getValue methods, but by selecting form elements from the rendered HTML code (
That's all. As you can see, creating even non-standard components by inheriting Ext.form.Field is not as difficult as it might seem at first glance. The component we created fit in just 99 lines of code.
You can download the example archive using the link ( alternative link without ExtJS distribution kit), and see the demo here .
Sooner or later, the time comes when the standard ExtJS components cannot meet the needs of the developer. Or, in the process of refactoring an application, it becomes necessary to move a part of the interface (several components, form, table, tab) into a separate component. In both cases, you have to resort to creating custom components.
The basics of this process have been discussed and described many times, I will not paint them, but I will depict them schematically:
ищем подходящий компонент-прародитель –-> наследуем его при помощи Ext.extend –-> регистрируем xtype при помощи Ext.reg
But behind the apparent simplicity hides many nuances. First of all, how to choose a suitable ancestor? Novice developers use the following approach - they select the inherited component so that as a result they write as little code as possible, and only within the framework of the constructions they know. They are frightened by onRender, creating elements, hanging event handlers. I will not admit, in certain cases, this approach is certainly correct and justifies its simplicity. You need a field with a button next to it - inherit Ext.form.TriggerField, you need a field with a drop-down list - inherit Ext.from.Combobox, you need to build in a visual editor - inherit Ext.form.TextArea. But there are also quite “contingency” situations in which the choice of the inherited component must be performed carefully and deliberately.
Consider the following practical example. For the admin panel of one site with a video gallery, I needed to create a control to enter the duration of the clip. It should contain three input fields (hours, minutes, seconds) in one line and contain a single input / output (setValue / getValue methods), which would operate with a duration in seconds.
A year and a half ago, when I was still a beginner ExtJS developer, I would solve this problem like this:
- would inherit a component from Ext.Panel
- using ColumnLayout would display in it three fields in three columns
- would write getValue / setValue methods, accessing fields through furious constructions like this.items.items [0] .items.items [0] .getValue () ...
Yes, the component would work, give / set values. True, his code would be terribly ugly, and the getValue () method would constantly access the fields and recount the total duration (even if the values in the fields did not change). But this is not so bad. In the future, when it would be necessary to validate the form or use the methods of serializing / loading forms (getValues / setValues, loadRecord / updateRecord), I would inevitably run into problems. The form would simply “forget” about the existence of the component as such, persistently would not recognize it as its field. As a result, I would have to write a bunch of “crutches”, copy-paste the code from Ext.form.Field to make the component work as a form field.
Therefore, at present I adhere to the following principle: any component that will have to work as a form field and participate in serialization and validation processes must be inherited exclusively from Ext.form.Field or any of its descendants.
First, create a new component, inheriting Ext.form.Field:
- Ext.ux.TimeField = Ext.extend(Ext.form.Field, {
-
-
- });
-
- Ext.reg('admintimefield', Ext.Admin.TimeField);
* This source code was highlighted with Source Code Highlighter.
Each form field renders its own element by default. In standard form component fields, this is either an input field or a checkbox. The input field element is stored in the el property after rendering. It also automatically resizes when the component container is resized.
Since our component contains three fields inside, we will create as a default element a div into which our three fields and their labels will be “wrapped”. To change the tag and properties of an element by default, we define the defaultAutoCreate property:
- Ext.ux.TimeField = Ext.extend(Ext.form.Field, {
-
- defaultAutoCreate : {tag: 'div', 'class' : 'time-field-wrap'},
-
- .................................................................
* This source code was highlighted with Source Code Highlighter.
Now you can create the internal structure (“frame”) of our input field. Put 6 divs in a row. Three of them will be containers for spinner controls (for entering hours of minutes and seconds), and the other three will contain corresponding labels. For clarity, we will create them not using Ext.DomHelper, but using the Ext.XTemplate template engine. All user renderer is placed in the inherited onRender method, after calling the parent method:
- Ext.Admin.TimeField = Ext.extend(Ext.form.Field, {
- timeFieldTpl : new Ext.XTemplate(
- 'ч',
- 'м',
- 'с'
- ),
- .................................................................
-
- onRender : function(ct, position){
- Ext.Admin.TimeField.superclass.onRender.call(this, ct, position);
- this.el.update(this.timeFieldTpl.apply(this));
-
- .................................................................
* This source code was highlighted with Source Code Highlighter.
So that the "frame" of the component is located as we need it - in one line, write and connect the following css table:
- div.hours-ct,
- div.minutes-ct,
- div.seconds-ct,
- div.timeunittext-ct {
- display: inline-block;
- width: 10px;
- }
-
- div.hours-ct,
- div.minutes-ct,
- div.seconds-ct {
- width: 50px;
- }
* This source code was highlighted with Source Code Highlighter.
For ease of implementation, I took the size of the fields fixed - 50 pixels.
The wireframe of the component is ready. To complete the rendering procedure, it remains only to create and display the field components. First, using Ext.query, we find the DOM elements of their containers, and then create instances of the components, telling them to render to the appropriate containers:
- onRender : function(ct, position){
- Ext.Admin.TimeField.superclass.onRender.call(this, ct, position);
- this.el.update(this.timeFieldTpl.apply(this));
- Ext.each(['hours', 'minutes', 'seconds'], function (i) {
- this[i+'Ct'] = Ext.query('.' + i + '-ct', this.el.dom)[0];
- this[i+'Field'] = Ext.create({
- xtype: 'spinnerfield',
- minValue: 0,
- maxValue: i=='hours' ? 23 : 59,
- renderTo : this[i+'Ct'],
- width: 45,
- value: 0
- });
- }, this);
- .................................................................
* This source code was highlighted with Source Code Highlighter.
Note that the components themselves, after rendering, are stored in the properties of this.xxxField, which allows us to easily and conveniently access them (instead of the furious constructions described in a couple of paragraphs above).
The visual part of the component is ready, it remains to complete the functional - getValue / setValue methods and support for validation / serialization.
So that the getValue method does not recount the number of seconds each time, proceed as follows:
- seconds will be stored in the value property
- this property will be recalculated and updated if and only if we change the values in the input fields
- the getValue method will simply return the value of the value property
Add methods to the component
- .................................................................
- getValue : function(){
- return this.value;
- },
- getRawValue : function () {
- return this.value;
- },
- onTimeFieldsChanged : function () {
- this.value = this.hoursField.getValue() * 3600 + this.minutesField.getValue() * 60 + this.secondsField.getValue();
- this.fireEvent('change', this, this.value);
- },
- .................................................................
* This source code was highlighted with Source Code Highlighter.
and when creating input fields, set onTimeFieldsChanged by the handler of all possible change events:
- .................................................................
- this[i+'Field'] = Ext.create({
- xtype: 'spinnerfield',
- minValue: 0,
- maxValue: i=='hours' ? 23 : 59,
- renderTo : this[i+'Ct'],
- width: 45,
- value: 0,
- enableKeyEvents: true,
- listeners : {
- keyup: this.onTimeFieldsChanged,
- spinup: this.onTimeFieldsChanged,
- spindown: this.onTimeFieldsChanged,
- scope: this
- }
-
- .................................................................
* This source code was highlighted with Source Code Highlighter.
As you can see, when updating the value, we also relay the change event received from the input fields. This is still useful for us to support validation.
To set the value, write the setValue method. I used to work with many custom components from third-party developers and in the implementation of most of them I had to fix the same glitch: an error while trying to call setValue if the component has not yet rendered. The developers simply forgot to check this and immediately turned to the this.el property (which has not yet been created). In our component, we will take this into account, and we will also additionally initialize the value to zero if it was not specified during creation:
- .................................................................
- initComponent: function () {
- if (!Ext.isDefined(this.value)) this.value = 0;
- Ext.Admin.TimeField.superclass.initComponent.call(this);
- },
-
- setValue : function (v) {
- var setFn = function (v) {
- var h = Math.floor(v / 3600),
- m = Math.floor((v % 3600) / 60),
- s = v % 60;
- this.hoursField.setValue(h);
- this.minutesField.setValue(m);
- this.secondsField.setValue(s);
- };
- this.value = v;
- if (this.rendered) {
- setFn.call(this, v);
- } else {
- this.on('afterrender', setFn.createDelegate(this, [v]), {single:true});
- }
- },
- .................................................................<
* This source code was highlighted with Source Code Highlighter.
As you can see, when you try to set the value of the component before rendering, it will only be saved in the this.value property, and the actual substitution of the necessary values in the input fields will be delayed until the component is finally rendered (by installing a one-time afterrender event handler)
And to give the component a "presentation" all that remains is to take care of validation and serialization.
To implement validation, we will go the standard way Ext.from.Field, namely:
- indicate the event at which the field will be revalidated (change)
- set up validation monitoring for the desired event in initEvents
- override validateValue method
- make changes to CSS
- ................................................
- validationEvent : 'change',
- ................................................
- initEvents : function () {
- Ext.ux.TimeField.superclass.initEvents.call(this);
- if (this.validationEvent !== false && this.validationEvent != 'blur'){
- this.mon(this, this.validationEvent, this.validate, this, {buffer: this.validationDelay});
- }
- },
- ................................................
- validateValue : function(value) {
- if (this.allowBlank !== false) {
- return true;
- } else {
- if (Ext.isDefined(value) && value != '' && value != '0' && value > 0) {
- this.clearInvalid();
- return true;
- } else {
- this.markInvalid(this.blankText);
- return false;
- }
- }
- },
* This source code was highlighted with Source Code Highlighter.
- .time-field-wrap.x-form-invalid {
- background: none;
- border: 0px none;
- }
-
- .time-field-wrap.x-form-invalid .x-form-text {
- background-color:#FFFFFF;
- background-image:url(../../resources/images/default/grid/invalid_line.gif);
- background-position: left bottom;
- border-color:#CC3300;
- }
* This source code was highlighted with Source Code Highlighter.
When monitoring an event, buffering is applied. If we change the value faster than this.validationDelay (default is 250) ms, then only one call to the handler (for the last event in the series) will occur. This is a standard approach to monitoring validation events; it is used in all components.
To make the component normally serialize, you have to go to tricks. At the moment, loading values into it will be normal, the get / setValue methods will work without problems. But during serialization, it will give instead of a single value with the number of seconds three values at once. This is because, in order to be compatible with the standard submit, forms are not serialized by accessing getValue methods, but by selecting form elements from the rendered HTML code (
- var setFn = function (v) {
- ................................................................
- this.hiddenField.value = v;
- };
- ....................................................
- onTimeFieldsChanged : function () {
- ..............................................................................
- this.hiddenField.value = this.value;
- this.fireEvent('change', this, this.value);
- },
-
- onRender : function(ct, position){
- Ext.ux.TimeField.superclass.onRender.call(this, ct, position);
- ............................................................................................................
- this.hiddenField = this.el.insertSibling({
- tag:'input',
- type:'hidden',
- name: this.name || this.id,
- id: (this.id+'hidden')
- }, 'before', true);
- if (this.value) this.setValue(this.value);
- }
* This source code was highlighted with Source Code Highlighter.
That's all. As you can see, creating even non-standard components by inheriting Ext.form.Field is not as difficult as it might seem at first glance. The component we created fit in just 99 lines of code.
You can download the example archive using the link ( alternative link without ExtJS distribution kit), and see the demo here .