Studio Developer Manual / Version 2406.0
Table Of ContentsThings 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:
- xtype
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).- alias
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 useplugin.
<type-value>, GridColumns usegridcolumn.
<type-value>. Thetype
property used for that purpose before introducingalias
has been deprecated.- xclass
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!"}); label.setText(null); console.log(button.getText()); // logs the empty string (""), not "null"
Example 5.7. Ext JS Bindable Configs