This class (docs here) has actually been around for ...]]> In the past couple of months we’ve received a few requests for mocking capabilities when it comes to Ajax requests with Siesta. We are actually quite interested in this feature ourself so we we’re very happy when we realized how easy it was to accomplish. The solution: Ext.ux.ajax.SimManager, is found in the Ext JS examples/ux folder.

Introducing the Ext.ux.ajax.SimManager

This class (docs here) has actually been around for quite a while, and it is even well documented in the public Sencha docs though we didn’t really notice it until recently. Originally written by the Ext JS mastermind Don Griffin, this class provides very easy mocking support. The static SimManager class allows you to easily mount a simulated Ajax response referred to as a simlet, mapped to a given URL. To mount a dataset for a specific URL returning a basic JSON object, you call the init method as seen below:

Ext.ux.ajax.SimManager.init({
        delay : 300
    }).register(
        {
            '/app/data/url' : {
                stype : 'json',  // use JsonSimlet (stype is like xtype for components)
                data  : [
                    { id : 1, name : 'user1', age : 25 },
                    { id : 2, name : 'user2', age : 35 },
                    { id : 3, name : 'user3', age : 45 }
                ]
            }
        }
    );

We can specify the delay to use, and just pass in the data we’d like the mocked response to contain. Later in your test when your store (or plain Ajax call) requests the ‘/app/data/url’ URL, this will be handled automatically by the SimManager. To make use of the SimManager class in a Siesta test, simply configure the ‘loaderPath’ to be able to require it inside the test.

{
        url : '051_ext-ajax-mock.t.js',

        // Setup the path to the 'ux' folder on the Sencha CDN
        loaderPath  : { 'Ext.ux' : 'http://cdn.sencha.io/ext-4.2.0-gpl/examples/ux' }
    }

I just created a basic Siesta test (included in the next release) to the Ext JS examples folder of the Siesta SDK to prove how easy it is to get started. All we have to do is to ‘require’ the SimManager class first.

StartTest(function (t) {

    t.requireOk('Ext.ux.ajax.SimManager', function () {
        Ext.define('MyModel', {
            extend : 'Ext.data.Model',
            fields : [
                'id',
                'name',
                'age'
            ]
        });

        Ext.ux.ajax.SimManager.init({
            delay : 300
        }).register(
            {
                '/app/data/url' : {
                    stype : 'json',  // use JsonSimlet (stype is like xtype for components)
                    data  : [
                        { id : 1, name : 'user1', age : 25 },
                        { id : 2, name : 'user2', age : 35 },
                        { id : 3, name : 'user3', age : 45 }
                    ]
                }
            }
        );

        var store = new Ext.data.Store({
            model : 'MyModel',

            proxy : {
                type : 'ajax',
                url  : '/app/data/url' // doesn't exist
            }
        });

        t.willFireNTimes(store, 'load', 1);

        t.it('should be possible to load mock data', function (t) {
            t.loadStoresAndThen(store, function () {
                t.expect(store.first().get('id')).toBe(1);
                t.expect(store.first().get('name')).toBe('user1');
                t.expect(store.getAt(1).get('id')).toBe(2);
                t.expect(store.getAt(1).get('name')).toBe('user2');
                t.expect(store.getAt(2).get('id')).toBe(3);
                t.expect(store.getAt(2).get('name')).toBe('user3');
            });
        });
    });
});

You can simulate any number of URL’s and associate them with an Ext.ux.ajax.Simlet. To make non-simulated Ajax requests after the SimManager class is initialized, add a nosim : true option to your Ajax call config.

Summing up

Using mocked Ajax calls are a great way to simplify your testing and speed it up at the same time. We hope you will find this Ext JS feature useful in your test suite. Do you have any other mocking tips & tricks? Please let us know in the comments or our support forums.

Related links:

Ext.ux.ajax.SimManager docs

We’re proud to present the new UberGrid component – a grid with super powers for Sencha Touch! UberGrid aims to support as many grid features as possible while also providing excellent performance on a wide range of mobile devices.

The UberGrid is the latest member of our product family. It already serves as the base component for another of our products – the Touch ...]]>

We’re proud to present the new UberGrid component – a grid with super powers for Sencha Touch! UberGrid aims to support as many grid features as possible while also providing excellent performance on a wide range of mobile devices.

The UberGrid is the latest member of our product family. It already serves as the base component for another of our products – the Touch Scheduler. We decided that the two products would benefit from a clean separation of logic – the scheduler just uses the grid API and doesn’t need to worry about the underlying grid implementation. The grid on the other hand – will not “know” anything about scheduling, thus remaining an isolated and general-purpose grid.

The UberGrid is mainly targeted at tablet devices and ‘phablets’, since grids normally display a lot of information. There is of course nothing preventing you from using it on a supported smartphone though.

Features

For the initial 1.0 release, the UberGrid supports:

• Grouped column headers
  The columns in the UberGrid can have sub-columns and form groups. There is no limit on the number of nesting levels.

  

• Buffered rendering

  UberGrid supports a special rendering mode in which only the rows visible in the viewport are included in the DOM. In this mode, the UberGrid offers a flat performance for any number of rows in the data set. For small data sets, you can just use the default non-buffered rendering mode which provides the best possible scrolling experience. See the below DOM footprint for a grid with a viewport fitting 5 rows, while having 100s of records in its store.

  

• Unlimited number of locked sections

  The UberGrid can have several “locked” sections on the left or the right side of the main content area. In the image below, there is a scrollable section on both sides.

  

• Unit tested with Siesta

  Code stability is a feature. The UberGrid is covered with unit and functional tests and the test suite is included in the package. We run the test suite nightly and before every release. This makes sure we won’t accidentally break old features in new releases and any bugs found should only be reported once – as each bug introduces a new test case. You can count on the public (documented) API to remain stable in future releases.

  

• And there’s more…

  UberGrid also supports variable row height, column sorting, customizable data rendering, customizable header rendering and more. We’ll cover these features in a more technical blog post coming soon.

Getting started

The component provides an API which is very similar to the Ext JS grid panel. UberGrid is a subclass of the Ext.Container class and can participate in any Sencha Touch layout. To create a grid you simply instantiate the UberGrid.Panel class:

Ext.define('Meeting', {
    extend : 'Ext.data.Model',

    config : {
        fields : ['Id', 'Title', 'StartDate', 'Location']
    }
});

Ext.setup({
    onReady: function () {
        var grid = new UberGrid.Panel({
            margin              : 20,
            rowHeight           : 50,

            columns             : [
                {
                    header      : 'Id',
                    dataIndex   : 'Id',
                    width       : 60,
                    cellCls     : 'id'
                },
                {
                    header      : 'Name',
                    dataIndex   : 'Title',
                    flex        : 1
                },
                {
                    header      : 'Start Date',
                    dataIndex   : 'StartDate',
                    width       : 200
                },
                {
                    header      : 'Location',
                    dataIndex   : 'Location',
                    width       : 250
                }
            ],

            store : new Ext.data.Store({
                autoLoad    : true,
                model       : 'Meeting',
                proxy       : {
                    type    : 'ajax',
                    url     : 'data.js',
                    reader  : { type : 'json' }
                }
            })
        })

        Ext.Viewport.add(grid);
    }
});

This example should be pretty self-explanatory. The required configs are columns and store. To dive deeper into the details, please see the getting started guide in the docs.

Roadmap

This is only the initial 1.0.0 release. We’ll keep adding new features with every new version. Among the nearest ones will be grouping, data index, columns resizing and later tree support. If a particular feature is important for you, let us know and we’ll try our best to add it!

Ready to try it out?

Here are some resources to get you going:

• Download a trial here
• Live examples (needs a Webkit browser)
• API docs
• Getting started guide
• “Learn Sencha Touch” at sencha.com
• Additional Sencha Touch resources

You might have seen one of the sneak preview videos on YouTube about a collaborative demo app using our scheduler with Ext JS and Sencha Touch. With our recent release of the first 2.2 beta version of Ext Scheduler, it’s now time to look under the hood of this demo application. When we were about to release the Touch Scheduler, we thought we should really put it to the ...]]>

You might have seen one of the sneak preview videos on YouTube about a collaborative demo app using our scheduler with Ext JS and Sencha Touch. With our recent release of the first 2.2 beta version of Ext Scheduler, it’s now time to look under the hood of this demo application. When we were about to release the Touch Scheduler, we thought we should really put it to the test before releasing it. A few days later, we had written a collaborative app where changes are being broadcasted immediately when a task is modified. The live aspect of the application is not something you see often in web apps today but with tools like Express and Socket.IO it’s now very easy to accomplish. This post is quite long and contains lots of code, but here’s how we did it:

Setting up an Express web server

First of all, we had to setup a simple Express web server which runs on Node (you need at least Node 0.6+). Download Node.js here. We also need socket.io which you can find here. To avoid having to involve a database on the server, we simply created an in-memory array “DB” of tasks to serve as the database. It also has add/remove/update methods to support all CRUD operations. Below is the script which launches a simple Express instance on port 3000.

node_backend.js

///Module dependencies.
var http = require('http'),
    express = require('express'),
    app = module.exports = express.createServer(),
    fs = require('fs'),
    io = require('socket.io').listen(app);


//Server Configuration
app.configure(function(){
    app.use(express.bodyParser());
    app.use(express.methodOverride());
    app.use(express.static(__dirname + '/public'));
});

app.configure('development', function(){
    app.use(express.errorHandler({ dumpExceptions: true, showStack: true }));
});

app.get('/', function(req, res){
    res.sendfile(__dirname+'/public/index.html');
});

app.listen(3000);


//'DATABASE'
var DB = {
    eventsTable: [
        {Id: 1, ResourceId: 2, Name : 'Chase turkey', StartDate : "2010-12-09 08:00", EndDate : "2010-12-09 10:00", Done : true},
        {Id: 2, ResourceId: 1, Name : 'Stuff turkey', StartDate : "2010-12-09 10:00", EndDate : "2010-12-09 12:00", Done : true},
        {Id: 3, ResourceId: 3, Name : 'Cook turkey', StartDate : "2010-12-09 12:00", EndDate : "2010-12-09 15:00", Done : true},
        {Id: 4, ResourceId: 5, Name : 'Set table', StartDate : "2010-12-09 14:00", EndDate : "2010-12-09 16:00", Done : false},
        {Id: 5, ResourceId: 4, Name : 'Serve dinner', StartDate : "2010-12-09 16:00", EndDate : "2010-12-09 19:00", Done : false},
        {Id: 6, ResourceId: 6, Name : 'Hack on NodeJS', StartDate : "2010-12-09 16:00", EndDate : "2010-12-09 18:30", Done : false},
        {Id: 7, ResourceId: 7, Name : 'Clean up', StartDate : "2010-12-09 19:00", EndDate : "2010-12-09 20:00", Done : false},
        {Id: 8, ResourceId: 8, Name : 'Do laundry', StartDate : "2010-12-09 17:00", EndDate : "2010-12-09 19:00", Done : false}
    ],

    getEventsData: function(){
        return this.eventsTable;
    },

    // get record by ID
    getById: function(id){
        var table = this.getEventsData(),
            current;

        for(var i=0, l=table.length; i

We then created a basic HTML index.html page which includes Ext JS, Ext Scheduler, Socket.IO and our application JS file (in the example there is also a touch version including Sencha Touch instead). Contents below:
index.html



    

    
    

    
    

    
    

    
    

    
    

    
    

    
    

    




Now to the application bootstrap part, which means adding an app.js which should work for both Ext JS and Sencha Touch. This required a little bit of normalization code but nothing really difficult.
app.js
Ext.Loader.setConfig({
    enabled         : true,
    disableCaching  : true
});

Ext.require([
    'App.view.SchedulerGrid'
]);

// Limit the resolution, to avoid putting too much data on the wire.
Sch.preset.Manager.getPreset('hourAndDay').timeResolution.increment = 15;

Ext.application({
    name : 'App',

    viewport : {
        layout : {
            type : 'vbox',
            align : 'stretch'
        }
    },

    // Initialize application
    launch : function() {
        var field = new Ext.form.Text({
            fieldLabel : 'User ',
            height : 30,
            label : 'User ',
            value : 'John Doe',
            labelWidth: 115,
            listeners : {
                change : function(field, value) {
                    scheduler.userName = value;
                }
            }
        });

        var scheduler = Ext.create('App.view.SchedulerGrid', {
            title               : 'Node + socket.io example',
            startDate           : new Date(2010, 11, 9, 8),
            endDate             : new Date(2010, 11, 9, 20),
            flex                : 1,
            userName            : field.getValue()
        });

        var vp;

        if (Ext.versions.touch) {
            vp = Ext.Viewport;
        } else {
            // Ext JS
            vp = new Ext.Viewport(this.viewport);

            // Uncomment this to see what's happening in the EventStore
            //Ext.util.Observable.capture(scheduler.eventStore, function() { console.log(arguments); });

            scheduler.on('eventcontextmenu', this.onEventContextMenu, this);
            Ext.QuickTips.init();
        }

        vp.add([
            new Ext.form.Panel({
                region: 'north',
                hidden : Ext.os && Ext.os.is.phone,
                padding: 5,
                border : false,
                height : 55,
                items : field
            }),
            scheduler
        ]);
    },

    onEventContextMenu : function(scheduler, rec, e) {
        e.stopEvent();
        
        if (!scheduler.gCtx) {
            scheduler.gCtx = new Ext.menu.Menu({
                items : [
                    {
                        text : 'Delete event',
                        iconCls : 'icon-delete',
                        handler : function() {
                            scheduler.eventStore.remove(scheduler.gCtx.rec);
                        }
                    }  
                ]
            });
        }
        scheduler.gCtx.rec = rec;
        scheduler.gCtx.showAt(e.getXY());
    }    
});

This creates a simple Viewport and puts a scheduler inside it together with a form where you can enter your name. Let’s move on to take a peek at the App.view.SchedulerGrid class. 
UI classes
As with the app.js file, we had to make sure this class could be used regardless of the underlying Sencha framework. For this view class, we had to use the constructor instead of relying on the initComponent hook since this hook doesn’t exist in Sencha Touch (instead there is an init hook). By relying on the constructor, we saved us a bit of normalization code.
App.view.SchedulerGrid
Ext.define('App.view.SchedulerGrid', {
    extend              : 'Sch.panel.SchedulerGrid',

    requires            : ['App.store.EventStore', 'App.store.ResourceStore'],

    userName            : null,
    draggingRecord      : null,
    socketHost          : null,
    rowHeight           : 75,
    barMargin           : 10,
    eventBarTextField   : 'Name',
    viewPreset          : 'hourAndDay',
    eventBodyTemplate   : '
{Name}
{BlockedBy}
',

    constructor         : function() {
        var me = this;
        //create a WebSocket and connect to the server running at host domain
        var socket = me.socket = io.connect(me.socketHost);

        Ext.apply(me, {

            viewConfig : {
                onEventUpdate: function (store, model, operation) {
                    // Skip local paints of the record currently being dragged
                    if (model !== me.draggingRecord) {
                        this.horizontal.onEventUpdate(store, model, operation);
                    }
                }
            },

            columns : [
                { header : 'Name', width : 120, dataIndex : 'Name', sortable : true}
            ],

            eventRenderer : function(event, resource, tplData) {
                tplData.cls = '';

                if (event.data.Done) {
                    tplData.cls += ' sch-event-done ';
                }

                if (event.data.Blocked) {
                    tplData.cls += ' sch-event-blocked ';

                    if (event === me.draggingRecord) {
                        tplData.cls += ' x-hidden ';
                    }
                };
                return event.data;
            },

            resourceStore : new App.store.ResourceStore({ /* Extra configs here */}),

            eventStore : new App.store.EventStore({
                socket : socket
            })
        });

        this.callParent(arguments);

        // Change default drag drop behavior to update the dragged record 'live'
        me.on({
            eventdragstart          : me.onDragStart,
            eventdrag               : me.onEventDrag,

            aftereventdrop          : me.onDragEnd,
            scope                   : me
        });
    },

    onEventCreated : function(record) {
        record.set('Name', 'New task');
    },

    // Block a record when it is being dragged
    onDragStart : function(view, records) {

        var rec = records[0];
        this.draggingRecord = rec;

        rec.block(this.userName);
    },

    // Update underlying record as it is moved around in the schedule
    onEventDrag : function(sch, draggedRecords, startDate, newResource) {

        if (newResource && startDate) {
            var task = draggedRecords[0];
            task.beginEdit();
            task.setStartDate(startDate, true);
            task.assign(newResource);
            task.endEdit();
        }
    },

    // Unblock a record after dragging it
    onDragEnd : function(view, records) {
        this.draggingRecord = null;

        records[0].unblock();
    }
});

There are basically just two special things about the scheduler above: When a drag operation starts, the dragged Model is marked as blocked and as the cursor is moved, the model is continuously updated until the drag operation is finished. Since we don’t want our own ‘local’ view to repaint itself on such model updates, we override the onEventUpdate method to prevent it. 
Data classes
So far we have only presented the UI and the application classes. Let’s move on to where the real magic happens. First, let’s look at the underlying App.model.CustomEvent, its sources can be seen below. To have this class support both Sencha frameworks, we needed a bit of normalization code since ST uses its config system to define class members. 
App.model.CustomEvent
(function() {
    var fields = [
        { name  : 'Blocked' },
        { name  : 'BlockedBy' },
        { name  : 'Done', type : 'boolean'}
    ];

    Ext.define('App.model.CustomEvent', {
        extend      : 'Sch.model.Event',
        fields      : fields,

        // Sencha Touch
        config      : {
            fields  : fields
        },

        block       : function(userName) {
            this.set({
                Blocked     : true,
                BlockedBy   : userName
            })
        },

        unblock     : function() {
            this.set({
                Blocked     : false,
                BlockedBy   : null
            });
        }
    });
}());

This model is consumed by the App.store.EventStore which is just a plain store consuming a special mixin we wrote. It defines the model to use and also initializes the socket its bound to.
App.store.EventStore
Ext.define('App.store.EventStore', {
    extend : "Sch.data.EventStore",

    requires  : [
        'App.model.CustomEvent'
    ],

    config : Ext.versions.touch ? {
        socket  : null,
        model   : 'App.model.CustomEvent'
    } : null,

    model   : 'App.model.CustomEvent',
    mixins  : [
        'App.store.mixin.SocketIO'
    ],

    proxy: {
        type: 'memory',
        reader: {
            type: 'json'
        }
    },

    constructor : function() {
        this.callParent(arguments);
        this.initSocket();
    }
});

Socket.IO – client side
If you have worked with regular Sencha data stores before, you’ll note we are doing things a bit different here. We’re not using any of the load/save capabilities of the data package. We’re instead letting socket.io handle all the CRUD traffic to and from the server. The contract for this mixin class can be summarized as this statement: 
Observe the socket to know what others are doing, and let the others know what I’m doing

The socket API allows you to observe it using the on method, and you can use the emit to broadcast local changes.
App.store.mixin.SocketIO
Ext.define('App.store.mixin.SocketIO', {
    socket : null,

    getSocket : function () {
        return this.socket;
    },

    initSocket : function () {

        var that = this;
        var socket = this.getSocket();

        socket.on('server-doInitialLoad', function (data) {
            that.onInitialLoad(data);
        });
        socket.on('server-doUpdate', function (data) {
            that.onRemoteUpdate(data);
        });
        socket.on('server-doAdd', function (data) {
            that.onRemoteAdd(data);
        });
        socket.on('server-syncId', function (data) {
            that.onRemoteSyncId(data);
        });
        socket.on('server-doRemove', function (data) {
            that.onRemoteRemove(data);
        });

        this.myListeners = {
            add             : this.onLocalAdd,
            update          : this.onLocalUpdate,
            remove          : this.onLocalRemove,
            addrecords      : this.onLocalAdd,
            updaterecord    : this.onLocalUpdate,
            removerecords   : this.onLocalRemove
        };

        this.addMyListeners();

        //Load initial data to Store from Server
        this.doInitialLoad();
    },

    addMyListeners : function () {
        //Add event listeners to store operations
        this.on(this.myListeners);
    },

    removeMyListeners : function () {
        //Add event listeners to store operations
        this.un(this.myListeners);
    },

    /**
     * Emit event to server in order to receive initial data for store from the DB.
     */
    doInitialLoad : function () {
        this.getSocket().emit('client-doInitialLoad');
    },

    /* BEGIN REMOTE LISTENER METHODS */

    /**
     * New records were added remotely, add them to our local client store
     */
    onRemoteAdd : function (data) {
        var records = data.records,
            record,
            current,
            model = this.getModel();

        this.removeMyListeners();

        for (var i = 0, l = records.length; i < l; i += 1) {
            current = records[i].data;

            //change dates from JSON form to Date
            current.startDate = new Date(current.StartDate);
            current.endDate = new Date(current.EndDate);

            // Work around a bug in ST when adding new records (internalId not set correctly)
            this.add(new model(current, current.Id));
        }

        this.addMyListeners();
    },

    onRemoteSyncId : function (data) {
        var records = data.records,
            model = this.getModel();

        this.removeMyListeners();

        Ext.Array.each(records, function(updatedRecord) {
            var internalId = updatedRecord.internalId;

            this.each(function (rec, idx) {
                if (rec.internalId == internalId) {
                    this.remove(rec);
                    this.add(new model(updatedRecord.data, updatedRecord.data.Id))
                    return false;
                }
            }, this);
        }, this);

        this.addMyListeners();
    },

    /**
     * Records were updated remotely, update them in our local client store
     */
    onRemoteUpdate : function (data) {
        var localRecord;

        // Only one record updated at a time
        data = data.record.data;

        this.removeMyListeners();

        localRecord = this.getById(data.Id);
        if (localRecord) {
            data.StartDate && (data.StartDate = new Date(data.StartDate));
            data.EndDate && (data.EndDate = new Date(data.EndDate));

            localRecord.set(data);
        }

        this.addMyListeners();
    },

    /**
     * Records were removed remotely, remove them from our local client store
     */
    onRemoteRemove : function (data) {
        var ids = data.data,
            record,
            current;

        this.removeMyListeners();

        for (var i = 0, l = ids.length; i < l; i += 1) {
            current = ids[i];
            record = this.getById(current);

            this.remove(record);
        }

        this.addMyListeners();
    },

    /**
     * Initial data loaded from server.
     */
    onInitialLoad : function (data) {
        var data = data.data;
        (this.loadData || this.setData).call(this, data);
    },

    /* EOF REMOTE LISTENER METHODS */


    /* BEGIN LOCAL STORE LISTENER METHODS */

    /**
     * On adding records to client store, send event to server and add items to DB.
     */
    onLocalAdd : function (store, records, index, opts) {
        var recordsData = [];
        records = records.length ? records : [records];

        for (var i = 0, l = records.length; i < l; i += 1) {
            records[i].data.Name = 'New Assignment';

            recordsData.push({
                data : records[i].data,
                internalId : records[i].internalId
            });
        }

        this.getSocket().emit('client-doAdd', { records : recordsData });
    },

    /**
     * On updating records in client store, send event to server and update items in DB.
     */
    onLocalUpdate : function (store, record) {
        var data = { Id : record.getId() };

        for (var prop in record.previous) {
            data[prop] = record.data[prop];
        }

        this.getSocket().emit('client-doUpdate', { record : { data : data } });
    },

    /**
     * On adding removing records from client store, send event to server and remove items from DB.
     */
    onLocalRemove : function (store, records, index, opts) {
        records = records.length ? records : [records];
        var ids = Ext.Array.map(records, function (rec) {
            return rec.get('Id');
        });

        this.getSocket().emit('client-doRemove', { ids : ids });
    }

    /* EOF LOCAL STORE LISTENER METHODS */
});

If you read the code above, you’ll also notice a few framework normalization snippets, but all in all it’s a trivial data mixin class. The final piece of this application is the socket.io integration on the server side. 
Socket.IO – server side
This is a quite straight forward piece of code. Once the socket connection is available we observe it for actions invoked on the client side (load/update/add/remove). Using the emit method of the broadcast property of the socket, we can reach all connected clients. 
node_backend.js
// WEBSOCKETS COMMUNICATION
io.sockets.on('connection', function (socket) {

    //Load initial data to client Store
    socket.on('client-doInitialLoad', function(data){
        socket.emit('server-doInitialLoad', { data : DB.getEventsData()});
    });

    //Update records in DB and inform other clients about the change
    socket.on('client-doUpdate', function(data){
        var record   = data.record;

        DB.update(record);

        socket.broadcast.emit('server-doUpdate', data);
    });

    //Add record to DB and inform other clients about the change
    socket.on('client-doAdd', function(data){
        var records   = data.records;

        DB.add(records);

        socket.broadcast.emit('server-doAdd', { records : records });

        //Sync ID of new record with client Store
        socket.emit('server-syncId', { records : records });
    });

    //Remove record from DB and inform other clients about the change
    socket.on('client-doRemove', function(data){
        var ids   = data.ids;

        DB.remove(ids);

        socket.broadcast.emit('server-doRemove', { data : data.ids });
    });
});

Styling
Finally, to visualize that someone else is moving a task bar on your screen, we placed a hand cursor for tasks that are in the ‘Blocked’ state. Next to the cursor, we also show the name of the user moving the task. This gives any observing users an extra clue about what is going on.

Summing up…
By combining our products with Ext JS, Sencha Touch, Express and Socket.IO we were able to write a cool collaborative application with realtime updates. We were also able to reuse the application code for both Sencha frameworks with only a very tiny amount of normalization code. If you like this example and find it useful (or if you have suggestions of how it can be improved), please let us know in the comments. To try it out, you need to download the Ext Scheduler 2.2 version and look in the ‘/examples/nodejs’ folder. There is an ‘index.html’ file for desktop and an ‘index_touch.html’ for touch devices.
]]>
			http://www.bryntum.com/blog/under-the-hood-of-the-socket-io-express-example/feed/
		0
		
		
		
		http://www.bryntum.com/blog/road-to-ext-scheduler-2-2-upgrade-guide/
		http://www.bryntum.com/blog/road-to-ext-scheduler-2-2-upgrade-guide/#comments
		Fri, 08 Feb 2013 14:45:04 +0000
		Mats Bryntse
				
		
		
		

		http://www.bryntum.com/?p=2517
		We just released the first 2.2 beta version in the CustomerZone. This release has quite a few changes due to some major refactorings mentioned in my previous post. To sum up, we adapted a lot of the code to be shared with our Sencha Touch version and we have also tried hard to eliminate as many private Ext JS overrides as possible. A few of the changes in this ...]]>
				We just released the first 2.2 beta version in the CustomerZone. This release has quite a few changes due to some major refactorings mentioned in my previous post. To sum up, we adapted a lot of the code to be shared with our Sencha Touch version and we have also tried hard to eliminate as many private Ext JS overrides as possible. A few of the changes in this release may break backwards compatibility, depending on how you use our components. Here is the API Changes section of the 2.2-beta-1 changelog:


[API CHANGES]

    – BREAKING: forceFit now defined on Panel, it was previously on the View. Compatibility patch installed.

    – BREAKING: Removed Sch.util.HeaderRenderers class (should no longer be required).

    – BREAKING: Removed Sch.view.Locking class.

    – BREAKING: Inner panel is no longer an instance of our Sch.panel.SchedulerXXX classes, it is whatever Ext JS decides

     (normally a regular Ext.grid.Panel)

    – ‘aftereventdrop’ now includes the dragged records as a new argument

    – Removed ‘useDragProxy’ option of Sch.feature.DragDrop

    – Removed ‘Sch.feature.DragZone’ class


Let’s walk through this list, one by one! 
forceFit now defined on Panel
This one is pretty self explanatory, the forceFit config option which makes sure all the time columns fit inside the viewport is now defined on the panel level, instead of the view. 
// v2.1 :
new SchedulerPanel({
    viewConfig : { forceFit : true },
    ...
});

// v2.2 :
new SchedulerPanel({
    forceFit : true,
    ...
});

For the sake of backwards compatibility, we look for the flag on the viewConfig, so this change isn’t really breaking but you should still change your code if you use this config option.
Removed Sch.util.HeaderRenderers
This class was introduced as a performance booster in a previous version when every time column was implemented as its own Ext.grid.Column. We now only use one Ext.grid.Column for the entire schedule, meaning there is no overhead in having many cells as it previously was and the need for this class is gone. If you still require it for some reason, you can still keep the copy from the 2.1 release, though it’s no longer supported officially.
Removed Sch.view.Locking class
This class previously subclassed the Ext.grid.LockingView and relayed events from the inner ‘normal’ view to the top view. From the top view, it was then re-relayed to the top panel. In 2.2, the scheduler panel relays the SchedulerView events directly and there is no longer any need to override this private Ext JS class.
Inner panel is no longer an instance of our Sch.panel.SchedulerXXX classes
This is a quite major change, but makes it a lot easier for us maintain our product. In 2.1 we were overriding internals of the GridPanel which is never a good thing. We no longer use our own panel class for any of the child grids. In 2.1, the SchedulerPanel consisted of a top SchedulerPanel, with a locked GridPanel + a normal SchedulerPanel (which had a SchedulerView). In 2.2, there is a main SchedulerPanel, with a locked GridPanel and a normal GridPanel. The normal grid panel is using a SchedulerView. This could potentially be an issue for you if you have written your own plugins which assumes that the previously nested SchedulerPanel existed. An example:
Ext.define("MyEditor", {
    extend      : "Ext.form.FormPanel",

    lockableScope : 'normal',
    
    init : function (grid) {
        
        // => ERROR! getSchedulingView is not a property of Ext.grid.Panel
        this.schedulerView  = grid.getSchedulingView();

        this.schedulerView.on({
            afterrender     : this.onSchedulerRender,
            destroy         : this.onSchedulerDestroy,
            dragcreateend   : this.onDragCreateEnd,
            
            scope           : this
        });

        ...
    },

For sake of backwards compatibility, we added an inline override to make sure the ‘getScheduling’ method exists on the GridView, but you should not rely on its existence (you might get other similar errors about missing methods on the GridPanel). To update your code and fix the issue above, you have two options.
1. Register the plugin in the ‘top’ panel scope.
Ext.define("MyEditor", {
    extend      : "Ext.form.FormPanel",

    lockableScope : 'top',  // Attach this plugin the 'top' panel which is the SchedulerPanel
    
    init : function (grid) {
        
        // => Works! getSchedulingView is a method of the SchedulerPanel
        this.schedulerView  = grid.getSchedulingView();

        ...
    },

2. Change to use ‘getView’ instead.
Ext.define("MyEditor", {
    extend      : "Ext.form.FormPanel",

    lockableScope : 'normal',

    init : function (grid) {
        
        // => Works! getView is a method of the GridPanel
        this.schedulerView  = grid.getView();

        ...
    },

Removed ‘useDragProxy’ option of Sch.feature.DragDrop
This option was introduced in the early days before we started using document.elementFromPoint for the drag drop implementation. All browsers support this reliably and this option should no longer be required.
Removed ‘Sch.feature.DragZone’ class
This class was introduced in the early days before we started using document.elementFromPoint for the drag drop implementation. If you rely on this class, you can still keep the source code from the previous version and maintain it – though it is no longer supported by us. 
Please give us feedback
The refactorings we made for 2.2 will make a huge difference as we support newer Ext JS releases. We’re no longer overriding lots of private Ext JS internals and we have new unit tests to prove it. We have listed the breaking changes above and we hope we did not miss anything, if we did please let us know as soon as possible. We’re eager to hear about your experience and to get your feedback after you have upgraded to the new version. If you stumble upon any issues, please let us know by starting a thread in our forums. 
]]>
			http://www.bryntum.com/blog/road-to-ext-scheduler-2-2-upgrade-guide/feed/
		0
		
		
		
		http://www.bryntum.com/blog/road-to-ext-scheduler-v2-2-overrides/
		http://www.bryntum.com/blog/road-to-ext-scheduler-v2-2-overrides/#comments
		Thu, 31 Jan 2013 15:38:14 +0000
		Mats Bryntse
				
		
		
		

		http://www.bryntum.com/?p=2485
		We’re currently busy finalizing a major refactoring of our Ext Scheduler component which will be released as v2.2. There are two major reasons for this refactoring. First of all we needed to refactor to enable certain pieces of the core functionality to be shared with our Touch Scheduler. These bits of code relate to non-UI parts of the component, such as stores, models, utility classes etc. The second reason for ...]]>
				We’re currently busy finalizing a major refactoring of our Ext Scheduler component which will be released as v2.2. There are two major reasons for this refactoring. First of all we needed to refactor to enable certain pieces of the core functionality to be shared with our Touch Scheduler. These bits of code relate to non-UI parts of the component, such as stores, models, utility classes etc. The second reason for the refactoring, was to future proof the component a bit and clean up as many Ext JS overrides as possible. With the recent Ext JS 4.2 beta releases, too many things broke that should not break. 

Global Ext JS overrides
In the latest official version of Ext Scheduler, things are pretty much under control. There’s a large unit test suite covering loads of scenarios and the component is very stable. For example, we’re testing that no global variables are leaked. We also scan the entire Ext JS source tree to find any global overrides of the Ext JS library (a bad practice we used in older versions). 
// Our Siesta suite will detect this and fail
Ext.grid.View.override({
   refresh : function() {
       // Do something else
   }
});

We don’t write code like this anymore. Override code like this introduces a lot of uncertainty and is just as bad as regular global variables. As a component maker, we should not make any changes to our ‘surroundings’. Thanks to our zero-tolerance test, any attempt to make a global Ext JS override will now break our build. You can check how the test is performed in our test named /tests/sanity/012_no_overrides.t.js .
Overriding private Ext JS methods
Another aspect of overrides is when you override a private method in a subclass (see code below). When faced with a tricky problem, this can be tempting since there is nothing stopping you in the world of javascript and Ext JS. But overriding non-public and non-documented methods will likely lead to problems, maybe not tomorrow – but at some point. It happened to us quite frequently with each new version of Ext JS we had to support. At too many places we had simply overwritten private Ext JS methods, whose implementations then changed slightly in newer releases. 
// Overriding a private method of the superclass
Ext.define("Sch.mixin.TimelineGridView", {
    extend : 'Ext.grid.View',

    // We don't want Ext guessing if this row should be repainted or not
    // @OVERRIDE
    shouldUpdateCell : function() { return true; }
});

The snippet above looks harmless but it could very well lead to an issue if the shouldUpdateCell method is renamed or removed from the Ext GridView class. Overrides like this should be considered as the last resort to solve a particular problem. If there is a way to solve the issue by relying on the public Ext JS API instead it is definitely preferred. In real life applications, it’s hard to completely avoid doing such overrides though, so how do you best deal with these overrides? We already tried ignoring the overrides, and it turns out that ignoring a problem doesn’t really solve it.   
Dealing with overrides
In our upcoming 2.2 version, each override of a private method is annotated with a // @OVERRIDE comment to warn anyone reading the code. If unit tests start breaking when we try a new version of Ext JS, those methods are prime candidates to review. This however is not enough, we can do better. I just wrote a simple Siesta unit test that will help us identify our weak spots as we upgrade to newer versions of Ext JS. It turned out to be very easy:
StartTest(function (t) {
    t.expectGlobal('Docs'); // JsDuck

    // Ignore some symbols that should be ignore + some bugs in the Ext docs
    var ignoreRe = /Ext.dd|DragZone.destroy|DragDrop.destroy|DragSource.destroy|Ext.grid.plugin.Editing.init|afterRender|initComponent|Ext.Base.configClass|Ext.Base.destroy/;

    var isPrivate = function(fullName) {
        var priv = false;

        Ext.Array.each(Docs.data.search, function(property) {

            if (property.fullName === fullName){
                priv = property.meta.private;
                return false;
            }
        });

        return priv;
    };


    function findInSuperClasses(sourceCls, property) {
        var cls = sourceCls.superclass.self;

        while (cls && cls.prototype) {
            var name = Ext.ClassManager.getName(cls);
            var fullName = name + '.' + property;

            if (name.match(/^Ext./) &&
                !ignoreRe.test(fullName) &&
                cls.prototype.hasOwnProperty(property))
            {
                if (isPrivate(fullName)) {
                    return name;
                } else {
                    return false;
                }
            }
            cls = cls.superclass && cls.superclass.self;
        }

        return false;
    }

    var MAX_NBR_OVERRIDES = 10;
    var nbrFound = 0;

    Ext.iterate(Ext.ClassManager.classes, function (className, constr) {
        if (!className.match('Sch.')) return;

        for (var o in constr.prototype) {

            // Check only own properties, and only functions for now
            if (constr.prototype.hasOwnProperty(o) && typeof constr.prototype[o] === 'function') {
                var result = findInSuperClasses(constr, o);

                if (result) {
                    t.todo(function(t) {
                        t.fail('Class ' + className + ' overrides ' + result + ':' + o);
                    })
                    nbrFound++;
                }
            }
        }
    });

    t.isLessOrEqual(nbrFound, MAX_NBR_OVERRIDES, 'Should not introduce new overrides of private methods');
});

The test isn’t 100% fool proof, you could still override classes at run time that won’t be detected by this test (though that is a very unusual practice). Running this test against the latest official Ext Scheduler release reports 65 overrides, which is waaaay too many. This is very clear proof and it explains why we’ve been experiencing painful upgrades. After our 2.2 refactorings, the result looks a lot better:
Launching PhantomJS 1.6.0 at http://lh/ExtScheduler/tests/index-no-ui.html

fail 1 - Class Sch.mixin.Lockable overrides Ext.grid.Lockable:constructLockablePlugins
fail 2 - Class Sch.mixin.Lockable overrides Ext.grid.Lockable:injectLockable
fail 3 - Class Sch.model.Customizable overrides Ext.data.Model:afterEdit
fail 4 - Class Sch.data.FilterableNodeStore overrides Ext.data.NodeStore:onNodeExpand
fail 5 - Class Sch.selection.EventModel overrides Ext.selection.Model:bindComponent
fail 6 - Class Sch.selection.EventModel overrides Ext.selection.Model:onSelectChange
fail 7 - Class Sch.plugin.TreeCellEditing overrides Ext.grid.plugin.CellEditing:onEditComplete
fail 8 - Class Sch.view.TimelineGridView overrides Ext.view.Table:shouldUpdateCell
fail 9 - Class Sch.view.TimelineGridView overrides Ext.view.View:processUIEvent

[FAIL]  sanity/017_override_scan.t.js?Ext=external
There are failures

We have now brought it down to 9 overrides, which is a lot more manageable. For an extremely small investment (the test took me < 1hr to write) we now have a very good overview of our component weak spots when it’s time for the next upgrade. As the 2.2 version relies a lot more on the public API, upgrading to and supporting new Ext JS versions should hopefully be much easier.
How do you deal with overrides in your application? Please share any tips you have in the comments section?
]]>
			http://www.bryntum.com/blog/road-to-ext-scheduler-v2-2-overrides/feed/
		2
		
		
		
		http://www.bryntum.com/blog/managing-stores-in-a-complex-component/
		http://www.bryntum.com/blog/managing-stores-in-a-complex-component/#comments
		Wed, 30 Jan 2013 17:31:10 +0000
		Mats Bryntse
				
		
		
		

		http://www.bryntum.com/?p=2480
		The Ext Gantt chart deals with a lot of observable data stores: Tasks, Dependencies, Assignments, Resources etc. A typical view component will observe its data stores and react to their changes. When building a view component that consumes data from one or more stores, it’s important to remember to de-register any store listeners in the Component destructor. If you don’t, you can end up with hard-to-trace errors after creating multiple ...]]>
				The Ext Gantt chart deals with a lot of observable data stores: Tasks, Dependencies, Assignments, Resources etc. A typical view component will observe its data stores and react to their changes. When building a view component that consumes data from one or more stores, it’s important to remember to de-register any store listeners in the Component destructor. If you don’t, you can end up with hard-to-trace errors after creating multiple views using the same store. Another common case where this happens is if you have a view component in a window that can be destroyed/closed. Once it’s re-opened, a new component instance is created and is tied to the same original data store. Consider this simple piece of code.

var taskStore = new Gnt.data.TaskStore();

var gantt = new Gnt.panel.Gantt({
    taskStore : taskStore
});

var gantt2 = new Gnt.panel.Gantt({
    taskStore : taskStore
});

gantt.destroy();

taskStore.getById(123).set('Name', 'Foo');

If the task store listeners aren’t cleaned up properly in the Gantt chart destructor, then code may be triggered in the first Gantt panel instance by a store listener even though the panel itself is destroyed. These errors are often tricky to debug and a good idea is to test this, it’s even quite easy. This is what we use for our tests to make sure we don’t ‘leak’ any listeners.
StartTest(function(t) {
    t.diag('Gantt not rendered');

    var assignmentStore = t.getAssignmentStore();
    var resourceStore = t.getResourceStore();
    var dependencyStore = t.getDependencyStore();

    var taskStore = t.getTaskStore({
        dependencyStore : dependencyStore,
        resourceStore   : resourceStore,
        assignmentStore : assignmentStore
    });

    t.snapShotListeners(taskStore, 'taskStore');
    t.snapShotListeners(taskStore.nodeStore, 'nodeStore');
    t.snapShotListeners(dependencyStore, 'dependencyStore');
    t.snapShotListeners(resourceStore, 'resourceStore');
    t.snapShotListeners(assignmentStore, 'assignmentStore');

    var g = t.getGantt({
        taskStore       : taskStore,
        assignmentStore : assignmentStore,
        resourceStore   : resourceStore,
        dependencyStore : dependencyStore
    });

    // Should clean all listeners
    g.destroy();

    t.verifyListeners(taskStore,  'taskStore', 'Listeners cleaned up on taskStore');
    t.verifyListeners(assignmentStore,  'assignmentStore', 'Listeners cleaned up on assignmentStore');
    t.verifyListeners(dependencyStore,  'dependencyStore', 'Listeners cleaned up on dependencyStore');
    t.verifyListeners(resourceStore,  'resourceStore', 'Listeners cleaned up on resourceStore');
    t.verifyListeners(taskStore.nodeStore,  'nodeStore', 'Listeners cleaned up on nodeStore');

    t.diag('Gantt rendered then destroyed');

    g = t.getGantt({
        renderTo        : Ext.getBody(),
        columnLines     : true,
        taskStore       : taskStore,
        assignmentStore : assignmentStore,
        resourceStore   : resourceStore,
        dependencyStore : dependencyStore
    });

    g.destroy();

    t.verifyListeners(taskStore,  'taskStore', 'Rendered: Listeners cleaned up on taskStore');
    t.verifyListeners(assignmentStore,  'assignmentStore', 'Rendered: Listeners cleaned up on assignmentStore');
    t.verifyListeners(dependencyStore,  'dependencyStore', 'Rendered: Listeners cleaned up on dependencyStore');
    t.verifyListeners(resourceStore,  'resourceStore', 'Rendered: Listeners cleaned up on resourceStore');
    t.verifyListeners(taskStore.nodeStore,  'nodeStore', 'Rendered: Listeners cleaned up on nodeStore');
});

Above you can see that we verify that no listeners are left for 5 different stores, both when not rendering the panel and when rendering the panel (as we shouldn’t assume when the listeners are added). In our TestClass for Siesta we have added these two useful methods for Observables:
Class('Bryntum.Test', {

    isa: Siesta.Test.ExtJS,
    
    methods: {

        snapShotListeners : function(observable, name) {
            this._observableData = this._observableData || {};

            if (!name) throw 'Must provide a name for the observable';

            this._observableData[name] = this.global.Ext.apply({}, observable.hasListeners);

            // Delete new Ext JS 4.2 properties
            if ('_decr_' in this._observableData[name]) {
                delete this._observableData[name]._decr_;
                delete this._observableData[name]._incr_;
            }
        },

        verifyListeners : function(observable, name, description) {
            var needListeners = this._observableData[name];

            this.isDeeply(observable.hasListeners, needListeners, description);
        }
    }
    // eof methods
})

Hope this helps you test your Observables!
]]>
			http://www.bryntum.com/blog/managing-stores-in-a-complex-component/feed/
		0