ExtJS - learning how to write components
I want to open a small series of articles devoted to the problem of creating custom components in ExtJS. In them I want to share with Habr's readers my experience in this field, I will describe in detail all the subtleties of this process, to which one should always pay attention, what errors lie in the way of beginner programmers and how they can be avoided.
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 make 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 already been discussed and described many times, I will not paint them, but I will sketch schematically:
But behind the apparent simplicity hides a lot of nuances. First of all - how to choose a suitable grandparent? Novice developers use the following approach - they select the inherited component so that they write as little code as possible in the end, and only within the framework of familiar constructions. They are intimidated by onRender, creating elements, hanging event handlers. I will not conceal that in certain cases this approach is certainly correct and justifies its simplicity. There is a field with a button next to it - inherit Ext.form.TriggerField, it is necessary a field with a drop-down list - inherit Ext.from.Combobox, you need to embed a visual editor - inherit Ext.form.TextArea. But there are also quite “abnormal” situations in which the choice of the inherited component should be carried out carefully and deliberately.
')
Consider the following practical example. For the admin panel of a single site with a video gallery, I needed to create a control for entering the duration of the video. It had to contain three input fields (hours, minutes, seconds) in one line and contain 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 horribly ugly, and the getValue () method would constantly refer to the fields and recalculate the total duration (even if the values in the fields did not change). But this is still half the trouble. In the future, when it would be necessary to validate the form or use the methods of serialization / loading of forms (getValues / setValues, loadRecord / updateRecord), I would inevitably run into problems. The form would simply “forget” about the existence of the component as such, would not persistently recognize it as its field. As a result, I would have to write a bunch of “crutches”, copy-paste 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 should work as a form field and participate in the serialization and validation processes should be inherited exclusively from Ext.form.Field or any of its descendants.
To begin with, let's create a new component, inheriting Ext.form.Field:
Each form field by default renders its element. In the standard form component fields, this is either an input field or a checkbox. The entry field element is stored in the el property after rendering. It also automatically resizes when the container component is resized.
Since we have a component that contains three fields inside at once, we will create a div element in which our three fields and their labels will be wrapped as the default element. To change the tag and properties of the element by default, predetermine the property defaultAutoCreate:
Now you can create an internal structure ("frame") of our input field. Let's display 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. The entire custom render is placed in the onRender inherited method, after calling the parent method:
In order to “frame” the component is located as we need - in one line, we write and connect the following css table:
For ease of implementation, I took the size of the fixed fields - 50 pixels.
The "frame" component is ready. To complete the rendering procedure, it remains only to create and display field components. First, we find using Ext.query the DOM elements of their containers, and then we create instances of the components, telling them to render the corresponding 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 fuzzy constructions described by the pair of paragraphs above).
The visual part of the component is ready, it remains to complete the functional - getValue / setValue methods and validation / serialization support.
So that the getValue method does not recalculate the number of seconds each time, we proceed as follows:
Add methods to the component
and when creating input fields, set the onTimeFieldsChanged handler for all possible change events:
As you can see, when updating the value, we also retranslate 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 bug: an error when trying to call setValue if the component had 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, as well as we will 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 the render, 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 final component render (by installing a one-time event handler afterrender)
And to make the component “marketable” it remains only to take care of validation and serialization.
To implement the 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 in this.validationDelay (250 by default) ms, then only one call to the handler (for the last event of the series) will occur. This is a standard approach to monitoring validation events; it is used in all components.
To make the component serialize normally, you have to go for tricks. At the moment, loading of values into it will be performed normally, and get / setValue methods will work without problems. But during serialization, it will give three values instead of a single value with a count of seconds. This is because, based on compatibility with standard submit, forms are not serialized by calling the getValue methods, but by selecting the form (<input, <textarea, etc.) from the rendered HTML code of the elements and reading to their value properties. Therefore, we will have to create and update the hidden field for any changes in the component value. The same approach, by the way, is used in the implementation of Ext.form.Combobox
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 to you at first glance. The component we created fit in just 99 lines of code.
You can download the archive with an example from the link ( an alternative link without the ExtJS distribution), 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 make 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 already been discussed and described many times, I will not paint them, but I will sketch schematically:
- –-> Ext.extend –-> xtype Ext.regBut behind the apparent simplicity hides a lot of nuances. First of all - how to choose a suitable grandparent? Novice developers use the following approach - they select the inherited component so that they write as little code as possible in the end, and only within the framework of familiar constructions. They are intimidated by onRender, creating elements, hanging event handlers. I will not conceal that in certain cases this approach is certainly correct and justifies its simplicity. There is a field with a button next to it - inherit Ext.form.TriggerField, it is necessary a field with a drop-down list - inherit Ext.from.Combobox, you need to embed a visual editor - inherit Ext.form.TextArea. But there are also quite “abnormal” situations in which the choice of the inherited component should be carried out carefully and deliberately.
')
Consider the following practical example. For the admin panel of a single site with a video gallery, I needed to create a control for entering the duration of the video. It had to contain three input fields (hours, minutes, seconds) in one line and contain 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 three fields in it 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 horribly ugly, and the getValue () method would constantly refer to the fields and recalculate the total duration (even if the values in the fields did not change). But this is still half the trouble. In the future, when it would be necessary to validate the form or use the methods of serialization / loading of forms (getValues / setValues, loadRecord / updateRecord), I would inevitably run into problems. The form would simply “forget” about the existence of the component as such, would not persistently recognize it as its field. As a result, I would have to write a bunch of “crutches”, copy-paste 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 should work as a form field and participate in the serialization and validation processes should be inherited exclusively from Ext.form.Field or any of its descendants.
To begin with, let's create a new component, inheriting Ext.form.Field:
* This source code was highlighted with Source Code Highlighter .
- Ext.ux.TimeField = Ext.extend (Ext.form.Field, {
- });
- Ext.reg ( 'admintimefield' , Ext.Admin.TimeField);
Each form field by default renders its element. In the standard form component fields, this is either an input field or a checkbox. The entry field element is stored in the el property after rendering. It also automatically resizes when the container component is resized.
Since we have a component that contains three fields inside at once, we will create a div element in which our three fields and their labels will be wrapped as the default element. To change the tag and properties of the element by default, predetermine the property defaultAutoCreate:
* This source code was highlighted with Source Code Highlighter .
- Ext.ux.TimeField = Ext.extend (Ext.form.Field, {
- defaultAutoCreate: {tag: 'div' , 'class' : 'time-field-wrap' },
- .................................................. ...............
Now you can create an internal structure ("frame") of our input field. Let's display 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. The entire custom render is placed in the onRender inherited method, after calling the parent method:
* This source code was highlighted with Source Code Highlighter .
- Ext.Admin.TimeField = Ext.extend (Ext.form.Field, {
- timeFieldTpl: new Ext.XTemplate (
- '<div class = "hours-ct"> </ div> <div class = "timeunittext-ct"> h </ div>' ,
- '<div class = "minutes-ct"> </ div> <div class = "timeunittext-ct"> m </ div>' ,
- '<div class = "seconds-ct"> </ div> <div class = "timeunittext-ct"> with </ div>'
- ),
- .................................................. ...............
- onRender: function (ct, position) {
- Ext.Admin.TimeField.superclass.onRender.call ( this , ct, position);
- this .el.update ( this .timeFieldTpl.apply ( this ));
- .................................................. ...............
In order to “frame” the component is located as we need - in one line, we write and connect the following css table:
* This source code was highlighted with Source Code Highlighter .
- 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;
- }
For ease of implementation, I took the size of the fixed fields - 50 pixels.
The "frame" component is ready. To complete the rendering procedure, it remains only to create and display field components. First, we find using Ext.query the DOM elements of their containers, and then we create instances of the components, telling them to render the corresponding containers:
* This source code was highlighted with Source Code Highlighter .
- 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 );
- .................................................. ...............
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 fuzzy constructions described by the pair of paragraphs above).
The visual part of the component is ready, it remains to complete the functional - getValue / setValue methods and validation / serialization support.
So that the getValue method does not recalculate the number of seconds each time, we proceed as follows:
- number of 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 give the value of the value property
Add methods to the component
* This source code was highlighted with Source Code Highlighter .
- .................................................. ...............
- 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);
- },
- .................................................. ...............
and when creating input fields, set the onTimeFieldsChanged handler for all possible change events:
* This source code was highlighted with Source Code Highlighter .
- .................................................. ...............
- 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
- }
- .................................................. ...............
As you can see, when updating the value, we also retranslate 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 bug: an error when trying to call setValue if the component had 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, as well as we will additionally initialize the value to zero if it was not specified during creation:
* This source code was highlighted with Source Code Highlighter .
- .................................................. ...............
- 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 });
- }
- },
- .................................................. ............... <
As you can see, when you try to set the value of the component before the render, 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 final component render (by installing a one-time event handler afterrender)
And to make the component “marketable” it remains only to take care of validation and serialization.
To implement the validation, we will go the standard way Ext.from.Field, namely:
- specify the event at which the field will be revalidovatsya (change)
- set monitoring of validation for the event we need in initEvents
- preset validateValue method
- make changes to CSS
* This source code was highlighted with Source Code Highlighter .
- ................................................
- 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;
- }
When monitoring an event, buffering is applied. If we change the value faster than in this.validationDelay (250 by default) ms, then only one call to the handler (for the last event of the series) will occur. This is a standard approach to monitoring validation events; it is used in all components.
To make the component serialize normally, you have to go for tricks. At the moment, loading of values into it will be performed normally, and get / setValue methods will work without problems. But during serialization, it will give three values instead of a single value with a count of seconds. This is because, based on compatibility with standard submit, forms are not serialized by calling the getValue methods, but by selecting the form (<input, <textarea, etc.) from the rendered HTML code of the elements and reading to their value properties. Therefore, we will have to create and update the hidden field for any changes in the component value. The same approach, by the way, is used in the implementation of Ext.form.Combobox
* This source code was highlighted with Source Code Highlighter .
- 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);
- }
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 to you at first glance. The component we created fit in just 99 lines of code.
You can download the archive with an example from the link ( an alternative link without the ExtJS distribution), and see the demo here .
Source: https://habr.com/ru/post/88261/
All Articles