A little about the Skin interface

The development and, to a large extent, maintenance of large systems has its own specific features, and each team has its own developments in the arsenal in the form of libraries, life hacks, tools, instructions, guides (etc, etc. etc.) located in Git. This post does not discuss methods for developing such projects. We will tell you only about one technique that makes it easier to maintain and support large systems. We'll talk about Skin. This is not something new, but simply the possibility of implementing a system with access through the website. Skin is a ready-made universal shell that any software company can quickly write for its products. Once configured, Skin does not require any changes or modifications when connecting structurally new user groups or new modules in the system.

Ideas for one window are often in the air and are in demand, especially when working with complex multi-modular complexes. Grouping access to various modules and their functionality is provided by menus in one form or another. Therefore, Skin contains an adaptive, if necessary, collapsible menu with bookmarks, adjustable to different devices. Skin builds a hierarchy and menu items based on data from jsons, which are stored in the corresponding settings database and accessed using REST[1]. The structure and content of the items themselves are modified depending on the rights and functional responsibilities of the user (including his personal settings), making it possible to create dynamic, individual menus on the fly. As a rule, Slide Menu is used, which provides a workplace metaphor for each module or subsystem of the software package ( “new” menu, own set of panels and Help pages)with the ability to return to the previous work or to the main window (eclipse bread crumbs).

The Skin menu contains search functions for items, a mechanism for creating “quick” pages in the form of general or individual links to frequently used items, which is important for large systems, counter mechanisms for items (for example, a counter for unregistered inboxes in the Correspondence module) and other features. Skin provides maintenance of “Help” pages for all frames of each system module, and their creation and modification does not require writing code, only filling in the corresponding jsons in the database.

If desired, complex menus of all system modules can be loaded at one time, since jsons are quite compact, and observe is used to track modifications.

Modifying the menu (adding new items, sub-items and even new modules to the complex) does not require any effort in adding or compiling the code, since it all comes down to changes or additions of json in database records through the graphical designer without programming knowledge.

(for example, json generated by the visual “Menu” constructor binds the “Tree” menu item to a working window built according to the “maket1.js” layout with two panels, and fills panel 1 with the organization structure in the form of a tree.

_{var AdminRoutes = {}

_{'Tree': {}

_{0: { panel: “M”, page: 'maket1.js', name: “Maket” }, 1: { panel: 0, db: “DBT”, page: window.LobiAdminConfig.Allbd[0].server + '/Setting/pageDefinitions.nsf/api/data/documents/unid/94BA042FAB9B5 840 462 589B20 054 982D', name: “Organization structure” },}

_{2: { panel: 1, page: 'pages/»Help_ organization structure.html', name: “Hint” }}, }}

Calling any menu item does not reload the entire page, but only the necessary panels, leaving all settings, global variables and the temporary bookmarks area in the current state.

The module interface in Skin has a panel structure (docking layout), which allows you to load independent sub-windows with functional or interface elements of the module into different panels via REST and, if necessary, manipulate them during operation (expand, compress, move, collapse, or place them in temporarily saved bookmark). These actions are performed using an internal system of movable bookmarks of vertical and horizontal types. It is possible to save permanent or basic manipulations in the form of json in the database as individual settings.

Calls to the panel structure, their localization, graphic design and filling with data, and, if necessary, modification, are carried out using the same techniques (Rest + json) from the layout database and Rest databases, and do not require programming or included code. They are typically based on fetch or more modern asynchronous requests. Panels function through rest, so both micro-service and monolith paradigms are easily implemented. A properly designed docking-layout should be adaptable and work on all popular devices.

An important feature is saving the state of the current workflow in the bookmarks line, for conducting temporary or parallel work in other Skin-a modules and the ability to continue working in any saved bookmark from a reserved place. In the simplest cases, browser sessions are used for this, in more general shadow DOM. In the future, when working, you can pick up the saved bookmarks of any module and use the results of its work.

To successfully support and maintain a complex, dynamically developing complex, Skin-e requires a set of visual graphic designers, at a minimum:

· “Forms” drawing and saving a screen form in json with support for multiple (search) selection from classifiers and Rest for communication with the database

· “Grid” drawing and saving tables in json with Rest-controlled data sources, built-in Lazy-load loadings, edge search mechanisms, filtering and sorting, printing mechanisms and a transformer into different formats.

· “Menu” – drawing a menu structure with items, sub-items, indicating slading and saving in json (relevant for bulky systems with dozens of modules)

· “Layout” drawing the structure of panels for the interfaces of system modules and saving them in jsons

It is important to understand that the power of constructors is that the jsons obtained using them will be located in the appropriate databases and, in many cases, provide the functionality of modules and their modification without additional programming. For example, using the “Grid” constructor in Skin, a user without programming knowledge can independently create any selections using the Drag & Drop technology using the data used in the module and subsequently work with them.

As a result, Skin is a set of sliding menu (REST), a docking-layout (REST) ​​frame window subsystem in the ol-a AJAX style, a temporary bookmark zone for storing the results of the current process, and a set of visual graphic designers that speed up the work of creating and maintaining the system.

Adding and changing functionality, including when connecting additional modules, does not require additional Skin programming.

Protection of data and functionality of Skin itself is ensured by proper storage and maintenance of settings and Rest in the database and access to it.

For manufacturing systems, the time-tested Material Design is recommended as a design methodology. The issues of choosing tools for writing REST and a server shell are resolved differently in each specific application; in any case, Skin does not depend on this.

Skin is an integration user interface that allows you to organize and successfully maintain not only large projects, but also the entire information infrastructure of enterprises within one window. All patches of the complex are carried out without stopping or rebooting Skin, since it separates interfaces and software implementation and picks up changes on the fly.

There are many sets of web components and even individual plug-ins (for example Menu [2]Grid[3] DockLng Layout[4]), from which, with some modification of the code, you can build a Skin with the functionality described above.

Sources:

1. https://habr.com/ru/articles/770226/ https://habr.com/ru/articles/323010/

2. https://mmenujs.com/examples.html

3. https://www.htmlelements.com/demos/grid/overview/

https://xpage.me/a-flexible-view-control-for-xpages-series/

4. https://www.htmlelements.com/demos/docking-layout/overview/