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
|Every object must have either a text attribute or a relation, where the target object can be represented as text, with name = true.
|Shows, how central the attribute should appear in the UI.
|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.
|Defines, who can edit the object.