View Full Version : [Solved] EditorGridPanel too slow for speedy data entry

Steffen Hiller
19 Nov 2009, 7:45 AM

my client is often entering a lot of data through an EditorGridPanel. He complains that it causes a lot of data entry errors, since it often doesn't take the first characters while he types.
So, for example, with the TAB key he jumps to the next editable cell and enters 740, jumps via TAB to the next cell and so on. The result is, that the cell would only take 40 instead of 740 in this example.
One can imagine how annoying that is when entering a lot data in a row.

In this app we are using Ext JS 2.1, but unfortunately, this behaviour is easy reproducable in Ext JS 3.0 as well.

Go to this official EditorGrid example: http://www.extjs.com/deploy/dev/examples/grid/edit-grid.html

Edit first row or add a new row. When you have the "Light" cell selected and in editor mode press with a left hand finger TAB and with a right hand finger a number, and that fast.
This doesn't have to be very fast, just the speed you would have when jumping and entering data fast.
The actual result is, that the number is not taken.
The expected result is, that the number should be taken/put into the input field.
If you hit TAB and a number with a small pause, it works.

This happens with any field, doesn't have to be a price/number field. If you move the first column "Common name" to the second column, you can reproduce this with a normal string field and press any character, not just a number (NumberField only excepts numbers).

I can reproduce this with the latest Firefox 3.5 (which my client is using as well) and the latest Chrome 4.0 for Mac.

So, apparently the browser takes too long to complete the edit of one field, and render/activate the next editor field.
Has anybody experienced the same problem or an idea how to optimize the speed for this specific action?

Somehow I imagine that this is not uncritical, since I suppose that the EditorGridPanel is often used for data heavy applications where a lot of data is entered.

I tested the same action with the RowEditor (http://www.extjs.com/deploy/dev/examples/grid/row-editor.html), speed seems not to be a problem here, since the input fields are already rendered and ready from the start on.
I wonder if the idea of RowEditor was to solve this speed problem?

Anyway, would be great if we could figure out a solution without having to use the RowEditor, since we're on Ext JS 2.1, using a lot of custom stuff, and a upgrade to Ext 3 wasn't planned due to time. One solution might be using RowEditor with Ext 2 though?

Hope this post didn't get too epic.

Really would appreciate any help!


19 Nov 2009, 8:01 AM
are you using the same editor class for multiple columns?

Like, if you have three columns that accept plain text, are you using the same instance of editor for those columns?

Steffen Hiller
19 Nov 2009, 8:09 AM
Hey Jay,

thanks for looking at this problem.

I'm using the same class for some columns, but I'm not using the same instance.
So, for example I have multiple columns with "editor: new Ext.form.TextField()" and multiple with "editor: new Ext.form.NumberField()".


P.S. Could you reproduce the problem?

19 Nov 2009, 8:15 AM
Yes i could. There is a notceable delay.

My only suggestion is to either work on a plugin that renders all of the editors or tell that dude to slow down. Slap him if you have to.

Btw, it's wasteful to use different editors for similar columns. Being that the fields are only shown one at a time, use the same instance of an field when you can. save resources man!

Steffen Hiller
19 Nov 2009, 8:31 AM

hmm, looks like I have to look into the RowEditor. Rendering all input fields for a row at wants doesn't seem to be easy, since the EditorGridPanel is made to only have one editable field active at a time.

First, it's not just one dude, it's multiple people that do data entry. Second, the client has more reason to slap me (which I have to forward to the Ext team) since this is obviously a problem with Ext JS. And as I said, you don't have to be god-fast to experience the problem.

Is the one editor instance for multiple fields solution covered in your book? :-) (I already bought it, but didn't had a chance to check/review it yet, sorry about that :-/)
But anyway, isn't Ext JS destroying the Editor instance after the edit has been completed?
I see that the time of instantiating could be save though by a one instance solution, so it's not memory rather than the cpu resource you refer to right?

19 Nov 2009, 8:39 AM
don't apologize. -- yes it is.

the row editor is a 'nice to have' plugin, but it has its own issues.

I tested out google's spreadsheet. While it has speed issues (on firefox), it did not miss any data. :-\

Steffen Hiller
19 Nov 2009, 9:47 AM
The latest ext-3.0.x version in svn seems to have solved this performance problem. Earlier revisions still have the problem.
Trying to figure out now which commit in between fixed it, suggestions are welcome. :-)

19 Nov 2009, 9:49 AM
hold on a second.

first things first: I don't think you can mix code from 3.0 with 2.x from a licensing perspective.

Steffen Hiller
19 Nov 2009, 9:58 AM
I was thinking about that, too.
First let me check if it's really fixed via a commit, and which commit it is,
then, if I have the Ext JS 3 license, I think it's no problem to use the fix in Ext JS 2 code.

Steffen Hiller
19 Nov 2009, 10:27 AM
Ha, it's commit 5087!
The commit message and the code diff says it all:

Fix for tabbing from combo when not in a grid. Related to the keyboard fixes that were made in a previous revision. This fix also removes the need for a delay in the RowSelectionModel edit grid.

g.startEditing.defer(10, g, [r, c]);
// changed to
g.startEditing(r, c);

Btw, as the commit message might suggest, the problem was not just when jumping out of a combo box. But the delay elimination fixed it for all cases. Very cool!

My only dilemma now is, what do I do with the app? :-/
Upgrading from Ext 2 to Ext 3? Oh my. This will be most likely like fixing one problem and introducing 10 others (because of all my custom stuff). :-/

Steffen Hiller
19 Nov 2009, 10:36 AM
Btw, I'm surprised that a commit from August 16th isn't in the online version for the examples yet.
The HTTP header for ext-all.js says it's last modified on August 4th, so I guess they haven't deployed for a while.

Steffen Hiller
19 Nov 2009, 6:37 PM
For the record, the "g.startEditing.defer(10, g, [r, c]);" line didn't exist yet in Ext JS 2.

I solved the problem though by removing the work-around "defer(50, this);" in the startEditing method of the EditorGrid class, which only was a work-around for non-firefox browser, and my app is luckily only used by firefox users. :-)