"onblur": "submit"

Ebbs

Hi All,

I discovered a bug today while stress testing my table. When I use the property "onblur": "submit" something strange happens when I am busy editing a cell and move immediately from it another one (I clicked on a different cell).

Basically the cell that I clicked on becomes un-editable - as in it assumes a read only state.

If I simply click outside the table (anywhere else on the page, except another cell), it works fine and the change is submitted and saved.

Does anyone have any idea how to fix it, or if it is catered for in the new 1.8 release? (BTW, I am using v1.7.6)

Kind regards
Ebbs

allan

Hi Ebbs,

I presume that this is with jEditable (like in this example: http://datatables.net/examples/api/editable.html )? I've just tried modifying that example to submit on blur and it seems to be okay. Are you using the latest version of the jEditable plug-in for jQuery?

Perhaps you can post a link to the example you are having problems with?

Allan

Ebbs

Hi Allan,

I checked versions before posting this discussion and I definitely have the latest version.

Looking at the link you provided I can see two differences between your page and mine:
1. I am using ASP.Net, but I don't think this should be the problem.
2. I am updating the whole row with JSON, where you are doing one cell at a time. Not sure if this could be the problem?

Here is my code:
[code]
function () {
var oTable = $('#example').dataTable({
"bPaginate": false,
"bInfo": false,
"bFilter": false,
"bLengthChange": false,
"bSearchable": false,
"bProcessing": true,
"bStateSave": true,
"bAutoWidth": false,
"aoColumnDefs": [
{ "sClass": "readonly", "aTargets": [1] }
],
"aoColumns": [{ "bVisible": false }, {}, {}, {}, {}],
"fnDrawCallback": function () {
$('#example tbody td:not(.readonly)').editable('update.aspx', {
"callback": function (sValue, y) {
/* Redraw the table from the new data on the server */
var aPos = oTable.fnGetPosition(this);
var result = jQuery.parseJSON(sValue);

oTable.fnUpdate([result["A"], result["B"], result["C"], result["D"], result["E"]], aPos[0], aPos[1]);
oTable.fnDraw();
},
"submitdata": function (value, settings) {
return {
"column": oTable.fnGetPosition(this)[2],
"row_info": oTable.fnGetData(oTable.fnGetPosition(this)[0]).toString()
};
},
"select": true,
"height": "14px",
"onblur": "submit"
});
}
});
[/code]

I'll have to speak to my boss about maybe posting a page with my code, or else I could mail you a demo solution?

allan

That's interesting doing a full row update - I've got to confess I'm not 100% sure what effect that will have on jEditable since the elements are being changed underneath it. Depending on the sequence of events, it could be that jEditable is actually making the cell editable, but when the update is writing to it and removing the edit box - then you can't get into edit mode at all, since jEditable already thinks it is in edit mode!

Are you able to update just the cell that has been edited, or is there a dependency on all cells in the row? Even if there is, I think it would be worth trying just updating the single cell and seeing what effect that has - if that is the case, then we know what the problem is. The workaround however, might be a bit more tricky since it will probably require more knowledge of jEditable than I have - caching the click or manually making the cell editable possibly...

Regards,
Allan

Ebbs

Hi Allan,

I think you are correct, jeditable is getting confused when I do a row update and leaving me with a cell that it thinks is editable, but is not.

I changed my code to reflect something more like the standard example you provided and as such my original problem goes away. However, it leaves me with a different problem. I have a column that is hidden which contains an ID which is critical to me for database operations. This is example html of what I have:
[code]




Column A


Column B


Column C


Column D


Column E






1_2_3


Sample B


Sample C


Sample D


Sample E






Column A


Column B


Column C


Column D


Column E




[/code]
This also reflects in the original code I posted with:
[code]
"aoColumns": [{ "bVisible": false }, {}, {}, {}, {}],
[/code]
The changed code (compared to the orignal that I posted) looks like this:
[code]
function () {
var oTable = $('#example').dataTable({
"bPaginate": false,
"bInfo": false,
"bFilter": false,
"bLengthChange": false,
"bSearchable": false,
"bProcessing": true,
"bStateSave": true,
"bAutoWidth": false,
"aoColumnDefs": [
{ "sClass": "readonly", "aTargets": [1] }
],
"aoColumns": [{ "bVisible": false }, {}, {}, {}, {}],
"fnDrawCallback": function () {
$('#example tbody td:not(.readonly)').editable('update_single_cell.aspx', {
"callback": function (sValue, y) {
var aPos = oTable.fnGetPosition(this);
oTable.fnUpdate(sValue, aPos[0], aPos[1]);
},
"submitdata": function (value, settings) {
return {
"column": oTable.fnGetPosition(this)[2],
"row_info": oTable.fnGetData(oTable.fnGetPosition(this)[0]).toString()
};
},
"select": true,
"height": "14px",
"onblur": "submit"
});
}
});
[/code]
The problem I have with the code above is that it will update the cell that I have edited, but also the cell before it. For example if I edit 'Sample C' to 'Test', 'Sample B' will also reflect 'Test'. Does that make sense?

I think it has something to do with the fact that I have a hidden column. Is this an easy fix?

If not, I might have a suggestion for a solution to my original problem. I got the idea from one of the JQuery AJAX properties called 'async: false'.

If you use 'async: false', it will instruct the JQuery request to "freeze" the page, as in not allow anything else to happen on the page until the AJAX request is complete.

If something similar is available on JEditable, then it might allow the first cell to complete its operation before moving on to the second cell that was clicked?

Kind regards
Ebbs

Ebbs

Hi Allan,

Seems like I should not have asked whether there is an easy fix to the second problem (the changed code problem), because as it seems, there is. I will have to do more tests to make absolutely sure, but I changed
[code]
oTable.fnUpdate(sValue, aPos[0], aPos[1]);
[/code]
to
[code]
oTable.fnUpdate(sValue, aPos[0] - 1, aPos[1]);
[/code]
and it seems to update the correct cell and not like I previously explained.

Let me know what you think of my suggestion.

Kin regards
Ebbs

Ebbs

Okay, no the solution I provided above does not work. Well, it does for one row tables, but when there are multi rows it goes all awry. Basically it will update the cell I changed, but then update the [row - 1], [cell - 1] too.

Any ideas?

I also noticed that the page I use for the AJAX request gets hit twice too. Not sure if this is part of the problem - but it wasn't before.

allan

Since you are using client-side processing, I would suggest that, rather than adding the jEditable stuff on every table draw, just do it once:

[code]

function () {
var oTable = $('#example').dataTable({
"bPaginate": false,
"bInfo": false,
"bFilter": false,
"bLengthChange": false,
"bSearchable": false,
"bProcessing": true,
"bStateSave": true,
"bAutoWidth": false,
"aoColumnDefs": [
{ "sClass": "readonly", "aTargets": [1] }
],
"aoColumns": [{ "bVisible": false }, {}, {}, {}, {}],
});

$('tbody td:not(.readonly)', oTable.fnGetNodes()).editable('update_single_cell.aspx', {
"callback": function (sValue, y) {
var aPos = oTable.fnGetPosition(this);
oTable.fnUpdate(sValue, aPos[0], aPos[2]);
},
"submitdata": function (value, settings) {
return {
"column": oTable.fnGetPosition(this)[2],
"row_info": oTable.fnGetData(oTable.fnGetPosition(this)[0]).toString()
};
},
"select": true,
"height": "14px",
"onblur": "submit"
});
});
[/code]
Also note that I've changed the fnUpdate third parameter to use aPos[2], which is the column index, regardless of column visibility - since this is what fnUpdate expects.

Allan

Ebbs

Thanks Allan, it works almost perfectly now :)

One more question though. I have ""select": true" enabled. When I move from one cell to the other, the new cell's text is highlighted, but not immediately editable - I first have to click in the textbox to edit.

How can I set it up so as to have it immediately editable? (As in click and type)

Ebbs

Hi Allan,

I have some more info on my previous post and it still seems to have something to do with the "onblur": "submit" issue I had earlier.

I had to show my boss what I have done so far and he took over from me, clicking away like mad on all the available cells. The results were cells that stayed open with the last one that was clicked ready to be edited as soon as a key on the keyboard was pressed.

I tried this on various browsers and the results were all the same.

It seems like the cells aren't properly closing before the next one is being made ready to be edited.

Is this an issue that you guys might be addressing in v1.8

allan

Hi Ebbs,

Regarding your first post from the two above, looking at the source code for jEditable, I'm not really sure how that would be done I'm afraid. There is an 'onedit' hook, which you might be able to bind to and use a setTimeout to focus on the element, but I think that might be a question for the jEditable folks.

Regarding your second post:

> Is this an issue that you guys might be addressing in v1.8

I'm afraid that this cannot be fixed in DataTables, and therefore there will be no fix for it in 1.8. The issue you describe is a function of the way the jEditable plug-in for jQuery ( http://www.appelsiini.net/projects/jeditable ) works. jEditable is not part of the DataTables project and I have no ability to control it's direction, so this is something that would need to be taken up with the jEditable author. It sounds like an architectural decision that was made to do it that way, but I'm sorry to say that I have no idea why!

Regards,
Allan