Managed forms 1c 8.3 on the server. StavAnalit. Contact Information. Conditional form design. Example of interactive setup

We all know that 1C had many different versions of the 1C platform, we will now be interested in some of the latest versions at the time of this writing, these are versions 1C 8.2 and 1C 8.3. If you had to work in both of these versions, then you, most likely, noticed differences in the interfaces of these versions, for users they differ only externally. Essentially the choice regular or managed application tells the system which forms to display to run, conventional or managed and which client of the application will be used by default, thick or thin. More detailed information for clients, read the article "What is a thick and thin client in 1C, as well as their differences."

Normal 1C application (normal forms, normal interface, version 1C 8.2)

In 1C 8.2 only work is possible with regular forms, in normal application mode... The image below shows the base in the "normal 1C application" operating mode (normal forms).

Managed 1C application (managed forms, managed interface, version 1C 8.3)

On the 1C 8.3 platform, we can work both with regular forms (in compatibility mode) and with managed ones. Moreover managed forms have two display types, standard and taxi... An example of 1C 8.3 configuration with standard managed forms is shown below, followed by the "Taxi" interface.

What is the difference between a regular and managed 1C application?

As we have already found out a regular application and a managed application are these types of launching a 1C program... Moreover, depending on the value of the 1C launch type ( regular or managed application), by default a specific interface will be loaded ( regular or managed forms), hence there are so many synonyms for this concept. We would like to note that the differences in the interfaces are quite significant, the managed interface has been completely redesigned. In principle, these are all the differences that ordinary users of the 1C program see. As for programmers, the managed interface requires writing modified code, because development is already underway in 1C 8.3, and not in 1C 8.2, hence all the ensuing consequences. The code should also be divided into client and server, this is indicated using the appropriate directives in the configurator.

Since the platform version 8.2, 1C began to use new principles of building the interface and user interaction with the database. The new technology is called Managed Application. The mechanisms for constructing forms and the scheme of interactions between the user of the 1C server and the database have undergone the greatest revision. Normal mode is still supported by the platform, but over time, all 1C users will switch to managed forms.

For ordinary users, the managed 1C document form differs from the usual one only in appearance. For a developer, this is new mechanism with its own rules, laws and conditions. Many areas have undergone changes, but the following innovations are considered key among experienced 1C developers:

Independent formation of the structure of the form and the placement of fields by the platform. If earlier the developers described the position of the field by indicating pixels, now it is possible only to specify the type of grouping;
The form consists of details representing form data, and commands - procedures and functions performed;
Form code is executed on the server and client side. After all, the form itself is a configuration object that is created on the server and displayed on the client. This means that it combines the client and server parts;
On the client side, many types of data have become unavailable and now there is no possibility to change the data in the infobase;
For each procedure or function, a special setting must be specified - a compilation directive. It is responsible for the place where the code is executed and can take the following values:
- On the client;
- On server;
- OnServerWithoutContext;
- On Client On Server;
- OnClientOnServerWithout Context.

The last point is especially acute in managed forms mode. If a developer is poorly versed in directives or client-server interactions, then it will be extremely difficult for him to create a managed form. All new principles of building managed forms in 1C: Enterprise 8.3 are united by the general concept of a three-tier architecture. It includes client computers, a 1C server and a DBMS where data is stored.

Editing a managed form in the configurator is different too. Many aspects have changed and the developers of version 7.7, where there were no managed forms, may be surprised. Even changed appearance the form constructor, which can be seen by opening any of the forms on the configuration object. When opening an object, we see a window divided into several sections:

Form interface elements. At the top left there is a window that lists all the fields reflected in the selected form, which ensure the interaction of the program with the user;
Form details. At the top right are all the data that the form works with. It is in them that information is stored on the client side;
Displaying a managed form. Below we see a preliminary look based on the interface elements;
Form module. The section containing the procedures and functions used by this form. Here you can find the code for the algorithms for the program's interaction with both the user and the database.

1C developers urge customers to switch to managed forms, so learning the principles of developing managed forms is a matter of time. Once you start working with this type of form, you will understand that this is a step towards standardizing development and adhering to uniform rules. Therefore, the ability to work with managed forms in 1C 8.3 increases your 1C developer level.

Principles for Designing Managed Forms

First of all, to understand the mechanism of the 1C controlled mode, you should remember that the form exists both on the server and on the client. Moreover, on the client, this object is only an image of the user interface with the program. All calculations, algorithms, calculations and processing should take place only on the server side. This is dictated not only by the inability to use many functions and parameters on the client, but also by the performance requirements.

You can figure out where the procedure is being performed by the name of the directive, which must be written before each procedure and function in the form module. The "Out of Context" wording indicates that data in a managed form will not be passed to this procedure on the server. Thus, in such procedures it will not be possible to write algorithms based on the values entered by the user. If this wording is not specified, then the form is transmitted in its entirety with all the details, and you will be able to refer to them.

1C developers strongly recommend using non-contextual server calls, minimizing their number and trying not to perform calculations on the client. It is difficult for novice developers without theoretical training to comply with all these rules and change the code correctly. Before the start independent work it will be helpful to open a managed configuration form to look at the syntax and how the client and server interact.

& NaServere PoluchitPlatezhnoRaschetnyeDokumentyIzHranilischa procedure (NovyyAdresVHranilische) & NaServereBezKonteksta EstRaschetySKlientom function (DokumentOsnovanie) & NaServereBezKonteksta ZapolnitSpisokVyboraKPP procedure (SpisokVybora contractor, DataSvedeny) & NaKliente ZapolnitGolovnogoKontragentaZavershenie procedure (VybrannoeZnachenie, DopolnitelnyeParametry) & NaServere UstanovitTekstPlatezhnoRaschetnyhDokumentov procedure () & NaServere EstZapolnennyeIskhodnyeDokumenty () function

The new rules for developing 1C forms will be of great benefit if all developers adhere to them. Moreover, everyone will feel the changes for the better - both programmers and companies working in 1C, and franchisee companies, and 1C developers. Main consequences correct operation managed forms in 1C:

Ease of configuration maintenance and increased code readability. Hence, we can conclude that an algorithm written by one developer can always be corrected by another employee, without wasting a lot of time;
Separation of code executed on the client and server. Given how different the functionality available on each of these sides is, separating them would be the right move;
A deeper understanding by developers of platform logic, client-server interactions, and the algorithms they write. In versions 8.0 and earlier, it was very common to come across forms of documents or reference books, developed without understanding the client-server part;
Improving the performance of configurations and reducing the load on client computers;
Reducing the cost of purchasing computers for workstations due to the absence of the need to purchase powerful PCs.

The choice of a managed form as the main 1C launch mode can bring many surprises. But with the right approach, this step will bring big dividends, so more and more 1C users all over Russia decide to take it. Taking into account the fact that the 1C company in the future expects to develop precisely controlled forms, it is risky to remain on outdated conventional ones.

Forms in 1C: Enterprise are designed to display and edit information contained in the database. Forms can belong to specific configuration objects or exist separately from them and be used by the entire application solution as a whole.

For example, the reference Nomenclature can have several forms that will be used for specific purposes - editing a catalog item, displaying a list, etc.:

Along with this, there may be general forms that do not belong to specific configuration objects - general forms.

Basic forms

Each configuration object can be used to perform some standard actions. For example, any catalog may need to display a list of its elements, display individual elements of the catalog, display a catalog group, select elements and groups of elements from the catalog. For any document, the list of such actions will be much smaller: viewing a list of documents, selecting from a list of documents, and viewing a separate document.

To ensure the execution of such standard actions with the data of the objects of the applied solution, for each of them there is a set of basic forms that will be used when performing the corresponding actions. Any of the forms subordinate to this object can be assigned as the main one. For example, the reference Nomenclature the following basic forms can exist:

And at the document Receipt of goods and services the composition of the main forms will be different:

Thus, if the user wants to see the list of the directory Nomenclature or list of documents Receipt of goods and services, the system will open the corresponding form assigned as the list form for these objects.

Auto-generated forms

An important feature of the 1C: Enterprise 8 system is the mechanism of auto-generated forms. This mechanism frees the developer from having to create all possible forms for each of the configuration objects. It is enough for the developer to add a new configuration object, and the system itself will generate the necessary forms at the necessary moments of the user's work to display the information contained in this object.

Thus, the developer needs to create his own forms of the objects of the applied solution only if they should have differences (different design or specific behavior) from the forms automatically generated by the system.

Linking a form to data

The belonging of a form to one or another configuration object does not determine the composition of the data that is displayed in the form. That the form belongs to, for example, a directory Nomenclature, allows you to assign it to one of the main forms for this directory, but does not in any way determine what kind of data this form will display, and what its behavior will be.

In order to associate the form with the data, the form details are used, which indicate the list of data displayed by the form. All forms, by themselves, have the same behavior, no matter what data they display. However, one of the form attributes can be assigned to it as the main one (it is highlighted in bold), in which case the standard behavior of the form and its properties will be supplemented depending on what type the main form attribute has:

For example, if a document is assigned as the main form attribute Receipt of goods and services, then when you close the form, the system will ask you to confirm the recording and posting of this document. If we assign, say, a reference book as the main requisite of the form Nomenclature, there will be no such confirmation request when closing the form.

Form structure

The main feature of the forms is that they are not drawn by the developer in detail, "pixel by pixel". A form in a configuration is a logical description of the composition of a form. And the specific placement of elements is performed by the system automatically when the form is displayed.

The displayed part of the form (visible to the user) is described as a tree containing form elements.

Items can be input fields, checkboxes, radio buttons, buttons, and so on. Additionally, an item can be a group that includes other items. A group can be represented as a panel with a frame, a panel with pages (tabs), a page itself, a command panel. In addition, an element can be a table, which also includes elements (columns). The element structure describes how the form will look.

All the functionality of the form is described in the form of attributes and commands. The requisites are the data that the form works with, and the commands are the actions performed. Thus, the developer in the form editor must include the necessary attributes and commands in the form, create form elements that display them, and, if necessary, arrange the elements into groups.

Based on this logical description, the system automatically generates the appearance of the form for display to the user. In this case, the system takes into account various properties of the displayed data (for example, the type) in order to arrange the form elements as conveniently as possible for the user.

The developer can influence the arrangement of elements with different settings. It can determine the order of elements, specify the desired width and height. However, this is only some additional information helping the system display the form.

In forms, the developer can use not only the commands of the form itself, but also the global commands used in the command interface of the entire configuration. In addition, the ability to create parameterizable commands has been implemented that will open other forms based on the specific data of the current form. For example, it can be a call of a report on the balances in the warehouse that is currently selected in the form of an invoice.

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

Introduction

Let's start with short description the concept of "managed form" and related concepts of the 1C platform. Platform connoisseurs may skip this section.

In 2008 became available a new version platform 1C: Enterprise 8.2 (hereinafter Managed Application), which completely changes the entire layer of work with the interface. This includes the command interface, forms, and the window system. This not only changes the design model of the user interface in the configuration, but also proposes a new architecture for the separation of functionality between the client application and the server.

The managed application supports the following types of clients:

Thick client (normal and managed startup mode)
Thin client
Web client

A managed application uses forms built on new technology... They are called Managed Forms. To facilitate the transition, legacy forms (so-called regular forms) are also supported, but their functionality is not evolving and they are only available in the thick client run mode.

The main differences between Managed Forms for a developer are:

Declarative, not pixel-by-pixel, description of the structure. 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 attributes and commands. Requisites are the data that the form works with, and commands are the actions performed.
The form is executed on both the server and the client.
In the context of the client, almost all application types are inaccessible, and accordingly, it is impossible to change the data in the infobase.
For each method or form variable, a compilation directive must be specified, which determines the place of execution (client or server) and access to the form context.

Let's list the directives for compiling form methods:

& OnClient

&On server

& OnServerWithoutContext

& OnClientOnServerWithout Context

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

All further reasoning will be about the right side of the illustration, how to structure the module code and what principles will allow you to implement effective client-server interaction.

Let's define the problem

Several years have passed since the new version of the 1C platform has been actively used and many solutions (configurations) have been released both by 1C and its numerous partners.

During this time, have the developers developed 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 new architectural realities?

Consider the structure of the code (form module) in several forms of one typical configuration and try to find patterns.

By structure we mean code sections (most often these are comment blocks) allocated by the developer for grouping methods and directives for compiling these methods.

Event handlers section

Method - on the client

Method - on the server

Method - on the client

Service procedures and functions section

Input control helper functions

Service procedures and functions

Payment documents

Values

Event handlers

Service procedures on the server

Service procedures on the client

Service procedures on the server without context

Header event handlers

Command event handlers

General procedures

Form event handlers

Subsystem procedures "contact information"

In fact, the structure of the code is absent, 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.
Methods are often grouped by interface elements "Working with the tabular section Products, Contact information".
Arbitrary arrangement of methods and code groups. For example, event handlers can be in one form at the top, in another at the bottom, in a third they are not selected at all, etc.
And let's not forget that this is all within one configuration.
Yes, there are configurations in which the words "General, Service, Auxiliary" are always in the same places, but ...

Why do you need code structure?

Simplification of maintenance.
Simplification of learning.
Fixing general / important / good principles.
... your option

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

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

These are absolutely correct slogans, but how can they be implemented? How to minimize the number of calls, what does it mean to program in client-server mode?

Design patterns or the wisdom of generations

Client-server interaction has been used in various software technologies for more than a dozen years. The answer to the questions outlined in the previous section has long been known and summed up in two basic principles.

Remote Facade (hereinafter Remote Access Interface)
Data Transfer Object (hereinafter Data Transfer Object)

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

… Every object potentially destined for remote access should have a low granularity interface to minimize the number of calls required to perform a particular procedure. ... Instead of requesting an invoice and all of its items separately, it is necessary to read and update all the items of the invoice in 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 lies solely in the ability to transmit several pieces of information over the network in one call - a reception that has great importance for distributed systems.

Examples of templates in the 1C platform

The API available to a developer when developing a managed form contains many examples of these principles.

For example, the OpenForm () method, a typical "coarse" interface.

Open Parameters = New Structure ("Parameter1, Parameter2, Parameter3", Value1, Value2, Value3);

Form = OpenForm (FormName, OpenParameters);

Compare with the style adopted in v8.1.

Form = GetForm (FormName);

Form.Parameter1 = Value1;

Form.Parameter2 = Value2;

Form.Open ();

In the context of a managed form, there are many Data Migration Objects. It is possible to distinguish systemic and developer-defined.

System objects model on the client an application object in the form of one or more form data elements. You cannot create them outside of binding to form attributes:

DataFormsStructure

DataFormsCollection

DataFormsStructureCollection

DataShapeTree

Transformation system objects data transfer to applied types and back is performed by methods:

ValueInForm Data ()

FormDataValue ()

CopyForm Data ()

ValueBForm Attribute ()

PropsFormVValue ()

Often, an explicit transformation is used when adapting an existing solution. Methods can expect (use features) input parameters, such asValueTable rather thanFormDataCollection, or the method was defined in the context of an application object and is no longer available for direct call from a form.

Example 1C v8.1:

// on the client in the context of the form

FillUserCache (SubdivisionLink)

Example 1C v8.2:

// on the server in the context of the form

ProcessingObject = FormInValue ("Object");

ProcessingObject.FillUserCache (DepartmentLink);

ValueVFormAttribute (ProcessingObject, "Object");

Developer-defined data transfer objects are a small subset of the types available on both the client and server. The most commonly used parameters and results of the "coarse" interface methods are:

Primitive types (string, number, boolean)

Structure

Correspondence

Example: the method accepts a list of orders to change the status and returns a description of the errors to the client.

& OnServerWithoutContext

Server functionChangeOrderStatus (Orders, NewStatus)

Errors = New Match (); // [order] [error description]

For Each Order From Orders Cycle

StartTransaction ();

Attempt

DocOb = Order.GetObject ();

…. other actions, perhaps not only with an order ...

Exception

UndoTransaction ();

Errors.Insert (Order, DescriptionErrors ());

End of Attempts;

End of Cycle;

Return of Errors;

EndFunction // ServerChangeOrderStatus ()

Structuring the code

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

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

Below is the basic structure module that implements the listed goals.

Graphical option - visually shows the main flow of execution.
The text variant is an example of a template design for quickly inserting a structure into a new form module.

// <Описание>

////////////////////////////////////////////////////////////////////////////////

// MODULE VARIABLES

////////////////////////////////////////////////////////////////////////////////

// ON SERVER

// ******* EVENTS ON THE SERVER *******

&On server

Procedure OnCreateAtServer (Failure, StandardProcessing)

// Insert the content of the handler

End of Procedure

// ******* REMOTE ACCESS INTERFACE *******

// ******* BUSINESS LOGIC ON THE SERVER *******

////////////////////////////////////////////////////////////////////////////////

// GENERAL CLIENT AND SERVER METHODS

////////////////////////////////////////////////////////////////////////////////

// ON THE CLIENT

// ******* BUSINESS LOGIC ON THE CLIENT *******

// ******* COMMANDS *******

// ******* EVENTS ON THE CLIENT *******

////////////////////////////////////////////////////////////////////////////////

// OPERATORS OF THE MAIN PROGRAM