CN116107555A

CN116107555A - GUI model driven low-code platform based on energy industry and use method

Info

Publication number: CN116107555A
Application number: CN202211707082.4A
Authority: CN
Inventors: 李振兴; 潘新阳; 贺礼奎; 开大宁; 毛文彬
Original assignee: Shanghai Shine Energy Info Tech Co ltd
Current assignee: Shanghai Shine Energy Info Tech Co ltd
Priority date: 2022-12-29
Filing date: 2022-12-29
Publication date: 2023-05-12

Abstract

The invention provides a low-code platform driven by a GUI model based on the energy industry and a use method thereof, which ensure that software under different development systems can realize integral compatibility and unification through the low-code platform driven by the unified GUI model. To achieve the above object, the present invention includes a GUI layer, a service layer, and a data model layer; after the user changes the data model, the database synchronously updates the table structure of the data model, and the data in the custom data model can be integrated into the interface in the form of a data source in the interface data binding stage. By adopting the technical scheme, each individual client specific service component is further abstracted into a general component, so that multiplexing and personalized secondary customization can be performed in the subsequent service.

Description

GUI model driven low-code platform based on energy industry and use method

Technical Field

The invention belongs to the technical field of program development platforms, and particularly relates to a GUI model driven low-code platform based on the energy industry and a use method thereof.

Background

Low code is a method of creating applications that allows developers to develop applications quickly using minimal coding knowledge. The developer assembles and configures the application through visual modeling in the graphical interface. The core of the low code platform development corresponding to the method is rapid application development, automatic application deployment and execution and design principles driven by using a model. The low-code platform reduces the use threshold of users by virtue of lower learning cost, improves the overall production efficiency of the platform, and reduces the cost of personnel training for enterprises. The high automation characteristic of the system also ensures the stability of development application, and enterprises do not need to spend excessive cost on the operation, maintenance and deployment of the platform. The prior art has been widely used due to the various advantages of low code platforms. For example, in the prior art, the invention patent with patent number 202110304573.3 discloses a system and a method for creating a low-code page, which belong to the technical field of program development and can be used for facing a developer, and a driving model, a view container, an action container and an expansion container are arranged in the system; the driving model is used for creating a corresponding driving model according to the construction instruction, and comprises a view module and an action module; the view container is used for rendering the target page according to the setting of the driving model; the action container is used for carrying out page display and interactive operation on the actions according to the setting of the driving model; and the expansion container is used for expanding the video container or the action container according to the expansion instruction. In a low-code development scene, the invention provides a method and a system for abstracting pages, which effectively solve the redundancy and repetition of a front-end system, improve the efficiency of the developer and improve the expandability of front-end development in the low-code scene.

But for the energy industries of electric power, petrifaction and the like, the organization architecture is complex, and a large number of branch institutions and subordinate units are provided. Different units have different service requirements, and corresponding low-code platforms can be designed by different development units. These single low code platforms are designed to be highly heterogeneous, and although most of them can meet the application of a single enterprise, it is difficult for the group itself to achieve compatibility and unification between different software.

Disclosure of Invention

In order to overcome the defects and the existing problems in the prior art, the invention provides a GUI model driven low-code platform based on the energy industry and a use method thereof, which ensure that software under different development systems can realize integral compatibility and unification through the unified GUI model driven low-code platform.

In order to achieve the above purpose, the invention adopts the following technical scheme: the GUI model driven low-code platform based on the energy industry comprises a GUI layer, a service layer and a data model layer; the GUI layer comprises a visual interface layout module, an interface data holding module and a multi-interface integration module, the service layer comprises a self-defined atomic service module and a self-defined combined service module, and a self-defined data model is arranged in the data model layer; the custom atomic service module and the custom combined service module support contents for a user-oriented custom platform, and after a user changes a data model, a database synchronously updates a table structure of the data model, and data in the custom data model can be integrated into an interface in the form of a data source in an interface data binding stage.

Preferably, when the data model in the data model layer is newly generated, a corresponding CRUD service is generated for the data model layer, whether a related data model is set is judged, and if so, a corresponding related database in the database is updated.

Preferably, the custom data model supports a user to generate a data table by defining the attribute and basic information of the data model; after the data model is published, the system will generate a corresponding data table in the database.

Preferably, the custom data model at least comprises a data structure, a database connection and a presentation layer.

Preferably, the visual interface layout comprises an interface data model structure, an interface editor and an interface layout rendering tool.

Preferably, the interface data model structure supports a Layout class and a content class guilcomponent class.

Preferably, the interface layout rendering tool comprises an element dragging tool;

in the dragging realization process of the element, firstly, the dragcable attribute of the element in the componentPanel is marked as true, the setData function of the DataTransfer object is bound for the onDragStart event of the selected element, and the type of the selected element is bound to the setData function;

binding a getData function of a DataTransfer object for the onDrop event of the target element; after the target element successfully acquires the type data of the generated element from the getData function, a corresponding abstract class is generated for the target element.

Preferably, the interface layout rendering tool comprises a DOM structure and CSS data synchronization tool, so that the Canvas area and the final online interface are ensured to have the same DOM structure and CSS data; the Canvas area and the final online interface have the same data used when rendering the interface, so that only the renderers of the Canvas area and the final online interface need to be adapted if the DOM structures of the Canvas area and the final online interface are consistent with the CSS data. The Canvas area renderer should use Canvas as the root of the DOM structure, while the interface renderer needs to use the root element of the page as the root of the DOM structure, except that the same rendering logic should be used.

The invention also comprises a method for using the GUI model driven low-code platform based on the energy industry, each individual user manages the data model used in the platform, generates the data model, manages the relation between the models later, and the GUI developer performs visual layout on the interface in a dragging component mode, can selectively modify the style of the interface, so as to bind the data in the interface and select whether to set jump logic for the interface.

Preferably, the data bound when the data in the interface are bound is static data or dynamic data, and the dynamic data supports predefined data model data, atomic service data and combined service data in the display platform.

By adopting the technical scheme, each individual client specific service component is further abstracted into a general component, so that multiplexing and personalized secondary customization can be performed in the subsequent service. The brand experience, the system style, the user habit, the user availability scheme and the like related in the specific business are uniformly visualized into specific specifications of Layout (Layout) and elements (elements) such as color matching, fonts, word sizes, word weights, spacing, grids and the like, so that the subsequent flexible upgrading of the business system and new page design are supported. Especially in the energy industry, the invention realizes that products finally developed by different software developers can realize compatibility and data unification through a low-code platform.

Drawings

FIG. 1 is a schematic diagram of a custom data model data structure of a GUI model driven low code platform based on the energy industry of the present invention;

FIG. 2 is a system frame diagram of a GUI model driven low code platform based on the energy industry of the present invention;

FIG. 3 is a schematic diagram showing a comparison of a user-defined data model service layer architecture of a GUI model-driven low-code platform based on the energy industry;

FIG. 4 is a Graphical User Interface (GUI) model driven low code platform based on the energy industry, which is compared with the prior art Quickbase low code platform of different types.

Detailed Description

The present invention will be further described with reference to the drawings and specific examples for the purpose of facilitating understanding by those skilled in the art.

The low-code platform is a cloud service platform which supports development and deployment of software applications with little or no code and debugging of graphic-User-Interface (GUI) and other graphic elements. The core of low code platform development is rapid application development, automated application deployment and execution, and the use of model-driven design principles. The low-code platform reduces the use threshold of users by virtue of lower learning cost, improves the overall production efficiency of the platform, and reduces the cost of personnel training for enterprises. The high automation characteristic of the system also ensures the stability of development application, and enterprises do not need to spend excessive cost on the operation, maintenance and deployment of the platform.

The invention will implement a low code platform design for GUIs and other graphical elements. Services supported by it include the generation development and automation deployment of GUIs, etc., and the platform will follow the principles of WYSIWYG (What-You-See-Is-What-You-Get). The information and the data source of the graphical interface are abstracted into static data, the data are converted into the graphical interface by using a parser of the platform, the platform can realize the change of the interface by editing the static data, and finally a complete low-code platform aiming at the GUI is built.

As shown in fig. 2, the GUI model-driven low-code platform according to the present invention includes a GUI layer, a service layer, and a data model layer; the GUI layer comprises a visual interface layout module, an interface data holding module and a multi-interface integration module, the service layer comprises a self-defined atomic service module and a self-defined combined service module, and a self-defined data model is arranged in the data model layer; the custom atomic service module and the custom combined service module support contents for a user-oriented custom platform, and after a user changes a data model, a database synchronously updates a table structure of the data model, and data in the custom data model can be integrated into an interface in the form of a data source in an interface data binding stage. And when the data model in the data model layer is newly generated, generating corresponding CRUD service for the data model layer, judging whether a set associated data model exists, and if so, updating a corresponding associated database in the database. The custom data model supports a user to generate a data table by defining the attribute and basic information of the data model; after the data model is published, the system will generate a corresponding data table in the database. In order to manage data of a data model used in a low-code platform, a custom data model is designed for the platform, which supports a user to generate a data table by defining the attribute and basic information of the data model. After the data model is published, the system will generate a corresponding data table in the database.

1) Data structure

The data model in the platform is managed in units of applications, as in figure 1,

the DataInfo class stores all relevant information of the data model, including data such as names, attributes, items to which the data model belongs, attribute association relations, release states and the like. All data models stored in the database have the Project to which they belong, and Project class will store all relevant information about the Project, where the User id and User name of the creator will be stored, corresponding to the data in User class. For attribute information in DataInfo, we have designed Property class to hold his attribute name, type and information whether null is allowed. The attribute type supports five common types, char, int, double, bool, string. And the association information between the data models is stored by using a relationship class, and the information to be stored comprises association attribute names and association types, including one-to-one and many-to-many association relations.

2) Database connection

To enable automatic generation of data tables through a data model, we need to create a connection with the database. After the user confirms that the data model is released, the system establishes a link with the database, and generates a script according to the data model data, wherein the script comprises information of all attributes and associated information. After the script is generated, the script is run on the database connection, so that a data table corresponding to the data model data can be created in the database.

As shown in FIG. 3, the service layer of the custom data model of the platform of the present invention is demonstrated as distinct from conventional architecture designs. In order to improve the usability of the platform, the platform should support the data storage of Chinese, however, the database does not support the use of Chinese characters for the table structure, so we need to convert the Chinese characters here, the final result is that the Chinese characters are stored in the data model data, and the structure of the generated data table uses the pinyin converted into English.

The association information between the data models is stored in the Relation class, and when the data table is created, if the association Relation exists in the corresponding data model, the corresponding data table is generated according to all the stored association relations. The data table stores the id of the original table and the id of the association table.

Because the data tables are automatically generated, in addition to the management of the structure of the data tables, the SQL script needs to be run to realize the management of the data in the data tables, and the corresponding SQL script also needs to be run to realize the management of the data in the data tables. In contrast to using traditional code development, the platform needs to directly link all data tables generated to the database, rather than directly use the existing APIs.

For data within the data table, the platform will automatically generate data services based on Restful semantics, which are also implemented by running corresponding SQL scripts generated from the data model data.

The original development of the Controller, service and repositisource classes for all data models is performed by only designing a corresponding class for managing all data models. Since the platform needs to directly connect with the database, we do not use the Repository layer any more, but use a SQLHelper class to process the data request, including changing the data table structure, data services, etc. all database related operations.

3) Display layer

At the presentation layer of the custom data model, a user can view attribute information and associated information of the data model. The published data model is able to view the specific data stored in the data table at this point in the database. In addition, the platform also provides a function of querying a single data model by using query sentences, a user can add the query sentences aiming at all the attributes of the data model, and finally the platform can summarize all the query sentences to generate corresponding SQL scripts, and after the SQL scripts are operated, query results are returned.

The visual interface layout comprises an interface data model structure, an interface editor and an interface layout rendering tool. In view of the usability of the platform, the use process of the platform needs to be as friendly as possible, so in the stage of visual interface layout, a user hopes to browse the actually generated interface in real time when editing the interface. Thus, we propose that the visual interface layout should follow the "what you see is what you get" principle. In order to simplify the design operation of the user, we choose drag as the main operation method for editing the interface layout. For editing of styles of interface elements, we allow the user to directly edit CSS data of the corresponding component in the detail panel, thereby enabling custom editing of styles.

1) Interface data model structure

In the process of using the low-code platform, the data model and interface information are stored in units of items, so that the first step required by the user to do when using the low-code platform is to create the items. Classes associated with this portion of functionality are screened out here to focus on the visual interface layout.

(1) Layout class

From the interface, the Layout class stores abstract data of an interface, and the interface should have basic information such as item id, detailed description, release state and the like to which the interface belongs, and the atfront page indicates whether the interface should appear on the first page. In addition to this basic information, the Layout class also needs to save the DOM structure of the interface and its corresponding style. To systematically manage the DOM structure of an interface, we specify that the Layout class corresponds to pages in the DOM structure, and that the Container class stored in the Layout class corresponds to block elements in the HTML.

(2) Container class

The content class can be considered an abstract class of tile elements, and since the present design uses a act+antd framework, the Type in the content class corresponds to the interface element in the Antd framework. After analyzing the functional requirements of interface elements in the interface, we find that the functions required to be possessed by block elements in the use process of the interface are mainly to display data and input data, so we design two types of content which are relatively universal for Layout and Form, the former will be responsible for displaying data, and the latter will be responsible for collecting user input data.

(3) GuiComponent class

The guilcomponent class can be considered as all other elements in the interface that are embedded in the tile element. The guilcomponent class can only exist in the Container class, which also conforms to the nesting relationship between the two when actually rendered. Considering that different elements of HTML have a lot of general attributes, and all HTML elements can apply CSS, we have designed a guilcomponent class as a general abstract class of HTML elements, where static properties will correspond to attribute information of the element, while style properties will correspond to style information of a component, and displayName represents a name of the component shown in an editor.

Based on the guilcomponent class, we design unique classes for different elements to describe their corresponding features and functions, and we have designed abstract classes of five more representative elements, all inherited from guilcomponent class:

(a) Button: corresponding to the button element, since it will generally execute its bound callback function after clicking, it is obvious that using the button element to present data is not ideal, so it should only exist in Form type containers. For callback functions called by button elements, two types of callback functions can be analyzed by combining the use requirements of the platform. First, a service within the platform is invoked, its abstract data is saved in the Api attribute, and its type is the Api class. This class is a generic class of APIs that can be called inside the platform, which will be described in more detail below, since this part is related to the data binding of the interface. And secondly, a function which is jumped to other interfaces can be called, abstract data of the behavior is stored in a jumpindolayout attribute, the corresponding class is a jumpindolayout class, and the id of a target interface to be jumped and data source information which needs to be carried when the interface is jumped are stored in the class. Considering that API calls and interface jumps often occur simultaneously in an actual usage scenario, both are allowed to coexist in the Button class.

(b) Input: corresponding to the input box element. Like Button, it should only exist in the Form type Container class.

(c) Table: corresponding to the table element. We have found, after a summary, that the data they present is data that is obtained from applications at runtime, which is a number of possible sources, we abstract it into the DataSource class, and the principle of which will be described in the section of interface data binding. The use of table elements often entails, in addition to the presentation data, certain operations on the presentation data, such as allowing the user to click a button to view detailed data of the presentation data, or other operations. To support this behavior, we save buttons properties in the Table class to provide these operations. The operations supported by all data in the table element should be the same, e.g., each column of data in the dataset should have its corresponding view button, but the buttons themselves should be responsible for the same behavior and style, with the only difference being that the corresponding data is different. Thus, for these operations we can save their abstract information in units of table elements, and because these operations typically exist in the form of buttons we save multiple button elements in a table element. These Button elements are in complete agreement with the Button class's running logic, i.e., they also support application's API calls and interface jump calls, which also conform to the usage scenario of the table elements. Considering that a user may not want to expose all of the attributes of the data model when exposing data, we provide showFields attributes to save the data that the user wants to expose.

(d) Text: corresponding to the text element.

(e) Title: corresponding to the title element.

In addition, the invention also comprises an interface layout rendering tool, and after determining the main operation method using the drag interface element as the visual interface layout, we need to determine the implementation scheme and store the obtained position information in the database. We also need to ensure that the interface follows the principle of "what you see is what you get" so we also need to determine how to have canvas and an online interface render the same interface when facing the same piece of data. Therefore, the interface layout rendering tool comprises an element dragging tool;

The interface layout rendering tool comprises a DOM structure and CSS data synchronization tool, so that the Canvas area and the final online interface are ensured to have the same DOM structure and CSS data;

the Canvas area renderer should use Canvas as the root of the DOM structure, while the interface renderer needs to use the root element of the page as the root of the DOM structure, except that the same rendering logic should be used.

The invention also comprises a method for using the GUI model driven low-code platform based on the energy industry, each individual user manages the data model used in the platform, generates the data model, manages the relation between the models later, and the GUI developer performs visual layout on the interface in a dragging component mode, can selectively modify the style of the interface, so as to bind the data in the interface and select whether to set jump logic for the interface. The data bound when the data in the interface are bound are static data or dynamic data, and the dynamic data support the predefined data model data, atomic service data and combined service data in the display platform.

Example 1: according to the method, a prototype system is established, a specific enterprise digital transformation example is analyzed as experimental data, and the prototype system is realized through four steps of custom data model, visual interface layout, interface data binding and multi-interface integration. And comparing the prototype system with other low-code platforms according to the four steps, analyzing experimental results of the prototype system and the low-code platforms, and finally making effect evaluation of the prototype system, wherein the evaluation effect is as follows:

in order to conduct comparison analysis on the effectiveness of the GUI model driven low-code platform, the advantages and disadvantages of the GUI model driven low-code platform and other types of low-code platforms are compared through four aspects of a custom data model, a visual interface layout, interface data binding and multi-interface integration. By looking up the relevant literature [8], we choose to compare experimentally with the low code platforms driven by the GUI model, which belong to different types of Quickbase low code platforms. The advantages of the two in different aspects are respectively shown in fig. 4:

overall, we can derive that GUI model driven low code platforms perform better than Quickbase in functionality, mainly in three aspects of visual interface layout, interface data binding and multi-interface integration. The low-code platform driven by the GUI model needs to be improved in usability, and firstly, the user-defined data model can refer to the QuickBase to support visual editing of the data model. We can also refer to Quickbase to support components with larger granularity when designing components, while supporting components with larger granularity and smaller granularity will further improve the functionality and ease of use of the platform.

It is noted that relational terms such as first and second, and the like are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.

The above embodiments are merely for illustrating the technical solution of the present disclosure, and are not limiting thereof; although the present disclosure has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical scheme described in the foregoing embodiments can be modified or some technical features thereof can be replaced by equivalents; such modifications and substitutions do not depart from the spirit and scope of the corresponding technical solutions of the embodiments of the present disclosure.

Claims

1. The GUI model driven low-code platform based on the energy industry comprises a GUI layer, a service layer and a data model layer; the GUI layer comprises a visual interface layout module, an interface data retaining module and a multi-interface integration module, the service layer comprises a self-defined atomic service module and a self-defined combined service module, and a self-defined data model is arranged in the data model layer; the custom atomic service module and the custom combined service module support contents for a user-oriented custom platform, and after a user changes a data model, a database synchronously updates a table structure of the data model, and data in the custom data model can be integrated into an interface in the form of a data source in an interface data binding stage.

2. The GUI model driven low code platform based on the energy industry is characterized in that when the data model in the data model layer is newly generated, corresponding CRUD service is generated for the data model, whether a set associated data model exists or not is judged, and if yes, a corresponding associated database in a database is updated.

3. The GUI model driven low-code platform according to claim 1 or 2, wherein said custom data model supports a user to generate a data table by defining attributes and basic information of the data model; after the data model is published, the system will generate a corresponding data table in the database.

4. A GUI model driven low code platform according to claim 3, wherein the custom data model comprises at least a data structure, a database connection, a presentation layer.

5. The energy industry based GUI model driven low code platform of claim 1, wherein said visual interface layout comprises an interface data model structure, an interface editor, an interface layout rendering tool.

6. The GUI model driven low-code platform according to claim 5, wherein the interface data model structure supports a Layout class and a content class guilcomponent class.

7. The GUI model driven low-code platform of claim 5, wherein said interface layout rendering tool comprises an element drag tool;

8. The GUI model driven low-code platform according to claim 5, wherein said interface layout rendering tool comprises a DOM structure and CSS data synchronization tool to ensure that Canvas areas and final online interfaces have the same DOM structure and CSS data;

9. The application method of the GUI model driven low-code platform based on the energy industry is characterized in that each individual user manages the data model used in the platform, generates the data model and manages the relation between the models later, and GUI developers can carry out visual layout on the interface in a dragging component mode and can selectively modify the style of the interface so as to bind data in the interface and select whether jump logic is set for the interface.

10. The method for using a GUI model driven low-code platform according to claim 9, wherein the data bound when the data in the interface is bound is static data or dynamic data, and the dynamic data supports predefined data model data, atomic service data and combined service data in the display platform.