Custom Binding Limitations
- 5 minutes to read
In custom binding mode, the MVC GridView does not have simultaneous access to the bound data in its entirety. This imposes certain limitations on the grid features available in regular binding mode.
See the list below for information on features that have limitations in custom binding mode.
The grid’s built-in facilities for custom data processing (such as custom sorting, grouping and summarization) are not in effect.
Unlike in standard binding mode (in which data is processed automatically), you are responsible for retrieving the required portion of data from a data source (Model) using code and passing this data to the grid. The grid does not have access to all of the data in your Model. Although the grid includes built-in features that allow you to control custom data processing in standard binding mode, these features are not in effect in custom binding, because they require the grid to access all data rows in the Model.
As a result, custom binding mode places a limit on the following data processing operations.
- Custom sorting using GridViewSettings.CustomColumnSort is not supported.
- ClearSorting toolbar command is not supported.
- Group modes defined using a column’s GridViewDataColumnSettings.GroupInterval property are not supported.
- Custom grouping with GridViewSettings.CustomColumnSort and GridViewSettings.CustomColumnGroup is not supported.
- Custom summary calculation implemented using GridViewSettings.CustomSummaryCalculate is not supported.
- Sorting groups by summary values by the GridViewSettings.GroupSummarySortInfo property and ASPxGroupSummarySortInfo objects is not supported.
Since in custom binding mode, you control the logic of selecting and processing the model data, implement similar custom data processing scenarios in your custom code if your application logic requires it. You can do this when populating the grid view model at the Model level.
Data binding notifications are not supported.
The GridSettingsBase.DataBinding and GridSettingsBase.DataBound events are not raised in custom binding mode, since you provide data to the grid manually in the Controller.
Exporting is not supported.
By design, the entire data source is required to perform an automatic export operation. It is not possible to export only a portion of the data - the grid’s view model. You can find more information about this issue in the Q474597 ticket.
Modes of the built-in SelectAll check box defined by the GridViewCommandColumn.SelectAllCheckboxMode property have the following limitations:
The Select all rows mode (on all grid pages) specified by the GridViewSelectAllCheckBoxMode.AllPages value is not supported.
The grid can process row selection changes only on the current page. It is not possible to select rows on other grid pages, since the grid is aware of only a portion of data provided by the grid’s view model and can work only with this portion. You can find more information about this issue in the T153324 ticket.
- The Select all rows mode (on a current grid page) specified by the GridViewSelectAllCheckBoxMode.Page value is supported, however, the check box state might incorrectly reflect the selection made in the current grid page if the page contains collapsed groups. This is because the grid can process row selection changes only for the visible data rows.
- Endless paging defined by the GridViewSettings.SettingsPager.Mode (ASPxGridViewPagerSettings.Mode) set to GridViewPagerMode.EndlessPaging is not supported.
- The Group expanded state cannot be obtained in the GridViewGroupInfo class.
Automatic application of saved cookies that are defined by the GridViewSettings.SettingsCookies sub-property settings and contain the current grid state (such as column position, width, filtering, sorting and paging) are not supported.
In the Support Center, there is a request for the implementation of this functionality. To receive updates on our progress, you can track the S170547 ticket.
Currently, it is necessary to apply the states saved in cookies manually. You can get a cookie from a request, parse it and pass data to GridViewModel to apply the state to the corresponding entities. You can also find additional information on this issue in the following tickets: Q454790 and Q553684.
Layout persistence implemented with GridSettingsBase.ClientLayout is partially supported using a workaround.
The current workaround to loading the saved client layout data requires that you send an extra callback to the server - by calling the client PerformCallback (MVCxClientGridView.PerformCallback) method with an empty parameter in the grid’s Init (ASPxClientControlBase.Init) client event handler. This makes client layout data available in the Controller (using GridViewModel, which maintains the grid’s state) and passes the grid state to custom binding delegate methods as the GridViewCustomBindingArgsBase.State argument.
Refer to the Q531390 ticket for more details on this workaround.
- Unbound Columns populated using the GridViewSettings.CustomUnboundColumnData event or GridViewDataColumn.UnboundExpression property are not supported. To display custom data, implement custom data fields with the required calculation logic at the data model level.
- Single item selection is not in effect in custom data binding mode.
- Values of non key fields cannot be accessed and returned in custom data binding mode. Only values of the key field(s) are accessible. So, specify only key field name(s) in calls to methods returning values of selected rows.
- Customization Dialog‘s actions (filtering, sorting, paging) are not supported in custom data binding mode.
Conditional formatting is not supported.
Applying the conditional formatting rules contained within the GridViewSettings.FormatConditions collection requires accessing all data rows in the Model.
- The MVC GridView cannot recalculate summary values on the client in the custom data binding mode.