loading table of contents...

Studio Developer Manual / Version 2310

Table Of Contents
Advanced Ext JS Config System

Things became more complicated with the new class and Config system introduced with Ext 4 (CoreMedia skipped Ext 4 and 5, but upgraded directly to Ext 6, later to 7).

The new Ext Config system supports additional indicators of which class to instantiate. The three different special Ext properties available to specify the target class are:


The "classic" class hint. Each Ext class may specify a unique xtype, which is registered and referenced here to identify the class to instantiate. This indirection is meant to separate usage and implementation (a bit).


When Ext extended their Config System to more than just components, they thought it would make sense to introduce prefixes for the different groups of classes. Components use widget.<xtype-value>, plugins use plugin.<type-value>, GridColumns use gridcolumn.<type-value>. The type property used for that purpose before introducing alias has been deprecated.


Introduced last, this is the most straightforward way to specify the target class: Just give its fully-qualified name! Unfortunately, this property does not work everywhere in Ext's Classic Toolkit (the one CoreMedia Studio uses), so if a class has an xtype / alias, you should better use that, or even better, all possible meta-properties the class offers.

Configs now can be declared explicitly for an Ext class and then trigger some magic: For every Config property foo, Ext generates methods getFoo() and setFoo(value). Such Configs are called bindable, because they can be bound to a model that would read and write their value through these methods.

Note that bindable Configs in Ext JS do not use ECMAScript accessors, but "normal" methods, as Ext 4 came out when browser support for accessors was not yet mainstream. Sencha never managed to update the Ext JS Config system to "real" accessors.

Only for sake of completeness, it should be mentioned that the generated setFoo(value) method looks for two optional "hook" methods that allow the following:

  • Transform the value before it is stored:

    updateFoo(value) { return transform(value) }
  • Trigger side-effects after the value has been set:

    applyFoo(value, oldValue) { /* side effect */ }

Since these hook methods do not add much value, but rather make code harder to read, we do not recommend using them. Rather, simply provide a custom implementation of setFoo(), calling super.setFoo() if and where needed.

As an example, here is how you could define a Config text, prevent anything that is not a string from being set into that Config (at least not when everybody uses the setText(value) method), and update the DOM of your component whenever the text is changed:

 Ext.define("acme.Label", {
  extend: "Ext.Component",
  xtype: "acme.label",
  config: {
    text: ""
  setText(value) {
    this.value = typeof value === "string" ? value : value ? String(value) : "";
    if (this.rendered) {
      // update my DOM node with 'this.value' ...

var label = Ext.create({ xtype: "acme.label", text: "Hi!"});
console.log(button.getText()); // logs the empty string (""), not "null"

Example 5.7.  Ext JS Bindable Configs

Search Results

Table Of Contents

Your Internet Explorer is no longer supported.

Please use Mozilla Firefox, Google Chrome, or Microsoft Edge.