How to dynamically add Edit button to grid for editing row using the jqGrid formedit

Goal:

Dynamically add an Edit button to an empty column that will NOT trigger an inline edit but rather a jqGrid formedit for the selected row using the modal dialog option.

Problem:

All examples in the Demo version include editing inline and adding buttons to a column that only does an inline edit and the Demo version's getRowdata does not perform as expected. I tried it an could not get it working and the getRowData did not work as specified.

Solution:

gridComplete: function() {
var rows = $(item).jqGrid('getRowData');
for (var i = 0; i < rows[0].rows.length; i++) {
var row = rows[0].rows[i];
var idx = row.id;
if (!$(row).hasClass('jqgrow') && !$(row).hasClass('alt'))
continue;
var be = "";
$(item).setRowData(idx, { act: be });
$('#editAddress' + idx).click(function() {
$(item).editGridRow($(this).parent().parent('tr').attr('id'));
});
}
},

item = that is a variable that contains the id of my grid.

This is for editing an address so change the "editAddress" id prefix for your needs or create a generic function that will handle all of this:

gridComplete: function() {
SetupJqGridEditDeleteButtons(item);
},

function SetupJqGridEditDeleteButtons(item) {
var rows = $(item).jqGrid('getRowData');
for (var i = 0; i < rows[0].rows.length; i++) {
var row = rows[0].rows[i];
var idx = row.id;
if (!$(row).hasClass('jqgrow') && !$(row).hasClass('alt'))
continue;
var be = "";
$(item).setRowData(idx, { act: be });
$('#editItem' + idx).click(function() {
$(item).editGridRow($(this).parent().parent('tr').attr('id'));
});
}
}

TDD - Red-Light-Green_Light:: A critical view

Subject: The concept of red-light-green-light for TDD/BDD style testing has been around since the dawn of time (well almost). Having written thousands of tests using this approach I find myself questioning the validity of the principle

The issue:

False positive or a valid test strategy that can be trusted?

A critical view:

I agree that the red-green-light concept has some validity, but who has ever written 2000 tests for a system that goes through a ton of chnages due to the organic nature fo the application and does not have to change, delete or restructure their existing tests? If you asnwer to the latter question is" "Yes I had a situation(s) where I had to refactor my code and it caused me to have to rewrite/change/delete my existing tests", read on, else press CTRL+ALT+Del :-)

Once a test has been written, failed the test (red light), and then you comlpete your code and now get the green light for the last test, the test for that functionality is now in green light mode. It can never return to red light again as long as the test exists, even if the test itself is not changed, and only the code it tests is changed to fail the test. Why you ask? because the reason for the initial red-light when you created the test is not guaranteed to have triggered the initial red-light result for the same reasons it is now failing after a code change has been made.

Furthermore, when the same test is changed to compile correctly in case of a compile-breaking code change, the green-light once again has been invalidated. Why? Because there is no guarantee that the test code fix is in the same green-light state as it was when it first ran successfully.

To make matters worse, if you fix a compile-breaking test without going through the red-light-green-light test process, your test fix is essentially useless and very dangerous as it now provides you with a false-positive at best. Thinking your code has passed all tests and that it works correctly is far worse than not having any tests at all, well at least for that part of the system that the test-code represents.

What to do?

My recommendation is to delete the tests affected, and re-create them from scratch. I have to agree. Hard to do and justify if it has a significant impact on project deadlines.

What do you think?