2.8 Configuring cascading selection

In this section we will show you how to configure cascading selection for enumeration properties, where a list of possible values for one property depends on the selected value in another property. This also needs to be done in the custom code for a data object, but Xomega Framework’s support makes it extremely easy.

We will make the list of sales territories on the SalesOrderCriteria cascade off of the selected global region (territory group), and the list of sales persons cascade off of the selected sales territory. Let's open the SalesOrderCriteriaCustomized class that we generated in the previous section, and add the following code to its OnInitialized() method.

As you see, Xomega Framework allows us to do it in just a few lines. Instead of hardcoding names of enumeration attributes that are used for cascading, such as “group” or “territory id”, we were able to specify them using constants, conveniently generated for us by a Xomega generator based on those additional parameters that are returned by our dynamic enumerations.

You can also configure the behavior of cascading selection with regards to nulls in the attributes of the possible values or in the cascading property. By default, salespersons not assigned to any territory would be shown only when you don’t select any territory, and it shows all salespersons, but we configured it to always show such salespersons regardless of the currently selected territory. Finally, we configured the semicolon to be a separator between salespersons when multiple salespersons are displayed in the applied criteria summary. This is to avoid confusion, because the default list separator comma is already used to separate the last name from the first name.

ASP.NET Web Forms specific configuration. The application needs to update the cascading list of values as soon as the value it depends on is changed, which happens automatically in Blazor applications. However, in the classic ASP.NET Web Forms applications, this requires the AutoPostBack attribute to be set on the controls for the global region and the territory criteria, so that the changes in their values could trigger updates of their dependent lists. This can be done in the custom code for the generated views, but Xomega model provides an easier way for that. All you have to do is to set the is-trigger attribute on the corresponding fields in the data object definition as follows.

Given that this change in the model only affects the ASP.NET views, we can regenerate just those views to make it faster, instead of building the entire model project, which would run all generators.

Let’s run the application now, and try changing the global region and the sales territory.

As you change the global region, you will see that the list of sales territories will be updated for that region only. Similarly, once you select a sales territory, the Sales Person selection will be narrowed down to that territory only, and also to salespersons without any territories. From the screenshot, you can see that there are only four such salespersons for the Northeast territory. If you select several salespersons and run the search, you’ll see that their names are separated with a semicolon in the criteria summary panel.

Next: 2.9 Adding custom UI validations >