3.8 Adding standard contextual selection

In this section we will use a similar technique to set up contextual selection for the credit card ID on the Payment tab, but we’ll use Xomega Framework support to minimize the custom code needed for standard cases. Instead of showing a text field to enter the ID of a stored credit card, we will display a dropdown list with a choice of credit cards for the current customer person, and the credit card details when one is selected.

First off, let's define some common credit card related types in the credit_card.xom file, and update the corresponding “credit card” object fields to use these types. We'll also change the base type for the "credit card" type to "integer enumeration", as displayed below.

Similar to what we did before, we will run the “Enumeration Read List” generator on the person_credit_card.xom file, and then we’ll update the generated "read list" operation to make the “business entity id” an input parameter and add it to the URI template of the REST method, return credit card fields using their types from the credit card object, and define a dynamic enumeration with the xfk:enum-cache element, as illustrated below.

Next, we will add a customized CreditCardPaymentObject data object in the sales_order.xom file, as well as a generic "credit card info" structure for this object to add fields to it, as shown below.

We will also configure our data object to make credit card non-key fields read-only, and to make the credit card ID a trigger with a proper label.

Next we will update both the "payment info" and "payment update" structures to push the credit card ID and the credit card approval code parameters down to a nested inline structure that is also tied to that data object.

We'll also need to add the CreditCardPaymentObject as a child of the SalesOrderPaymentObject using the same name "credit card", as we used in the above structure.

Since the list of person's credit cards depends on the selected customer, which is in a sibling child object on the sales order data object, we will implement the trigger in their common parent object SalesOrderObject, so we'll need to customize it.

Let's build the model project, and refactor our customer service code in the SalesOrderServiceExtended.cs to use the new nested structure in the GetPaymentInfo method as follows.

And similarly in the UpdatePayment like this.

Next we'll provide custom implementation in the PersonCreditCardService to read all the credit card parameters, where we will return the credit card name as the card type, and the last four digits of the card number, as follows.

Now, to display the credit card details when a credit card is selected on the screen, we’ll open the customized CreditCardPaymentObject in the Client.Common project, and add a credit card change listener, which will populate other properties from the credit card attributes. The expiration property will combine both expiration month and year, as shown below.

Finally, we’ll set up the local lookup cache loader for the credit card property in the SalesOrderObjectCustomized class, but instead of manually listening to the updates of the person ID property and then refreshing the cache loader and updating the credit card property, we’ll just call the SetCacheLoaderParameters method with the generated constant for the input parameter name and the source property, and Xomega Framework will handle all of the for us automatically. The following snippet illustrates this logic.

Let's run the application, and review our changes. The Payment tab should now look as shown below.

As you see, we're displaying a list of person's saved credit cards using the credit card type and the last four digits of the card number now, and show specific credit card details when one is selected from the list.

Next: 3.9 Using dynamic view titles >