The PagingMethod property enables you to specify how paging requests are handled. The default setting is PostBack, which posts each page request back to the server.
CallBack paging uses the ASP.NET script callback feature to provide page navigation without posting the whole page back to the server. The XML data for the next requested page is downloaded as an XML string returned to the callback. A JavaScript function on the client collects the data and invokes the client-side XSLT processor to transform the data using the XSLT stylesheet that was downloaded and cached on the first request. The next page of data is displayed on demand. If you set the PagingMethod property to CallBack, you do not need to write server-side code and client-side JavaScript to take advantage of the script callback feature.
The PagingMethod property affects all paging actions, including DataWindow button actions that cause paging, client paging script methods, and integrated page navigationbar paging actions, but also all other DataWindow button actions and client methods such as Sort and Retrieve. When PagingMethod is set to Callback, all these actions are executed using script callbacks.
For the XML RenderFormat, if the DataWindow layout is inconsistent from page to page, or it does not contain a complete first page of data, the generated XSLT stylesheet is not reusable, and therefore cannot be cached by the browser. When this occurs, the Callback PagingMethod defers to PostBack until a stylesheet that can be reused and therefore cached in the browser can be generated.
Client-side paging uses an XML document stored in the browser’s memory as a client-side data cache of all the DataWindow’s rows. It retrieves the entire XML result set and uses XSLT re-transformation of the cached stylesheet to perform paging on the client. This allows other DataWindow actions to be performed entirely on the client. When PagingMethod is set to XmlClientSide, the InsertRow, AppendRow, and DeleteRow actions execute entirely on the client with no postback or callback to the server.
Computed fields not refreshed
No computed fields dependent on the RowCount method
get refreshed as the user is changing the current row count as a
result of the InsertRow, AppendRow, and DeleteRow actions.
This is because the underlying expressions are evaluated and generated
on the server as static values. They are reevaluated only when
an action is performed that does involve a postback, such as an update.
An ASP.NET page hosting a WebDataWindowControl configured for postback paging (or even callback paging) places more load on the Web server and can only page as quickly as the connection between client and server allows. A similar ASP.NET page hosting a WebDataWindowControl configured for client-side paging by contrast takes slightly longer to load on first request due to the fact that it is pulling down all of the XML records rather than just one page worth. But once loaded, subsequent paging requests take place entirely on the client and paging is not dependent on the connection speed.
Crosstab, Group, and Label DataWindows cannot be rendered correctly using the client-side paging method because their data presentation is not consistent from page to page. The client-cached XSLT style sheet cannot be reused. For the same reason, client-side paging cannot handle a DataWindow with a summary band on the last page. Client-side paging is available only for the Xml RenderFormat and in button actions and client JavaScript paging methods of the Web DataWindow client control. It is not supported with the integrated page navigation bar.
Call SetTransaction if you change the DataWindowObject
property
With the XmlClientSide PagingMethod, if you change the DataWindowObject property
of the WebDataWindowControl from its original value during a server lifecycle,
without calling Retrieve, you must at least call SetTransaction during that
same server lifecycle.
