A special feature of the system must be pointed out urgently and also in detail. If an object is to be displayed in the user interface (e.g. in the context of displaying a reference), the system always uses a property with the technical identifier "name" of the type string. Instances of an object type that does not have such a property cannot be displayed in a meaningful way. In the chapter Add new option product we will create such a property when defining the object type "product". After that, we can refer to the products directly in the instance editor of the "Ticket". The products are also offered as a selection field in the first form.

However, there is no compulsion to model a property "name" with. If you can do without displaying an object by reference in the context of an app, you don't necessarily need it. But you should look beyond an isolated app and think company-wide: Even if I don't implement references today, it may be that tomorrow I want to display exactly this reference as part of another application development. That's why it's a good idea to always model the "name" property.

Although many object types will have a "name" attribute that fits the sense, it can happen, especially in interaction with legacy applications, that no directly fitting property can be found (e.g. when pure numbers are displayed). In this case, you can also implement the "name" property as a computed attribute of type string.

As an example, let's consider our object type "ticket". First, we re-sort the columns in the display window so that the "number" property, which Ticket inherits from the process instance, is at the top:

Ticket was initially modeled without the "name" property. If we look at this object type in the instance browser, we find the following picture:

It seems reasonable to show the user a concatenation of the two attributes "number" (inherited from the parent class "process instance") and "ticket title" in selection fields. Since this is a calculated property, a calculation rule must be defined and created. This is done as part of the attribute definition under "Customizations, storage rule".

We define the attribute "name" as follows:

Under the Storage rule option we enter the following code: x->$x.get(`MyEntities:Ticket#executionNumber`)+' - '+$x.get(`MyEntities:Ticket#ticketTitle`)

The calculation of the attribute follows the same rules as described in TopLogic script. In addition, we now concatenate two string expressions using the + sign and enclose another constant (the - sign) in quotation marks.

In the instance editor, we now see the new, calculated Display Name column:

This field could now be used instead of the ticket title from the 2nd form onwards, for example, as using the number now actually makes the tickets unique, which is not always the case with a plain text title.

For information on the "name" attribute, see also: https://dev.top-logic.com/documentation/servlet/LayoutServlet?page=Attributes&uuid=d36fecb2-4542-4692-ac30-86fa631e580a