Pro web client 1C

One of the nice features of the 1C: Enterprise technology is that the application solution developed using the technology of managed forms can be launched in a thin (executable) client for Windows, Linux, MacOS X, or as a web client for 5 browsers - Chrome, Internet Explorer, Firefox, Safari, Edge, and all this - without changing the source code of the application. Moreover, externally, the application in the thin client and in the browser functions and looks almost identical.
Find 10 differences (under the cat 2 pictures):

Linux thin client window:



The same window in the web client (in the Chrome browser):
')


Why did we make a web client? Speaking a little pathetic, this task was set before us by time. Work over the Internet has long been a prerequisite for business applications. Initially, we added the ability to work via the Internet for our thin client (some of our competitors, by the way, stopped at this; others, on the contrary, refused a thin client and limited to the implementation of the web client). We decided to give our users the opportunity to choose the version of the client that suits them more.



Adding the ability to work over the Internet for a thin client was a big project with a complete change of client-server interaction architecture. Creating a web client is a new project, starting from scratch.

Formulation of the problem

So, the requirements for the project: the web client should do the same thing as the thin client, namely:

1. Display user interface
2. Execute client code written in 1C

The user interface in 1C is described in a visual editor, but declaratively, without a pixel-by-pixel arrangement of elements; about three dozen types of interface elements are used - buttons, input fields (text, digital, date / time), lists, tables, graphics, etc.

The client code in 1C can contain server calls, work with local resources (files, etc.), printing and much more.

Both the thin client (when working through the web) and the web client use the same set of web services to communicate with the 1C application server. The implementation of the clients, of course, is different - the thin client is written in C ++, the web client is written in JavaScript.

A bit of history

The project of creating a web client started in 2006, a team of 5 people participated in it (on average). At certain stages of the project, developers were involved to implement specific functionality (tabular document, diagrams, etc.); as a rule, these were the same developers that did this functionality in the thin client. Those. developers re-wrote JavaScript components previously created by them in C ++.

From the very beginning, we rejected the idea of ​​any automatic (at least partial) conversion of C ++ code of a thin client into a JavaScript web client due to the strong conceptual differences between these two languages; The web client was written in JavaScript from scratch.

In the first iterations of the project, the web client converted the client code in the embedded language 1C directly into JavaScript. The thin client acts differently - the code in the built-in language 1C is compiled into byte-code, and then this byte-code is interpreted by the client. Subsequently, the web client also began to do - first, it gave a performance gain, and second, it allowed unifying the architecture of thin and web clients.

The first version of the 1C: Enterprise platform with web client support was released in 2009. The web client at that time supported 2 browsers - Internet Explorer and Firefox. The initial plans were to support Opera, but due to the problems that were unsurmountable at that time with the handlers for closing the application in Opera (it was not possible to track down the application with 100% confidence, and at that moment to disconnect from the 1C application server) these plans had to be abandoned.

Project structure

In total, the 1C: Enterprise platform has 4 projects written in JavaScript:

1. WebTools are shared libraries used by other projects (we include the Google Closure Library here ).
2. Formatted Document Control (implemented in JavaScript in both the thin client and the web client)
3. Scheduler control (implemented in JavaScript in both the thin client and the web client)
4. Web client

The structure of each project resembles the structure of Java projects (or .NET projects - to whom that is closer); we have a namespace, and each namespace lies in a separate folder. Inside the folder are files and neymspeys classes. There are about 1000 files in the web client project.

Structurally, the web client is divided into the following subsystems:

• Managed Client Application Interface
  
  • General interface of the application (system menus, panels)
  • Managed form interface, including, among other things, about 30 controls (buttons, various types of input fields - text, digital, date / time, etc., tables, lists, charts, etc.)
  
  
• An object model that is accessible to developers on the client (more than 400 types in total: the object model of the managed interface, data composition settings, conditional design, etc.)
• Interpreter built-in language 1C
• Browser extensions (used for non-javascript functionality)
  
  • Working with cryptography
  • Work with files
  • A technology of external components that allows them to be used in both thin and web clients.

Design features

Implementing all of the above in JavaScript is not easy. Perhaps 1C Web Client is one of the largest client-side applications written in JavaScript - about 450,000 lines. We are actively using an object-oriented approach in the web client code, which simplifies working with such a large project.

To minimize the size of the client code, we first used our own obfuscator, and starting with platform version 8.3.6 (October 2014), we began to use the Google Closure Compiler . The effect of using the figures - the size of the web client framework after obfuscation:

• Own obfuscator - 1556 KB
• Google Closure Compiler - 1073 KB

Using the Google Closure Compiler helped us improve the performance of the web client by 30% compared to our own obfuscator. In addition, the amount of memory consumed by the application decreased by 15-25% (depending on the browser).

Google Closure Compiler works very well with object-oriented code, so its efficiency is for the web client as high as possible. Closure Compiler does a few good things for us:

• Static type checking at the project build stage (provided that we cover the code with JSDoc annotations). The result is static typing, very close in level to typing in C ++. This helps to catch a fairly large percentage of errors at the compilation stage of the project.
• Reducing code size through obfuscation
• A number of executable code optimizations, such as:
  
  
  • inline function substitutions. Calling a function in JavaScript is a rather expensive operation, and inline substitutions of often used small methods significantly speed up the work of the code.
  • Counting constants at compile time. If the expression depends on a constant, the actual value of the constant will be substituted into it.

We use WebStorm as the development environment for the web client.

For code analysis, we use the SonarQube , where we integrate static code analyzers. With the help of analyzers, we monitor the degradation of the quality of the source code in JavaScript and try to avoid it.

What tasks solved / solve

During the project we faced a number of interesting tasks that we had to solve.

Data exchange with the server and between windows

There are situations where obfuskie source code may interfere with the operation of the system. A code external to the executable code of the web client, due to obfuscation, may have function and parameter names different from those that our executable code expects. The external code for us is:

• Code coming from the server in the form of data structures
• Code of another application window

To avoid obfuscation when interacting with the server, we use the @expose tag:

/**
 * @constructor
 * @extends {Base.SrvObject}
 */
Srv.Core.GenericException = function ()
{
    /**
     * @type {string}
     * @expose
     */
    this.descr;

    /**
     * @type {Srv.Core.GenericException}
     * @expose
     */
    this.inner;

    /**
     * @type {string}
     * @expose
     */
    this.clsid;

    /**
     * @type {boolean}
     * @expose
     */
    this.encoded;
}

(, ).

/**
 *    DropDownWindow
 *
 * @interface
 * @struct
 */
WebUI.IDropDownWindowExp = function(){}

/**
 *    1   
 *
 * @param {boolean} isForward
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarker = function (isForward, checkOnly){}

/**
 *      
 *
 * @param {boolean} isFirst
 * @param {boolean} checkOnly
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.moveMarkerTo = function (isFirst, checkOnly){}

/**
 * @return {boolean}
 * @expose
 */
WebUI.IDropDownWindowExp.prototype.selectValue = function (){}

We used Virtual DOM before it became mainstream)

, UI, , DOM . Virtual DOM UI. DOM , , DOM-.

-

- , (CSS ..). , ( ) , CSS.

( Java C++), , Selenium.

– , , -. , «1», -. — . - . - , – . .

25 . (, ) . .




Selenium ; , - – Selenium , , .. . , .

( Selenium) . «1:». ( ) . – .

; Dynatrace AJAX Edition DynaTrace. , . ( ) – , . JavaScript, DOM .. / – , .

, Google Closure Compiler - inline- (, ). , .

, , JavaScript, :

. – , ( , JavaScript Chrome Firefox), — , . , 3 – Windows, Linux MacOS. 1: 1. - .

Safari NPAPI, Internet Explorer — ActiveX. Microsoft Edge , - .

- – . - , , -.

— , , . , – . - . ( ) , - ( ). .