3.2 Handling read-only fields

If we look at the details screen generated for us by default, we will notice that all object fields there are editable. However, some fields are completely internal, and should not even be displayed to the user, such as the Row GUID highlighted in red below.

Other fields, such as the ones highlighted in yellow, are set internally by the system, and should be read-only on the screen. To address these issues, we will need to properly update the generated CRUD operations to specify which fields can be updated on the object.

We will start by updating the output parameters of the "read" operation for the "sales order" object. Since it is the first structure in the model that is added to the data object SalesOrderObject, and includes all properties of that data object, the order of its output parameters will drive the order of the fields on the screen, so we can use it to rearrange some fields on the screen as well. Let's remove the "rowguid" parameter, move the “sales order number” to be the first parameter, and move the “revision number” to go right before the “modified date”. We'll also override the type on the "order date" parameter to be just "date", without the time component. The following picture illustrates this setup.

Next, let’s remove the “rowguid” parameter from the input of the “create” operation, and move the other parameters, that are calculated during order creation, to the output of the “create” operation, as shown below.

Note that we also need to update the type of the “order date” parameter here to be “date”, so that it would be consistent with the type of this parameter in the “read” operation. In a similar manner, we will remove all those parameters (including “rowguid”) from the input of the “update” operation, and move the following two parameters to the output of the operation, since they are changed on each update.

As you update operations’ inputs and outputs, make sure to insert the config section with the xfk:add-to-object element in them as needed. This will allow the data object to set the input parameters from its properties when calling the operation, and to update its properties from the output parameters when handling the operation result.

The system may set the read-only parameters in different ways. For example, the Sales Order Number is just a computed field in the database, and the Revision Number is incremented by a database trigger. The Row GUID, Modified Date and Order Date, which would presumably be the order creation date, are not updated in the database, so we will add custom code in the Create method of the SalesOrderService to populate them as follows.

And similarly, we will add custom code in the Update method to set the modified date.

Let's build the model, and run the application to review the results. Here's what the Sales Order Details panel will look like.

Notice how our fields are displayed as read-only labels, and in the correct order now, while the Order Date is shown as just a date.

Next: 3.3 Grouping fields as child data objects >