When Infragistics WebDataGrid perform AJAX operations such as sorting and paging – it sends grid data directly to page’s DOM. But it also allows you to send your own custom data via server-side GridResponse object and its client-side counterpart. This feature allows you to establish effective link between server and client to perform custom operations otherwise available only during full postback or partial postback via update panel. There’re multiple cases where this can be used, let’s take a look at 3 most common:

• Updating a related control with server-side generated data
• Running a server-side generated JavaScript
• Handling server-side errors, for example Session timeout

GridResponse object has Tag property and Message property. We will use Tag to set command type and Message to set actual data. Server-side code will set these properties and client will read and act upon them. GridResponse also has AdditionalProperties property which is a generic collection of objects and can be used to send additional information to the client, but it’s not used in this exercise.

First lets establish some framework. I am a big fan of strongly named constants – they prevent confusion and make code maintenance a lot easer later on. So server-side let’s create Enum with our 3 response types:

'''<summary>Types of response sent by Grid back to client via AJAX calls</summary>
Public Enum GRID_RESPONSE_TAGS
   UPDATE_CONTROL = 1111
   EXECUTE_SCRIPT = 2222
   SESSION_TIMEOUT = 8888
End Enum

Also let’s create its client-side counter-part in JavaScript:

// Types of response sent by Grid from server via AJAX calls
var GRID_RESPONSE_TAGS = new Object();

GRID_RESPONSE_TAGS.UPDATE_CONTROL = '1111';
GRID_RESPONSE_TAGS.EXECUTE_SCRIPT = '2222';
GRID_RESPONSE_TAGS.SESSION_TIMEOUT = '8888';

This done, let’s move on to our tasks.

Updating a related control with server-side generated data. Let’s say when you’re paging thru the grid a DIV control needs to show some server-generated info related to current page. First, server-side lets collect that info:

Protected Sub xMyGrid_PageIndexChanged(ByVal sender As Object, _
   ByVal e As GridControls.PagingEventArgs) Handles xMyGrid.PageIndexChanged

   xMyGrid.GridResponse.Tag = GRID_RESPONSE_TAGS.UPDATE_CONTROL
   xMyGrid.GridResponse.Message = GetRelatedInfoForDiv(xMyGrid)

End Sub

Here we assigning “update control” task type to GridResponse‘s Tag property and some HTML generated by GetRelatedInfoForDiv function to Message property. On client we receive this info in grids’ Grid_AJAXResponse event handler:

function xMyGrid_Grid_AJAXResponse(sender, eventArgs) {

   switch (eventArgs.get_gridResponseObject().Tag) {
      case GRID_RESPONSE_TAGS.UPDATE_CONTROL:
         $get('xMyDiv').innerHTML = eventArgs.get_gridResponseObject().Message;
         break;
   }

}

Here we check Tag property of client-side GridResponse object and if it’s “update control” we read HTML from Message and load it into DIV’s innerHTML. Easy.

Running a server-side generated JavaScript This is very similar to previous task. Let’s say when grid is sorted you need to run some server-side generated JavaScript. First, let’ set it up server-side:

Protected Sub xMyGrid_ColumnSorted(ByVal sender As Object, ByVal _
   e As GridControls.SortingEventArgs) Handles xMyGrid.ColumnSorted

   xMyGrid.GridResponse.Tag = GRID_RESPONSE_TAGS.EXECUTE_SCRIPT
   xMyGrid.GridResponse.Message = "alert('Hello from server side!');"

End Sub

Also let’s modify Grid_AjaxResponse event handler on the client:

function xMyGrid_Grid_AJAXResponse(sender, eventArgs) {

   switch (eventArgs.get_gridResponseObject().Tag) {
      case GRID_RESPONSE_TAGS.UPDATE_CONTROL:
         $get('xMyDiv').innerHTML = eventArgs.get_gridResponseObject().Message;
         break;
      case GRID_RESPONSE_TAGS.EXECUTE_SCRIPT:
         eval(eventArgs.get_gridResponseObject().Message);
         break;
   }

}

We added lines 7, 8 and 9. This case block checks whether Tag hold command type of “execute script” and if so – simple evaluate data is Message property as a JavaScript block.

Handling Session timeout. Last but not least. Server-side part can be set in Page_Load event:

Protected Sub Page_Load(ByVal sender As Object, _
   ByVal e As System.EventArgs) Handles Me.Load

        If Session("Variable_that_always_there") Is Nothing Then
            xMyGrid.GridResponse.Tag = GRID_RESPONSE_TAGS.SESSION_TIMEOUT
            Exit Sub
        End If

End Sub

This time we set just “command type”, no need to send any data, the client will handle just the type:

function xMyGrid_Grid_AJAXResponse(sender, eventArgs) {

   switch (eventArgs.get_gridResponseObject().Tag) {
      case GRID_RESPONSE_TAGS.UPDATE_CONTROL:
         $get('xMyDiv').innerHTML = eventArgs.get_gridResponseObject().Message;
         break;
      case GRID_RESPONSE_TAGS.EXECUTE_SCRIPT:
         eval(eventArgs.get_gridResponseObject().Message);
         break;
      case GRID_RESPONSE_TAGS.SESSION_TIMEOUT:
         location.href = 'my_login_page.aspx'; //redirecting to login
         window.alert = function() { }; // and suppressing all possible error messages
         break;
   }

}

Lines 11, 12 and 13 check for “session timeout” command type and it it is – redirect user to login page. Note Line 12 – it suppresses built-in alert function preventing possible messages that grid would otherwise generate because of session timeout. Those messages would confuse non-technical user and since we’re redirecting to a new page anyway, it’s OK to temporarily destroy the alert.