Action Types and Passed Parameters
- 5 minutes to read
When you use the CardView in custom binding mode, provide the extension with data manually upon each request. The CardView sends requests to the server using callbacks (see Using Callbacks). Each callback type should be associated with a handling Action in a Controller. You can define the callback routing logic by using specific properties exposed by the CardView. This topic provides information about the available callback routing properties of the CardView, and specifies which particular Actions should be handled in custom binding mode.
Callback Routing Properties
In general, the CardView has the following properties that allow you to define callback routing logic for different actions. The table below describes which properties and corresponding Actions relate to the custom binding implementation of the CardView.
Name | Description | Required for custom data binding? | Action accepts binding parameter(s)? |
---|---|---|---|
Specifies the names of the Controller and the Action that handle standard CardView callbacks. The CardView automatically updates (re-renders) itself after each standard callback, so it is necessary to provide the extension with data during standard callback processing. Handling the specified Action is essential to implement the CardView’s custom data binding; no specific custom binding parameter is automatically passed to the Action. | Yes | No | |
Specifies the names of Controllers and Actions that handle callbacks related to CardView data operations such as paging, sorting and filtering. Handling all or some of these data operations is essential to implement the CardView’s custom data binding. Operation-specific parameters are automatically passed to the specified Action(s). | Yes | Yes | |
Specifies the names of the Controller and the Action that handle custom callbacks initiated by the client MVCxClientCardView.PerformCallback method. The CardView automatically updates (re-renders) itself after this custom callback, so it is necessary to provide the extension with data during callback processing. If the client MVCxClientCardView.PerformCallback method is used in your project, it is essential to handle the specified Action to implement the CardView’s custom data binding. The specified Action only accepts a parameter passed with the client MVCxClientCardView.PerformCallback method. No specific custom binding parameter is automatically passed to the Action. | Only if the client MVCxClientCardView.PerformCallback method is manually called on the client side. | No | |
Specifies the names of the Controller and the Action that handle custom data callbacks initiated by the client MVCxClientCardView.GetValuesOnCustomCallback method. The CardView does not automatically update (re-render) itself after this custom data callback, so it is not necessary to provide the extension with data during callback processing. Handling the specified Action is not required to implement the CardView’s custom data binding. No specific custom binding parameter is automatically passed to the Action. | No | No |
Action Types and Parameters that are Specific to Custom Binding
The CardViewSettings.CustomBindingRouteValuesCollection property allows you to assign particular handling Actions for three data operations – paging, sorting and filtering — which are specifically exposed to be handled in a custom manner to implement the custom data binding of the CardView. These operations are identified by the values of the CardViewOperationType enumeration. The table below lists the available data operation types, and provides additional information on how to assign and declare Actions that handle these operations.
Operation Type | Description | Syntax to Assign and Declare Action | Parameters Passed to Action |
---|---|---|---|
An operation of this type is initiated if the paging-related state of the CardView is changed. For instance, an end-user moves to another CardView page (by clicking a pager navigation button or page number button) or changes the CardView’s page size (using the pager’s page size combo box). | Partial View Code:
Controller Code:
|
| |
An operation of this type is initiated if the sorting-related state of the CardView is changed. For instance, an end-user sorts a column by clicking its Column Header in the Customization Window. Note that a regular click on a column header clears the sort settings on other columns. To preserve the existing sort settings of other columns, an end-user can hold the SHIFT key down while clicking. This can be useful when sorting against multiple columns. | Partial View Code:
Controller Code:
|
| |
An operation of this type is initiated if the filtering-related state of the CardView is changed. An end-user can apply a filter condition to a single column - by using a column’s header filter dropdown or by typing in the search panel. Or, an end-user can filter multiple columns at once - by using the built-in filter builder. | Partial View Code:
Controller Code:
|
|
Note: When implementing the CardView’s custom data binding, the DevExpressEditorsBinder must be used instead of the default model binder to correctly transfer values from DevExpress editors back to the corresponding data model fields. See the Binding to Model section in the Binding Data Editors to Data topic for more details on how to specify the DevExpressEditorsBinder as a model binder.