Common module naming rules

This article describes the standards that apply to common module naming. All of the listed recommendations are mandatory unless noted otherwise.

1.1. Common modules are intended for implementation of procedures and functions that have something in common. As a rule, a common module contains procedures and functions belonging to a single subsystem (such as Sales or Purchases), or procedures and functions having similar functionality (such as string operations or general-purpose functionality).

1.2. Select one of the following four contexts for your common modules:

Common module type Naming example Server call Server External connection Client (ordinary application) Client (managed applicatuion)
1. Server CommonUse (or CommonUseServer)






2. Server, called from client CommonUseServerCall





3. Client CommonUseClient (or CommonUseGlobal)






4. Client/server CommonUseClientServer






2.1. Server common modules contain procedures and functions that cannot be called from the client code. They implement the internal server business logic of the application.
To ensure correct functioning of your configuration in external connection, ordinary, and managed modes, implement server procedures and functions in common modules with the following flags:

  • Server (clear the Server call check box)
  • Client (ordinary application)
  • External connection 

This ensures that calling server procedures and functions with parameters of mutable types (such as CatalogObject or DocumentObject) is available. Normally such procedures and functions include:

  • Event subscription handlers for catalogs, documents, and similar objects whose parameters include mutable values (objects)
  • Server procedures and functions whose parameters include objects from modules of catalogs, documents, and similar objects, as well as from modules that include event subscription handlers

Use the common metadata object naming rules for server common modules.
Examples: FileOperations, CommonUse

In some cases you can add the Server postfix to avoid naming conflicts with global context properties.
Examples: ScheduledJobsServer, FullTextSearchServer.

2.2. Server common modules called from client contain procedures and functions that can be called from the client code. They form the client programming interface of the applied solution server.
Implement such procedures and functions in modules with the following flag:

  • Server (select the Server call check box)

Use the common metadata object naming rules for server common modules that are called from server and add the ServerCall postfix.
Example: FileOperationsServerCall

Note that export procedures and functions implemented in such modules must hot have parameters of mutable types (such as CatalogObject or DocumentObject) because they cannot be passed to or from client code.

2.3. Client common modules describe the client business logic (the functionality that is only available on the client). They have the following flags:

  • Client (managed application)
  • Client (ordinary application)

The only exception is the scenario where client procedures and functions must be only available in the managed application mode (or ordinary application mode, or external connection mode). In this scenario you can use a different combination of these two flags.

Add the Client postfix to client common module names.
Examples: FileOperationsClient, CommonUseClient.

2.4. In rare cases creating common server modules with procedures and functions that have identical client and server contents is acceptable. Implement such procedures and functions in modules with the following flag:

  • Client (managed application)
  • Server (clear the Server call check box)
  • Client (ordinary application)
  • External connection

Add the ClientServer postfix to names of such common modules.
Examples: FileOperationsClientServer, CommonUseClientServer.

In general, we recommend that you do not define common modules that are intended for both the server and the client (managed application). We recommend that you implement the functionality available both on the client and on the server in different common modules (see paragraphs 2.1 and 2.3). Separating the server and the client logics improves the applied solution modularity, simplifies developer control over the client/server interaction, and reduces the risk of errors related to essential differences in the requirements to client and server code (such as minimizing the code executed on the client, differences in the object and type availability, and so on). Note that this inevitably increases the total number of modules in your configuration.

Form and command modules are considered a special case of mixed client and server modules, they are intended for implementing server and client logics in a single module.

3.1. Use the common metadata object naming rules for naming common modules. A common module name must be identical to the name of the subsystem or feature whose procedures and functions are implemented in the module. We recommend that you avoid  vague words, such as Procedures, Functions, Handlers, Module, or Functionality, except for rare cases when they add accuracy to the description of the module purpose.

We recommend that, in order to distinguish common modules of a single subsystem with different execution contexts, you name them using postfixes as described in paragraphs 2.1-2.4.

3.2. You can use additional postfixes to clarify the module purpose.

3.2.1. Add the Global postfix to global module names. In this case do not add the Client postfix.
Example: FileOperationsGlobal.

2.2. Add the FullRights postfix to names of modules executed in privileged mode (modules that have the Privileged flag).
Example: FileOperationsFullRights.

3.2.3.  Add the Cashed or ClientCashed postfix, respectively, to names of server or client modules with reusable return values (values that can be reused during a session).
Example: FileOperationsClientCached.

3.2.4. Add the Overridable or ClientOverridable postfix, respectively, to server and client modules of library configurations (configurations intended not for independent use but for development of other configurations). Such modules contain procedures and functions whose implementations can be modified.
Example: FileOperationsClientOverridable.

See also:

Add comment