There are many implementations available in the ASP.NET framework to display tabular data. Most of them send the content of the table to the client as a part of the page including all the other parts of the page. If it comes to mass data situations the implementations offer a mechanism to navigate through pages containing a smaller set of the records and sending the whole page again and again.
Here comes another approach that offers paging and scrolling even with huge datasets without refreshing the page that uses AJAX calls to a WebService to fetch the data.
In fact it's a 3 steps approach:
- When the page loads an empty table that acts as the template is downloaded to the client. No data integration is needed for this pahse to finish.
- Then a query is started by passing some parameters to the WebService that selects all the rows that should be displayed and returns a unique ID for each row.
- Then every row that is visible is fetched from the server using another WebService call that returns a XML document for each row.
The amount of data that is transferred has some overhead in the case of the first page that is displayed but if you scroll down to the next page by using the scrollbars or the page navigation buttons, only the new row data is fetched from the server - far less than a whole page refresh. It gets better when you scroll back to a region or page that was already displayed because the data is already on the client and can be displayed without requesting the server at all.
Also when you request another set of records by using another sort criteria all the rows that are already known on the client can they can be displayed without fetching them again from the server.
As you can imagine, using this approach it is possible to send huge tables to a client without the need to send all record data immediately.
Give it a try and check out the sample implementation at: http://www.mathertel.de/AjaxEngine/S03_AJAXControls/TableData.aspx.
First select some data using one of the 3 Select buttons. You can now page through the recordset or (by favorite) press the all-button and scroll through the table. You can see the deferred loading of the table rows.
The implementation consists of a WebService, 2 Web Controls and the AJAX Engine that does the asynchronous communication and the caching.
The DataTablePager is the client side controller of the MVC pattern and is an AJAX Control that implements the AJAX action for retrieving the dataset on the client side.
There are some methods available that can be used by additional buttons to load a specific view or to clear the actual data.
Buttons can use these functions to select rows by supplying a filter and a sorting criteria.
The events that are triggered by scrolling the table also use methods of this control to fetch data from the server.
The DataTablePager is the client side view of the MVC pattern and is responsible for dynamically building up the table that displays the record data fetched from the server formatted by the format given by the template row.
When the page load the template gets saved and when new row data must be shown this template is copied for every row that should be displayed.
Right now there is only a very simple template processing functionality implemented that can only display columns as simple text and the template is constructed on the server by interpreting the cols attribute of the datatable tag.
Every time a row gets visible a fetching the data is initiated by calling the DataTablePager Control's FetchRow Method.
When data comes back from the server the AJAX Action will call the DataTable Control's FillRow method to fill up the corresponding row with the record data.
The TableData WebService
The WebService that is used by the AJAX Actions of the DataTablePager Control is the server side model of the implementation. This WebService must implement the methods defined by the ITableData interface.
To bind all 3 elements together only some lines of coding are needed and the sample page itself, containing the controls and the WebService’s proxy, has only some specific attributes that must be set. – Have a look.
I see still some optimization potential in reducing the number of call to the server by bundling the records that got visible together into a single WebService call. – Stay connected.