1C:Enterprise 8.2 :: Specifics

From the point of view of 1C:Enterprise 8.2 developer, user interface is more a declarative description of interface items (main menu and forms), rather than a set of drawn (designed) items .

Developers only define general scheme of command interface and interface of forms, mainly – grouping of items.

This description then used by the system when building a particular user interface taking into account many factors (user rights, specifics of this implementation, settings defined by the user, etc.)


Interface is created by means of definitions of metadata properties

With this interface development approach there is no need to align a form by pixels, for example, or to define control item assignments; most of are now automatically placed proceeding from data types and metadata properties.

The Strategy for Development of Applied Solutions in Managed Application

The interface conception used by managed application puts a number of tasks upon a developer that he did not see before or they were not so meaning.

Designing of subsystems' content.
In earlier versions of 1C: Enterprise 8 subsystem were only used by a developer to split applied solution's functionality into some groups that simplify the development process. That grouping has not much of external meaning, notable for users.
With managed application, a subsystem's structure has of the most important meanings, since it is used by the system to build user command interface. Therefore, the structure should be attentively thought out from the point of view how user should 'see' the application. Configuration objects should be distributed by subsystems carefully and with sense.
Specifying interactive metadata properties.
For configuration's object properties, one should specify the properties defining ways to display and edit the objects' data.
Designing and specifying functional options.
Beginning development, one should think out which functionality parts should be customizable at implementation stage.
Setting up visibility by roles.
One should think over what functionality should be displayed to which roles, so that interface would not appear crammed. For example, which entry commands should be put to the action panel.
Selection of command set.
Only necessary context commands should be selected to be displayed in forms.
Interface operation evaluation.
It is useful to preview interface for typical user types, also to look at how it looks with functional options turned off.

Managed Command Interface

Command interface – is the main tool for users to navigate across application's functionality.

Managed application command interface is built basing on subsystems. A developer has to create a hierarchy of subsystems that would represent a particular applied solution's functionality.

User is shown an applied solution's structure (subsystems' hierarchy) as the main navigation bar, also provided with standard command to use applied objects' functionality (such as calling catalog lists, documents, opening reports, data processors, etc.).

Managed Forms

The user operation is mainly performed in forms. The forms that are used in managed application are called managed forms.

The main difference of the forms is that managed application forms are not 'drawn' by a developer, but they are represented in configuration as a logical description of content of a form. While specific location of forms is done automatically by the system when displaying a form.

The part of form visible to users is described as a tree with form's elements (see the picture below).


Description of form interface in the Designer

The elements can be represented by input fields, tables and buttons. An element can implement a specific functionality. For example, an input field can act as a text box, check box, label field, image field, text document field, HTML document field, switch or radio button. Besides, an element can be a group of other elements. A group can be represented as a panel with a border, a panel with pages (tabs), a proper page or a command panel. A table element includes other elements (columns). The structure of elements describes the way the form appears.


Definition of ElementForm interface appearance

All functionality of a form is described as attributes and commands.

Attributes are data that a form operates with; commands are actions to be performed.

Thus, a developer using the form editor should add necessary properties and commands to the form, create the form elements representing them and group some elements, if necessary.


Definition of form functionality

The system can automatically create an applied object's form, but developers can also create the form and define its set of attributes, commands and elements to be displayed. Basing on this logical description the system automatically shapes the form's appearance. At that, the system takes into account various properties of data being displayed (such as, data type), so that form's elements would be placed conveniently for users.

Developers can change placement of form elements using various settings. The order of elements, desirable width and height can be changed. This, however, is just some additional information that assists the system in displaying the form.


Adding new form element

Developers can use not only forms' commands in managed application forms, but also global context commands used in a configuration's command interface. In addition to that, the possibility implemented to create parameterized commands which open other forms considering current form's specific data. For example, it could be a stock report for the warehouse which is selected at the currently open expenditure invoice form.

Managed Forms Operation Mechanics

Operation of managed forms has the following specifics:

Forms exist on both client and server.
They provide client-server interaction (data transfer and transfer of design properties of elements).
Forms do not operate with applied objects.
Special universal objects – 'FormData…' are used in forms. Applied objects operate on server side only and during execution of only some operations.


'FormData...' objects in Syntax Assistant window

Briefly, the mechanics can be described as the following.

When a form is being opened:

An object is read from a database.
The object is transformed into the form data.
The object is removed from the memory.
Form data are transferred to the client side.

When a form is being written:

From data are received from client.
The form data are transformed into an object.
The object is written to the database.
The object is removed from the memory.

Control Items

Forms can contain various control items ('controls') to display and modify a form's data. The system includes a specialized set of controls specific for business-tasks and having the following specific features:

Text boxes, equipped with functional buttons (selection, clear, combo-box).
The possibility to edit any data types in one control item.
Efficient and convenient dynamic lists to browse database information, supporting filtration features, end more. See below for more information.
Modern and ergonomic design of controls.
Controls' behaviour is data-driven.

For example, if a text box is referenced to String data type, then it will be looking as

However, if the control is referenced to data of Date type then the control item appearance will be as following:

Click on the functional button to the right of the field causes mini-calendar window to appear:

If this control item is associated with some applied object, then it will get two more buttons: selection button and clear the textbox button:

Business tasks-specific controls that are used in 1C:Enterprise 8 forms may have more additional buttons, such as:

Selection from a list of values,
Clearance,
Adjusting value,
Open an object.

Actions performed at pressing additional entry buttons may differ, depending on data type that are displayed in the field (textbox). Besides, textboxes support 'automark incomplete' function, designating required fields on forms.

Since the framework supports storing various data type in database fields, controls also allow entry and editing of data of various types in one control item. For example, a text box supporting this feature will look like the following:

Special button 'T' means that data type is not yet specified for the field. Pressing this button opens a special data type selection window, to be contained in the window.

Dynamic Lists

Dynamic lists in managed application are composed basing on the data composition system.


Sales of goods is a dynamic list

For dynamic lists developers either select a configuration's object (and by that, in fact, selecting a table) to be displayed, or specify an arbitrary ('custom') query to get necessary data from a database.


Dynamic list attributes

The system automatically reads the query data, in portions, along with a user's browsing down the list. At that, both developer and user are provided rich possibilities of data composition system to customize the information being displayed (filtration, sorting and conditional formatting).

Interface Definition in Metadata

To automate the process of user interface composing there is a set of applied objects' attributes specified in metadata. This includes a extensive number of properties describing data representation. For example, a property can be specified for a string to be multiline, or another one – to specify negative values to be displayed in red color. The system uses such properties to build interface for forms, also for reports.

It is possible to customize properties for applied objects' standard attributes (such as Code, Name, Date, Owner, etc.). This allows changing, for example, form headings formed by the system.

There is a possibility to specify several representations for metadata objects that describe applied objects (catalog, document, etc.). These representations are used by the system to form commands and form headings.

There is a 'Quick choice' tag for applied objects. The tag can be used, for example, in a catalog making it possible to quickly select the catalog's items in all entry fields where the catalog's items are used.

There is a fill check mechanism for applied objects. It is used for 'required' form fields (i.e. the fields must be filled by a user). The check can be specified by metadata attributes' properties, either implemented by special handlers in objects' modules.


Fill check and Fill value (initial fill functionality) properties

The mechanism of initial fill allows defining some fields to be filled with initial data upon data entry.

Applied objects' manager modules allow implementing functions and procedures that logically relate to functionality of some applied objects, but not bound to a particular object's entity.

User Settings Mechanism

To store user settings information between work sessions the platform implements settings repositories.

There are two types of settings repositories:

Standard repository – a repository used by the system by default and storing data in system tables of an information base.
Settings repository – special metadata objects describing data storage in some information base object. For example, this object can contain description of how to process the settings stored in a catalog.

The platform uses five repositories:

System repository. This repository stores all platform operation-related settings, such as dimensions of forms, table document print settings, etc. As a system repository the standard settings repository is always used. I.e. system repository data are always stored in the information base system table.
User report settings repository. As it follows from its name, this repository stores user report settings.
Report variant repository – used as storage for report variants.
Form data settings repository – stores form data. The repository can be used, for example, to store data processors' attributes. At that an individual repository can be selected for each report and a data processor.

When developing a configuration a developer can define original repositories of settings for all repositories (excepting the system repository). For this one should create an object – settings repository in a corresponding metadata tree branch and then specify it in proper configuration property. Configuration object's properties have the same names as the named above repositories.


Using repositories

Thus, repositories' data can be stored in both information base system table and in some special information base object, for example in a catalog or in an information register.

For example, one can create a settings repository object in a configuration and specify in the configuration's property that this repository should be used to store report settings. Thereby, report settings will be stored not in the system table, but in the some object, for example in a catalog. This give the possibility to arrange operation with common report settings, implement restriction system, settings exchange, etc.

Your proposals on site send to:webmaster@1c.ru