Craig Stuntz’s Weblog

This is the fifth post in a series on using jqGrid with ASP.NET MVC. Today, we’re going to begin examining the grid’s editing features by implementing deletes. If you’re new to the series, you might want to start at the beginning.

The delete feature of jqGrid is, oddly, almost entirely undocumented, even though there quite a few examples of different methods of editing, and inserts are documented, to a lesser extent. But it does exist; I just had to read the source code to figure out how it works.

JqGrid has three different methods of editing data. The cell edit feature allows the user to edit a single cell the grid at a time, and saves the data when the cell loses focus. The row edit feature works similarly, but does not save the data until the row loses focus. The form edit feature shows a modal dialog instead of editing the values inline. Of these three, the form edit feature is the only one which supports deletes. However, you can still use one of the other "modes" for editing, if you like. Just be aware that when you do a delete, you will be in the form edit code. Also, deletes won’t work if you change the grid’s configuration to disable the form edit feature.

In order to allow the user to delete a row, I need to:

• Add a delete button to the grid’s toolbar. I could, of course, use a custom button or something instead of the grid’s toolbar if I chose to do so.
• Specify a URL for the delete action
• Implement a delete action on the controller

I can accomplish the first two tasks by making a slight change to the JavaScript that configures the grid:

}).navGrid(pager, { edit: false, add: false, del: true, search: false }, {}, {}, {url: "Delete"});

I’ve highlighted the parts I’ve changed in boldface. Changing the "del" property to true turns on the toolbutton. The fifth argument is an object specifying options for the delete action, of which I have only specified the URL. This is important: The only places you can specify the URL for delete are in the arguments to the delGridRow method or in the toolbar’s configuration. There is not a "delete URL" property of the grid itself.

If you don’t specify a delete URL in this way, the grid will presume that you want to send delete requests to the URL you have specified for editing rows. There will be an "oper” value in the submitted form indicating that the request is a delete rather than an edit. But I prefer to use a separate URL for delete, because I think that fits more naturally in the ASP.NET MVC paradigm.

Now let’s write an action to handle the delete:

[AcceptVerbs(HttpVerbs.Post)]
public ActionResult Delete(int id)
{
    var repository = new Repository();
    var deleted = repository.Delete(id);
    if (!deleted)
    {
        Response.StatusCode = 500;
        return Content("Record not found.");
    }
    return Json(true);
}

Again, I’ll note that I’m using a mock repository for this demo so that you can compile and run the solution without needing to set up a database. Since the mock repository is based on IList, the Delete method of the repository returns a Boolean indicating whether or not the requested record was found, since that is how IList behaves. It would probably be more correct to return a partial view in the event of an error rather than specifying the contents directly, but error handling is a subject I hope to cover in more depth later on. For the time being, simply changing the StatusCode will tell the grid when something does not work.

If the delete was successful, I return "true." By default, the grid ignores returned data when the operation is successful. However, you can handle the grid’s afterSubmit event, which will be passed any data you do return. So what you choose to return, and what you do with it, is entirely up to you.

With all that in place, deletes work as expected. I’m not going to update the demo solution just yet, because I’ll be covering edits and inserts real soon now. But first I need to revisit formatting and explain more about LINQ".

Share This | Email this page to a friend