Clear Up
SharpKit Reference

BatchConfig Class


Base Types



Name Description


Name Description
autoStart True to immediately start processing the batch as soon as it is constructed (defaults to false) Defaults to: false
listeners A config object containing one or more event handlers to be added to this object during initialization. This should be a valid listeners config object as specified in the addListener example for attaching multiple handlers at once. DOM events from Ext JS Components While some Ext JS Component classes export selected DOM events (e.g. "click", "mouseover" etc), this is usually only done when extra value can be added. For example the DataView's itemclick event passing the node clicked on. To access DOM events directly from a child element of a Component, we need to specify the element option to identify the Component property to add a DOM listener to:
new Ext.panel.Panel({
            width: 400,
            height: 200,
            dockedItems: [{
            xtype: 'toolbar'
            listeners: {
            click: {
            element: 'el', //bind to the underlying el property on the panel
            fn: function(){ console.log('click el'); }
            dblclick: {
            element: 'body', //bind to the underlying body property on the panel
            fn: function(){ console.log('dblclick body'); }
pauseOnException True to pause the execution of the batch if any operation encounters an exception (defaults to false). If you set this to true you are responsible for implementing the appropriate handling logic and restarting or discarding the batch as needed. There are different ways you could do this, e.g. by handling the batch's exception event directly, or perhaps by overriding onBatchException at the store level. If you do pause and attempt to handle the exception you can call retry to process the same operation again. Note that operations are atomic, so any operations that may have succeeded prior to an exception (and up until pausing the batch) will be finalized at the server level and will not be automatically reversible. Any transactional / rollback behavior that might be desired would have to be implemented at the application level. Pausing on exception will likely be most beneficial when used in coordination with such a scheme, where an exception might actually affect subsequent operations in the same batch and so should be handled before continuing with the next operation. If you have not implemented transactional operation handling then this option should typically be left to the default of false (e.g. process as many operations as possible, and handle any exceptions asynchronously without holding up the rest of the batch). Defaults to: false
© Copyright 2005-2011 SharpKit. All rights reserved.