This was addressed at SenchaCon. I'm not sure on the details, but some future release of Ext JS (and probably Touch) will come with the full test suite.Originally Posted by Scorpie
This was addressed at SenchaCon. I'm not sure on the details, but some future release of Ext JS (and probably Touch) will come with the full test suite.
Thanks for the information, but I've been waiting for this since SenchaCon 2010.
http://docs.sencha.com/extjs/4.2.1/#!/video/17666102
Skip to around 6:07 if you just want the testing part. It's stated that there are over 4000 unit tests. They also introduce a new product / methodology that was developed in house called Visual QA. It sounds great - taking screen compares for UI regression testing. There were hundreds of these tests.
One of the questions was whether they were going to open this Visual QA up to the public. They said they would (37:06).
I honestly never heard of Visual QA again - did they describe it at this year's conference and give an actual time frame for release? I realize a lot has changed with Ext since 2010, so maybe they use something different now.
Don't get me wrong - I'm very excited for some of the things unveiled at SenchaCon 2013 and I'd love to get my hands on the official test suite. However, I've learned to take conference announcements with a grain of salt. I'll believe it when I can hold it in my hands and break it : )
The presentation is what I like to hear. I had not stumbled across that yet. Thanks. So if they've got tests, then what's happening? They're missing the discipline necessary to ensure that tests are actually written and kept up to date? And where are these? Where they vapour? And why would someone from Sencha not engage in this discussion? When problems crop up people look for reassurance that their investment in time/energy is worth it. The junk that occasionally appears shakes that confidence - and rightly so. Earth to Sencha?
@firefoxSafari wasn't the 2010 SenchaCon where we were told that ExtJS v4 was *faster* than version 3 and thus resolved the performance problems that had been introduced in v3...
@rich02818 You have a good memory ; )
haha....oh how they have lied to us. hook, line, and sinker!
My two day upgrade experience from 4.1.1a to 4.2.1 is fair. I removed most of 4.1.1a patch except two of them: (1) html editor old value is null (2) grid single selection mode - select/un-select issue. That is not too bad.
However, 4.2.1 introduce one very critical bug for me: grid cell colIndex is incorrect when there are any hidden columns. The grid cell click and grid cell drag/drop will not work, also grid column renderer will have trouble if try to set md.tdCls based on colIndex. Got the patch to fix colIndex issue, then cell editor is not working due to colIndex is not match. Looks like we have to wait for next stable release 4.2.2?
Other minor issues with my apps during the upgrade : (simple patch will fix the bugs).
(1) grid grouping without set group - grid will not show up.
(2) grid grouping header name is not use rendered value (same bug in 4.0.x and fixed in 4.1.1a and come again in 4.2.1).
(3) tree run beforeitemexpand when load tree (4.1.1a is not). It is good fix.
(4) Grid/tree performance is about same as 4.1.1a after apply my own patch to reduce do layouts.
Wish Sencha can quickly release next stable version without introduce any critical bugs. We still release our application with 3.4.x and not be able to do so with 4.x.x due the critical bugs and performance issue, therefore, I have to develop any new features in our application with both 3.4.x and 4.x.x at the same time.
Can you provide your patch ?I think it will interest many people !
See below patch and and link for info.Can you provide your patch ?
http://www.sencha.com/forum/showthre...l=1#post936004
PHP Code:
//TODO patch need review for every extjs release
Ext.define('My.patch.data.Store', { override: 'Ext.data.Store', //grid performance bug
onProxyLoad: function(operation) {
var me = this,
resultSet = operation.getResultSet(),
records = operation.getRecords(),
successful = operation.wasSuccessful();
if (me.isDestroyed) {
return;
}
if (resultSet) {
me.totalCount = resultSet.total;
}
// Loading should be set to false before loading the records.
// loadRecords doesn't expose any hooks or events until refresh
// and datachanged, so by that time loading should be false
Ext.suspendLayouts(); //add
me.loading = false;
if (successful) {
me.loadRecords(records, operation);
}
if (me.hasListeners.load) {
me.fireEvent('load', me, records, successful);
}
//TODO: deprecate this event, it should always have been 'load' instead. 'load' is now documented, 'read' is not.
//People are definitely using this so can't deprecate safely until 2.x
if (me.hasListeners.read) {
me.fireEvent('read', me, records, successful);
}
//this is a callback that would have been passed to the 'read' function and is optional
Ext.callback(operation.callback, operation.scope || me, [records, operation, successful]);
Ext.resumeLayouts(true); //add
}
});
//TODO patch need review for every extjs release
Ext.define('My.patch.data.TreeStore', { override: 'Ext.data.TreeStore', //grid performance bug
onProxyLoad: function(operation) {
var me = this,
successful = operation.wasSuccessful(),
records = operation.getRecords(),
node = operation.node;
me.loading = false;
Ext.suspendLayouts(); // add
node.set('loading', false);
if (successful) {
if (!me.clearOnLoad) {
records = me.cleanRecords(node, records);
}
records = me.fillNode(node, records);
}
// The load event has an extra node parameter
// (differing from the load event described in AbstractStore)
/**
* @event load
* Fires whenever the store reads data from a remote data source.
* @param {Ext.data.TreeStore} this
* @param {Ext.data.NodeInterface} node The node that was loaded.
* @param {Ext.data.Model[]} records An array of records.
* @param {Boolean} successful True if the operation was successful.
*/
// deprecate read?
me.fireEvent('read', me, operation.node, records, successful);
me.fireEvent('load', me, operation.node, records, successful);
//this is a callback that would have been passed to the 'read' function and is optional
Ext.callback(operation.callback, operation.scope || me, [records, operation, successful]);
Ext.resumeLayouts(true); // add
}
});
OK I understand, thanks ! You've simply added suspend et resume layouts. Nice idea.
I think this technique could be added in a lot of other internal functions
Posting Permissions
