-
8 Jun 2012 9:08 AM #1
CellEditing - validateedit does not have correct value
CellEditing - validateedit does not have correct value
REQUIRED INFORMATION
Ext version tested:- Ext 4.1.0, 4.0.7
- Firefox 12
- Firefox 13
- Chrome
- The validateedit event with the CellEditing plugin is supposed to contain 2 fields on the context, value and originalValue. These should have the current (new) value of the cell, and the original value of the cell respectively. When this event is fired from the CellEditing plugin both of these are set equal to originalValue.
- Create a grid and bind the CellEditing plugin, attach a function to the validateedit event of that grid, add a row to that grid with the editor set to have xtype 'numberfield' (other types probably work for this bug as well as I don't see any reason in the code they should be different), then edit the value, on leaving the editor inspect the arguments passed to your function, value and originalValue will both have the original value regardless of what has been entered in the cell.
- The value parameter should have the current (new) value of the cell.
- The original value is also populated for the value parameter
- Also, the record is falsely marked dirty when no information is changed. Simply opening the editor then leaving the cell without ever typing in it causes the record to be marked as dirty which I do not believe is right.
-
8 Jun 2012 12:05 PM #2
-
8 Jun 2012 12:34 PM #3
Hi Scott,
Thanks so much for taking the time to reply. This does help a little bit but it still seems a bit off.
If I declare the function like this:
It shows the old value for both event.value and event.originalValue no matter what I set the delay to. But if I declare it like this:Code:validateedit: { fn: function(editor, event, eOpts) { console.log(event.value); console.log(event.originalValue); } }
Then it works when the delay is >= 1.Code:validateedit: { function(editor, event, eOpts) { console.log(event.value); console.log(event.originalValue); }
Which is great, except that this doesn't seem quite right to me, we shouldn't have to wait for rendering before deciding whether we would like to cancel the edit altogether. Also, if that is what we are waiting for, what happens if the browser or computer slows down briefly, we might miss this time window.
Comparing the code of the cell editor to the row editor I see one big difference in how this is handled. The row editor seems to have a validateEdit call which rummages about and properly sets the value parameter directly, while the cell editor does not. It seems to me like if the validateEdit function set the value property then the delay would be unnecessary it would be a better solution.
I have had success making this work without a delay and using the first style of function definition by overriding CellEditing's validateEdit function and locating the correct value to set then using ext.apply to set the value. Unfortunately this method requires quite a bit of rummaging about in the editors property of the cellediting object. I will try to post the code here when I have it cleaned up and working a little bit better.
-
8 Jun 2012 12:50 PM #4
I have finished a quick round of testing and have refactored this code to make it a little bit easier to read, here is the code I was discussing above that I feel corrects this issue properly:
As you can see it is based heavily on the RowEditing method of updating this information. What would be your opinion of this fix / workaround?Code:Ext.define('Ext.grid.plugin.CellEditingFixed', { override: 'Ext.grid.plugin.CellEditing', validateEdit: function() { var me = this, editors = me.editors.items, context = me.context, record = context.record, newValue, originalValue, editor, name, i; for (i=0;i<editors.length;i++) { editor = editors[i].items.items[0]; if (editor.name === context.field) { Ext.apply(context, { value: editor.value } ); } } return this.callParent(arguments); } });
-
20 Sep 2012 8:12 PM #5Sencha - Community Support Team
- Join Date
- Nov 2007
- Location
- Helsingborg, Sweden
- Posts
- 2,455
- Vote Rating
- 52
Bump, is this fixed for 4.1.1 or 4.1.2?
-
20 Sep 2012 10:06 PM #6
This is already resolved, should be in the next patch release: EXTJSIV-2550
Evan Trimboli
Sencha Developer
Twitter - @evantrimboli
Don't be afraid of the source code!
This issue duplicates another issue.


Reply With Quote