GeoExt 2 - more technical details

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.