This blog post provides more details on GeoExt 2 and Ext JS 4, focusing on technical aspects
So GeoExt 2 is a port of GeoExt 1 to Ext JS 4. The GeoExt 2 code sprint was really about porting the existing code base to Ext JS 4, redesigning, and rewriting code, only when simple adaptations were not possible.
GeoExt 2 works with Ext JS 4 only. Ext JS 3 and lower aren't supported, and won't be, obviously.
Note also that GeoExt 2 doesn't work with Sencha Touch. Sencha Touch and Ext JS 4 have similarities but their APIs are too different to write code that works with both libs. We actually did attempt to make map panel work with both Ext JS 4 and Sencha Touch, but failed.
The class system
The class system of Ext JS 4 is quite different from that of Ext JS 3. Ext JS 3 had no specific mechanism for defining classes, and had
Ext.extend to
define child classes. With Ext JS 4 classes are defined using
Ext.define. Defining a parent class is done as follows:
Ext.define('P', {
// prototype object
});
Defining a child class is done as follows:
Ext.define('C', {
extend: 'P',
// prototype object
});
In the above examples the
P and
C constructors are added to the
window namespace. To create a class without adding a reference to it in the global namespace
Ext.Class can be used.
Ext.define actually uses
Ext.Class internally, and most of the time you should not need to use
Ext.Class.
So porting GeoExt to Ext JS 4 has required using
Ext.define for every class definition – the easy part of the porting work really.
Another major change in Ext JS 4 is the way classes should be instantiated. Although using the
new keyword still works (thank god!) using
Ext.create is recommended. For example:
var c = Ext.create('C');
Using
Ext.create Ext JS will actually load the script containing the class if the class is not defined yet. This is called "synchronous loading" in the Ext JS 4 jargon, which means "load the class at the time it is actually needed".
The autoloader also supports "asynchronous loading". When relying on asynchronous loading, scripts are loaded earlier, in fact as soon as
Ext.require is called or when classes with specific requirements (defined with "requires" in the class) are defined. Synchronous loading works with XHR while asynchronous loading works by dynamically adding
script tags to the page.
The data components
The data types/components in Ext JS 4 work differently from Ext JS 3. Ext JS 4 has introduced the notion of “model”. A model, which is a class, defines a data schema. For example:
Ext.define('my.Model', {
extend: 'Ext.data.Model',
fields: [{
name: 'text', type: 'string'
}, {
name: 'code', type: 'int'
}]
});
This defines a data model with two fields/columns: "text" and "code". The defined model class can then be used in a store. For example:
var store = Ext.create('Ext.data.Store', {
model: 'my.Model'
});
GeoExt 2 defines its own data models. To name a few:
LayerModel,
WmsCapabilitiesLayerModel,
WmsDescribeLayerModel to name a few.
GeoExt 2 also defines preconfigured stores. For example GeoExt 2 includes
WmsDescribeLayerStore which is preconfigured with
WmsDescribeLayerModel.
As GeoExt 1, the goal of GeoExt 2's data components is to ease working with geo data and metadata in Ext JS applications. But we had to rethink and redesign things in GeoExt 2, to adapt to Ext JS 4's new architecture and concepts.
The tree components
(paragraph contributed by Andreas Hocevar)
Trees have seen a complete overhaul in Ext JS 4. Instead of loaders, every node in a tree now has a store for its child nodes. While the Ext JS 4 tree is more flexible than the Ext JS 3 one when it comes to columns (the tree is a grid), there are less extension points for customizations on the node level. And GeoExt 1 did a lot of customizations on the node level. But despite these difficulties, we were able to come up with a nice API for configuring trees. Let's have a look at a tree configuration for including a WMS
GetLegendGraphic image for each layer in GeoExt 1:
// custom layer node UI class
var LayerNodeUI = Ext.extend(
GeoExt.tree.LayerNodeUI,
new GeoExt.tree.TreeNodeUIEventMixin()
);
var tree = new Ext.tree.TreePanel({
// apply the tree node component plugin to layer nodes
plugins: [{
ptype: "gx_treenodecomponent"
}],
loader: {
applyLoader: false,
uiProviders: {
custom_ui: LayerNodeUI
}
},
root: {
nodeType: "gx_layercontainer",
loader: {
baseAttrs: {
uiProvider: "custom_ui"
},
createNode: function(attr) {
// add a WMS legend to each node created
attr.component = {
xtype: "gx_wmslegend",
layerRecord: mapPanel.layers.getByLayer(attr.layer),
showTitle: false,
// custom class for css positioning
// see tree-legend.html
cls: "legend"
};
return GeoExt.tree.LayerLoader.prototype.createNode.call
(this, attr);
}
}
},
rootVisible: false,
lines: false
});
Obviously the configuration of a custom
TreeNodeUI to get additional events on the tree, which are needed by the
gx_treenodecomponent plugin is a bit cumbersome. With GeoExt 2, the same tree can be achieved with a much nicer configuration:
var store = Ext.create('Ext.data.TreeStore', {
model: 'GeoExt.data.LayerTreeModel',
root: {
plugins: [{
ptype: "gx_layercontainer",
loader: {
createNode: function(attr) {
// add a WMS legend to each node created
attr.component = {
xtype: "gx_wmslegend",
layerRecord: mapPanel.layers.getByLayer(
attr.layer),
showTitle: false,
// custom class for css positioning
// see tree-legend.html
cls: "legend"
};
return GeoExt.tree.LayerLoader.prototype.createNode.call
(this, attr);
}
}
}]
}
});
var tree = new GeoExt.tree.Panel({
store: store,
rootVisible: false,
lines: false
});
The node (here: the root node) can be configured with plugins. Note that this is not an Ext JS 4 extension point, but one that we created in GeoExt 2. As long as your tree is a
GeoExt.tree.TreePanel instead of an
Ext.tree.TreePanel, and its store is configured with a
GeoExt.tree.LayerTreeModel instead of the default model, there are no special configuration options needed to make the already built-in component rendering available.
Instead of having this built into our default tree view (the one the
GeoExt.tree.TreePanel is configured with), we could also move it into a plugin before the final release.
This decision depends on how much code the other plugins (like the
ActionPlugin and
RadioButtonPlugin) require, and our architecture allows us to create an extension point here any time.
Posts
