Optimizations or hints are needed for the kit to know the meaning of attributes/relations and to make the UI comfortable from the start.
E.g. a type of object with lots of instances, which need to be accessed often and conviently, like messages in an email app, is likely to be placed in a cental place, while rarely accessed information, like the username on a server, may be moved to some dialog.
If not noted otherwise, each end of a relationship is treated as an attribute of the respective object, i.e. all hints can be given for attributes and both ends of a relationship.
Optimizations may be changed by the user without the knowledge of the app.
Current hints types are:
Table 2-1. Hint types
| Name | Type | Meaning | Predefined values | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| name | boolean | Every object must have either a text attribute or a relation, where the target object can be represented as text, with name = true. |
| ||||||||
| importance | short int | Shows, how central the attribute should appear in the UI. |
| ||||||||
| multiplicity | short int | Only valid for cardinalities of relations. Shows, how many target items will usually appear, in contrast to how many can appear as shown in the model. |
| ||||||||
| protection | enum | Defines, who can edit the object. |
|