Naming classes, windows and controls

So far, ODABA GUI resources do not support name spaces on global level, i.e. one cannot arrange GUI classes in different projects or name spaces. Hence, class names have not to be unique, only, but have to be defined in global name space. Since persistent GUI classes, i.e. GUI classes inheriting from persistent data type definitions, get the same name as the complex data type they are based on, persistent data types intended to be referred to in GUI applications should also be defined in global namespace, until ODABA GUI is supporting namespaces, too. In particular, this means, that complex data types intended to be used in GUI applications, should not contain local data type definitions.

Windows and controls are defined in the local namespace of the complex data type the GUI class is based on, i.e. names for windows and controls have to be unique within the context of the GUI class, only. Referring to a window or control, always requires scoped names, or class name and window or control name.

Typically, for referring to controls a two level assignment is necessary, which includes GUI class selection first and and selecting control in the selected GUI class afterward.

Fields and regions in control definitions use physical referenced (by identity). Thus, one may rename classes or controls without destroying link information. GUI action definitions, however, use logical references just containing names for classes and windows. Those are not maintained when changing class or window names and have to be updated explicitly by the developer.