Using subsystems





This article describes subsystem usage standards. All of the listed recommendations are optonal.

1.1. Subsystems are intended for solving the following methodical tasks:

  • Generate the command interface of the main application window, which provides an overview of the application functionality
  • Group metadata objects by functionality to streamline the development

In a simple scenario the configuration subsystem structure can satisfy both requirements.

For example, the Sales and Purchases sections, which represent command interface sections available to users, can also be used during the development for quick filtering in Designer mode metadata objects window, for moving objects to other configurations, for narrowing the search area when performing global configuration search, and so on.

Such subsystems should have the Include in command interface check box selected.

1.2. In general, a subsystem that logically groups a set of metadata objects might not have an exact match among the application sections. If this is the case, we recommend that you specify a separate subsystem hierarchy for logical grouping of metadata objects. These subsystems should not be included in the command interface (should have the Include in command interface check box cleared).

Examples:

  • The Products catalog logically belongs to the Lists subsystem but it is available in two command interface sections: Lists and Marketing.
  • The Administration command inteface section includes commands that open lists of objects logically related to various "functional" subsystems where customization by adiministrators is available.

1.3. We recommend that you include modules, sceduled jobs, constants, event subscriptions, and other objects that do not have visual presentations to "functional" subsystems only.


Comments
0
Add comment