Module Ext_container_Container


module Ext_container_Container: sig .. end
Base class for any Ext.Component that may contain ...

Base class for any Ext.Component that may contain other Components. Containers handle the basic behavior of containing items, namely adding, inserting and removing items.

The most commonly used Container classes are Ext.panel.Panel, Ext.window.Window and Ext.tab.Panel. If you do not need the capabilities offered by the aforementioned classes you can create a lightweight Container to be encapsulated by an HTML element to your specifications by using the autoEl config option.

The code below illustrates how to explicitly create a Container:

// Explicitly create a Container
Ext.create('Ext.container.Container', {
    layout: {
        type: 'hbox'
    },
    width: 400,
    renderTo: Ext.getBody(),
    border: 1,
    style: {borderColor:'#000000', borderStyle:'solid', borderWidth:'1px'},
    defaults: {
        labelWidth: 80,
        // implicitly create Container by specifying xtype
        xtype: 'datefield',
        flex: 1,
        style: {
            padding: '10px'
        }
    },
    items: [{
        xtype: 'datefield',
        name: 'startDate',
        fieldLabel: 'Start date'
    },{
        xtype: 'datefield',
        name: 'endDate',
        fieldLabel: 'End date'
    }]
});

Layout

Container classes delegate the rendering of child Components to a layout manager class which must be configured into the Container using the layout configuration property.

When either specifying child items of a Container, or dynamically adding Components to a Container, remember to consider how you wish the Container to arrange those child elements, and whether those child elements need to be sized using one of Ext's built-in layout schemes. By default, Containers use the Auto scheme which only renders child components, appending them one after the other inside the Container, and does not apply any sizing at all.

A common mistake is when a developer neglects to specify a layout (e.g. widgets like GridPanels or TreePanels are added to Containers for which no layout has been specified). If a Container is left to use the default Auto scheme, none of its child components will be resized, or changed in any way when the Container is resized.

Certain layout managers allow dynamic addition of child components. Those that do include Ext.layout.container.Card, Ext.layout.container.Anchor, Ext.layout.container.VBox, Ext.layout.container.HBox, and Ext.layout.container.Table. For example:

//  Create the GridPanel.
var myNewGrid = Ext.create('Ext.grid.Panel', {
    store: myStore,
    headers: myHeaders,
    title: 'Results', // the title becomes the title of the tab
});

myTabPanel.add(myNewGrid); // Ext.tab.Panel implicitly uses Card
myTabPanel.setActiveTab(myNewGrid);

The example above adds a newly created GridPanel to a TabPanel. Note that a TabPanel uses Ext.layout.container.Card as its layout manager which means all its child items are sized to fit exactly into its client area.

Overnesting is a common problem. An example of overnesting occurs when a GridPanel is added to a TabPanel by wrapping the GridPanel inside a wrapping Panel (that has no layout specified) and then add that wrapping Panel to the TabPanel. The point to realize is that a GridPanel is a Component which can be added directly to a Container. If the wrapping Panel has no layout configuration, then the overnested GridPanel will not be sized as expected.

Adding via remote configuration

A server side script can be used to add Components which are generated dynamically on the server. An example of adding a GridPanel to a TabPanel where the GridPanel is generated by the server based on certain parameters:

// execute an Ajax request to invoke server side script:
Ext.Ajax.request({
    url: 'gen-invoice-grid.php',
    // send additional parameters to instruct server script
    params: {
        startDate: Ext.getCmp('start-date').getValue(),
        endDate: Ext.getCmp('end-date').getValue()
    },
    // process the response object to add it to the TabPanel:
    success: function(xhr) {
        var newComponent = eval(xhr.responseText); // see discussion below
        myTabPanel.add(newComponent); // add the component to the TabPanel
        myTabPanel.setActiveTab(newComponent);
    },
    failure: function() {
        Ext.Msg.alert("Grid create failed", "Server communication failure");
    }
});

The server script needs to return a JSON representation of a configuration object, which, when decoded will return a config object with an xtype. The server might return the following JSON:

{
    "xtype": 'grid',
    "title": 'Invoice Report',
    "store": {
        "model": 'Invoice',
        "proxy": {
            "type": 'ajax',
            "url": 'get-invoice-data.php',
            "reader": {
                "type": 'json'
                "record": 'transaction',
                "idProperty": 'id',
                "totalRecords": 'total'
            })
        },
        "autoLoad": {
            "params": {
                "startDate": '01/01/2008',
                "endDate": '01/31/2008'
            }
        }
    },
    "headers": [
        {"header": "Customer", "width": 250, "dataIndex": 'customer', "sortable": true},
        {"header": "Invoice Number", "width": 120, "dataIndex": 'invNo', "sortable": true},
        {"header": "Invoice Date", "width": 100, "dataIndex": 'date', "renderer": Ext.util.Format.dateRenderer('M d, y'), "sortable": true},
        {"header": "Value", "width": 120, "dataIndex": 'value', "renderer": 'usMoney', "sortable": true}
    ]
}

When the above code fragment is passed through the eval function in the success handler of the Ajax request, the result will be a config object which, when added to a Container, will cause instantiation of a GridPanel. Be sure that the Container is configured with a layout which sizes and positions the child items to your requirements.

Note: since the code above is generated by a server script, the autoLoad params for the Store, the user's preferred date format, the metadata to allow generation of the Model layout, and the ColumnModel can all be generated into the code since these are all known on the server.



class type t = object .. end
class type configs = object .. end
class type events = object .. end
class type statics = object .. end
val of_configs : configs Js.t -> t Js.t
of_configs c casts a config object c to an instance of class t
val to_configs : t Js.t -> configs Js.t
to_configs o casts instance o of class t to a config object