The basic principle of programming a controlled form in 1C

The purpose of the article is to show the application of the Remote Facade and Data Transfer Object templates to the structuring of code, a managed form in the 1C 8.2 environment.

Introduction

Let's start with a brief description of the concept of “controlled form” and related concepts of the 1C platform. Platform experts can skip this section.

In 2008, a new version of the 1C: Enterprise 8.2 platform (hereinafter Managed Application) became available, which completely changes the entire layer of work with the interface. This includes the command interface, the forms, and the window system. At the same time, not only the user interface development model in the configuration is changing, but also a new architecture for the separation of functionality between the client application and the server is proposed.
The managed application supports the following types of clients:

• Thick client (normal and controlled startup mode)
• Thin client
• Web client

The managed application uses forms built on the new technology. They are called Managed Forms . To facilitate the transition, the old forms (so-called Normal forms) are also supported, but their functionality is not developed and they are available only in the launch mode of the thick client.
The main differences of the managed forms for the developer:

• Declarative, not “per pixel” structure description. The specific placement of elements is performed by the system automatically when the form is displayed.
• All the functionality of the form is described in the form of details and commands . Details are the data with which the form works, and commands are the actions performed.
• The form runs both on the server and on the client.
• In the context of the client, almost all application types are not available, and accordingly it is impossible to change the data in the infobase.
• For each method or form variable, a compilation directive must be specified, specifying the execution location (client or server) and access to the form context.

We list the compilation directives of the form methods:

• & Onclient
• &On server
• & AtServerEcontacts
• & On ClientServerWithoutContext

We illustrate the above. The screenshot shows an example of a managed form and its module in development mode. Find the declarative description, details, compilation directives, etc.

')
All further considerations will be about the right part of the illustration, about how to structure the module code and what principles will allow to implement effective client-server interaction.

Denote the problem

Several years have passed since the new version of the 1C platform has been actively used and a lot of solutions (configurations) have been released both by 1C and its numerous partners.
During this time, did the developers have a common understanding of the principles of client-server interaction when creating forms, and has the approach to the implementation of software modules changed in the new architectural realities?

Consider the structure of the code (form module) in several forms of the same typical configuration and try to find patterns.
By structure, we mean sections of code (most often these are blocks of comments) allocated by the developer for grouping methods and compilation directives for these methods.
Example 1:

    –   –   -           

Example 2:

Example 3:

Example 4:

         « » 

In essence, the structure of the code is missing, or, to put it mildly, it is similar to what was in Forms 8.1:

• Non-informative words "General, Service, Auxiliary."
• Timid attempts to separate client and server methods.
• Often the methods are grouped by the interface elements "Working with the tabular part Goods, Contact information".
• Arbitrary arrangement of methods and code groups. For example, event handlers may be in one form at the top, in the other at the bottom, in the third, they are not allocated at all, etc.
• And let's not forget that this is all within the same configuration.
• Yes, there are configurations in which the words "General, Service, Auxiliary" are always on the same places but ...

Why is the code structure needed?

• Simplify maintenance.
• Simplify learning.
• Fixing common / important / successful principles.
• ... your option

Why the existing development standard from 1C does not help?

Let's look at the principles recommended for writing a managed form published on ITS disks and in various “Developer’s Manuals ...”.

• Minimize the number of server calls.
• Maximum calculations on the server.
• Non-contextual server calls are faster than contextual calls.
• Program with respect to client-server interaction.
• etc.

These are slogans that are absolutely correct, but how to implement them? How to minimize the number of calls, what does programming in client-server mode mean?

Design patterns or the wisdom of generations

Client-server interaction has been used in various software technologies for decades. The answer to the questions indicated in the previous section has long been known and summarized in two basic principles.

• Remote Facade (hereinafter referred to as the Remote Access Interface)
• Data Transfer Object (further Data Transfer Object )

A word to Martin Fowler , his description of these principles:

• ... every object that is potentially intended for remote access should have an interface with a low degree of detail , which will minimize the number of calls necessary to perform a specific procedure. ... Instead of requesting an account and all its points separately, it is necessary to count and update all points of the account for one call. This affects the entire structure of the object. ... Remember: the remote access interface does not contain domain logic .
• ... if I were a caring mother, I would definitely tell my child: "Never write data transfer objects!" In most cases, data transfer objects are nothing more than a bloated set of fields ... The value of this disgusting monster is solely in the ability to transfer over the network several items of information in one call - a reception that is of great importance for distributed systems.

Examples of patterns in the platform 1C

The application programming interface available to the developer in developing the managed form contains many examples of these principles.
For example, the OpenForm () method, a typical “hardened” interface.

  =  ("1, 2, 3", 1, 2, 3);  = (, ); 

Compare with the v8.1 style.

  = (); .1 = 1; .2 = 2; .(); 

In the context of the managed form, the set of “Data Migration Objects”. You can select the system and the developer defined .
The system models on the client an application object, in the form of one or more form data elements. You cannot create them outside the binding to the form details.

• Data Forms Structure
• These FormsCollection
• Data FormsStructureCollection
• Data Forms Wood

Conversion of system data transfer objects to application types and back is performed by the methods:

• ValueDataForm ()
• Data Forms Value ()
• CopyDataForm ()
• ValueV recital Forms ()
• Details FormsValue ()

Often an explicit transformation is used when adapting an existing solution. Methods can expect (use features) input parameters, such as Table Values, not Data Forms, or the method has been defined in the context of the application object and has become unavailable for a direct call from the form.
Example 1C v8.1:

 //      () 

Example 1C v8.2:

 //       = (""); .(); (, ""); 

Data transfer objects whose structure is determined by the developer is a small subset of the types available on both the client and the server. Most often, the following parameters are used as parameters and results of the “hardened” interface methods:

• Primitive types (string, number, boolean)
• Structure
• Conformity
• Array
• References to application objects (unique identifier and textual representation)

Example: the method takes a list of orders for changing status and returns a description of errors to the client.

 &  (, )  =  (); // [][ ]       ();   = .(); ….  ,     …  (); .(, ()); ; ;  ;  // () 

Structure the code

The main goals that the managed form module should reflect and the approaches to the solution.

• Clear separation of client and server code. Let's not forget, at the time of execution these are two interacting processes, in each of which the available functionality is significantly different.
• Clear selection of the remote access interface, which server methods can be called from the client, and which cannot? The names of the remote interface methods begin with the prefix “Server”. This allows reading the code to immediately see the transfer of control to the server, and simplifies the use of contextual prompts. Note that the official recommendation (ITS) suggests naming methods with postfixes, for example, so ChangeStatusZakazazVServera (). However, we will not repeat all server methods that can be called from the client, and therefore logical accessibility is more important than the place of compilation. Therefore, the prefix "Server" mark only the methods available for the client, the example method is called ServerEditStatusZakazov ().
• Readability. A matter of taste, we accept the order when the module begins with the procedures for creating a form on the server and remote access methods.
• Maintainability. There must be a unique place to add new code. An important point, automatically generated by the configurator of the prefab methods are added to the end of the module. Since form event handlers are most often created automatically, the corresponding block is located last, so as not to drag each handler to a different place in the module.

Below is the basic structure of the module that implements these goals.

• Graphic option - clearly shows the main thread of execution.
• The text version is an example of a template design for quick insertion of a structure into a new form module.

 //////////////////////////////////////////////////////////////////////////////// // <(c) ="<?"", >" ="<?"", ,"=dd.MM.yyyy">"/> // <> // <?> // </> //////////////////////////////////////////////////////////////////////////////// //   //////////////////////////////////////////////////////////////////////////////// //   //*******    ******* &  (, ) //    //*******    ******* //******* -   ******* //////////////////////////////////////////////////////////////////////////////// //      //////////////////////////////////////////////////////////////////////////////// //   //******* -   ******* //*******  ******* //*******    ******* //////////////////////////////////////////////////////////////////////////////// //    

Related Issues

In conclusion, we denote several directions that it is useful to think about when programming client-server interaction.

• Options for the implementation of the remote access interface . Asynchrony, the degree of detail ...
• Caching In 1C, an unsuccessful architectural decision was made, by introducing caching only at the level of invoking methods of common modules and without providing management capabilities (time of relevance, reset on demand).
• Implicit server calls . Do not forget about the technological features, many "innocuous" operations on the client provoke a platform to access the server.
• Pre / postponed data loading.