In 8.х platform there is quite a large number of modules. And in order not to get lost in all this variety, as well as to determine in which of them some code should be located, it is required to clearly understand the purpose of each of them.

What are the modules and what are they intended for? The software code is located in the module. Moreover, it should be noted that, in contrast to the 7.7 platform, where the code could be located both in the form items and in the template table cells, in the 8.х platform any code line must be located in some module. Usually, the module consists of three sections – the section of variable description, the section of procedure and function description and the section of main program. This structure is typical for almost all the platform modules with some exceptions. In some modules there is not section of variable description and the section of main program. For example, the Session module and any General module.
The context of module execution, in general, is divided into the client and server. In addition, some modules can be compiled both in the client and server side. And other – exclusively on the server or client side. So:

Application module

The module is designed to catch the moments of application launch (configuration loading) and completion of its work. And it is possible to place the check procedures in the corresponding events. For example, at the beginning of application work, to update any referenced configuration data, at the work completion, to take interest whether it is worth to close it, maybe the working day is not over yet. In addition, the events are intercepted here from the external hardware, for example, from the trade and fiscal one. In should be noted that the application module intercepts the described events only in case of interactive startup. That is, when the program window is created by itself. It does not happen, if the application is launched in the mode of com-connection.
In the 8.2 platform two different application modules exist. These are the module of General application and the module of Manageable application. They trigger on startup of different clients. Thus, the module of manageable application triggers on startup of web-client, thin client and thick client in the mode of manageable application. And the module of general application triggers on startup of thick client in the mode of general application.
In the application module all the sections can be placed – description of variables, procedures and functions as well as description of main program. The application module is compiled on the client side, so it significantly limits us in the availability of many data types. It is possible to expand the application module context with help of the methods of general modules for which the property «Server call» is set. All the variables and methods marked as the export ones are available in any application module which operates on the client side. However, no matter how tempting it is, it is not recommended to place here a large number of methods. The more code is here, the more compile time and, therefore, the application startup time which very annoys the users.
As it was mentioned before, the application module processes the events of application startup and shutdown. To process each of these events on the application module, there is a couple of handlers Before… and When… The difference between them is that when the code is executed in the handler Before…, the action has not yet occurred and we can deny its execution. To do this, the parameter Denial is designed. In the handlers When.. the action has already occurred and we cannot deny the application startup or its exit.

External connection module

The module purpose is similar to the purpose of application module. It processes the points of application startup and termination. The external connection module triggers when the application is running in the mode of com-connection. The external connection process itself is a non-interactive process. In this mode the software work with information base is performed and there is no opening of the application windows which imposes the certain restrictions on the use of methods designed for interactive work. It is impossible in this mode to use the calls of dialog forms, warning messages, etc. They simply will not trigger.
As in the application nodule, the sections of variable and method description and the section of main program are available here. It is possible also to declare the export variables and methods. The difference is that in the mode of com-connection all the work with information base is performed on the server side, so the external connection module is compiled exclusively on the server. Thereafter, the export variables and methods of client modules are not available here.

Session module

This is a highly tailored module designed exclusively to initialize the session parameters. Why was it required to create a separated module for this? This is due to the fact that the initialization process may require the execution of some code, and, in addition, the application can be launched under different clients (that leads to the execution of different application modules or the external connection module), but the initialization of session parameters must be performed in any startup mode. Therefore, an additional module was required which is executed in any application startup mode.
In the session module there is a single event «SettingSessionParameters» which is executed the first, even before the application module event BeforeSystemStartup. The section of variable declaration and the section of main program are not available here. Also, it is impossible to declare the export methods. The module is compiled on the server side.
It is no good to give into temptation that this module is executed in any application startup and to place here the code not related directly to the initialization of session parameters. This is due to the fact that the handler SettingSessionParameters can be called repeatedly during the system operation. For example, it happens in those cases when we refer to the uninitialized parameters. Although it is possible to catch the moment of first launch of this event (RequiredParameters has a type Undefined), however, it should be taken into account that this module is compiled in the privileged mode, i.e. it does not control the access rights. And the second point, we still cannot be one hundred percent sure that the system will launched. Suddenly, the application module will fail and we are trying to do some actions with database.

General modules

The modules are designer to describe some general algorithms to be called from other configuration modules. The general module does not contain the section of variable description and the section of main program. It is possible to declare here the export methods the availability context of which will be determined by the compilation flags. Due to the fact that the section of variable description is not available, it is not allowed to define the global variables in the general modules. To do this, it is required the functions of general modules with caching the returned values or the application module. It should be kept in mind that even if the property of general module reuse is set in value “On session time”, in this case, the life time of the cached values does not exceed 20 minutes from the moment of their last call.
General module behavior depends on the specified parameters (global or not, different compilation flags, whether the server call is available, etc.). We will not consider in this article all the possible settings as well as the behavioral features and pitfalls that occurs in case of unreasonable setting of the flags of properties. This is a topic for another article. Let’s focus on several moments that should guide definition of flags:

• A good rule will be to use the flag «Global» everywhere. This will reduce the application startup time as well as will improve the code readability (of course, if the general module has a quite meaningful name).
• It is not advisable to use more than one compilation flag. There are not so many methods to be executed in different contexts, and if such methods will be needed, it is possible to allocate for them a separate general module.
• The flag «Server call» makes sense only if the module is compiled «On server». Therefore, all the rest of the compilation flags should be unchecked to avoid different problems.
• If the module methods perform the mass data processing, reading and writing in the database, then, in order to accelerate the work, it is better to disable the control of access rights by setting the flag «Privileged». This mode is available only for the general modules compiled on the server.

Form module

It is designed to process the user actions, i.e. different events related to the data input and processing of their input correctness. The module of general form is compiled completely on the client. The module of manageable form is clearly delimited by execution context, therefore, all the variables and methods must have the compilation directive. If the directive is not explicitly specified, this variable or method will be compiled on the server side. The sections of variable and method description and the section of main program are available in the form module.

Object module

This module typical for many configuration objects and is designed, in general, to process the object events. For example, the events of object writing and deletion, event of document conduction, etc.
Some events of object module duplicate the form module events. For example, the events related to the writing. But it should be understood that the form module events will be executed exclusively in a particular object form. In general, these forms may be multiple. And the object module events will be called in any case, even at the moment of software work with the object. Therefore, if it is required to execute some code in all the cases, it is better to use for this the object module events.
The object module is compiled only on the server. It is possible to define in it the export variables and methods that will be available in other configuration modules. With these properties and methods, we can significantly extend the object functionality.

Object manager module

This module is available for many configuration objects. The main purpose of this module – redefinition of standard selection event which occurs at the moment of input by the string and extension of manager functionality. The module is compiled on the server side. It is possible to define in it the export properties and methods. The call of export manager methods does not require the creation of object itself.
To all of the above, it is possible to add a picture of some configuration modules and the ways of mutual calls of methods in the mode of manageable application. The arrow indicates the direction in which it is possible to refer in order to call the corresponding method. As it is seen from the diagram, the server context is completely closed. But there is an ability to refer to the server methods from the client context.
Reference designation on the diagram: Client GM – Client general module; Server GM – Server general module; FM Client – form module client procedures; FM Server – form module server procedures.