Low-code processing method and device, electronic equipment and storage medium
By employing a plug-in design and intersection strategy, the problem of bloated schemas in low-code platforms is solved, achieving lightweight runtime and efficient data parsing, and supporting flexible expansion and cross-platform adaptation.
Patent Information
- Application Number
- CN202511366178.2
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-09-23
- Publication Date
- 2026-01-23
AI Technical Summary
In existing low-code platforms, JSON-based schema design leads to bloated schemas, resulting in large, complex, and difficult-to-maintain runtime engines.
The runtime adopts a plug-in-based design, reduces the schema size through an intersection strategy, and uses a general parsing plugin and a target parsing plugin for the target application for rendering or logic parsing. The rendering logic and business logic are encapsulated in the plugins, and the runtime is only responsible for loading and scheduling the plugins.
It effectively reduces schema size, improves data parsing efficiency several times over, is lightweight at runtime, easy to maintain and upgrade, and supports flexible expansion and cross-platform compatibility.
Smart Images
Figure CN121387293A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to the field of software development technology, and in particular to a low-code processing method, apparatus, electronic device, and storage medium. Background Technology
[0002] Currently, most mainstream low-code platforms use JSON-based schemas as the core description carrier to define the application's interface structure, component attributes, behavioral logic, and data binding rules. Related technologies employ a union strategy to define the schema, meaning the schema is compatible with the schemas of various low-code products. This is achieved by integrating the unique fields, component types, attribute definitions, and logical descriptions of each product to form a super schema that includes the features of all compatible products. However, this union-based schema design necessitates the continuous absorption and inclusion of all the unique functions and customization requirements of the compatible products. This inevitably leads to extreme bloat and bulkiness of the schema. This bloat is then propagated and amplified to the general-purpose runtime engines that depend on this schema, making these core engines large, complex, and difficult to maintain. Summary of the Invention
[0003] This disclosure provides a low-code processing method, apparatus, electronic device, and storage medium to effectively reduce schema size and, through a pluggable runtime design, make the runtime more lightweight, easier to maintain, and easier to upgrade. The technical solution of this disclosure is as follows: According to a first aspect of the present disclosure, a low-code processing method is provided, comprising: In response to a request to process visual configuration information in a low-code platform, the editor of the low-code platform is loaded; Using the loaded editor, the visual configuration information is translated into target structure description information based on a preset configuration mode; the protocol fields in the preset configuration mode include extensible fields and core fields of various applications compatible with the low-code platform; Based on the runtime general parsing plugin and the target parsing plugin corresponding to the target application in the runtime, the target structure description information is rendered or logically parsed to obtain the visual configuration information adapted to the target component code corresponding to the target application.
[0004] In one possible implementation, the editor that loads the low-code platform includes: Load application plugins. During the loading process, scan the decorators declared by each application plugin. The decorators are used to mark the classes that can be injected by the application plugin. The application plugin is injected into the global inversion of control container, and the mapping relationship between the application plugin and the plugin identifier is stored in the global inversion of control container; Obtain the main application instance, and when the main application instance is started, obtain all contribution point instances from the global inversion of control container and perform cyclic scheduling; the hook functions declared by the contribution points correspond to the functions of the application plugins; After the cyclic scheduling completes the scheduling process for all contribution points, it is determined that the editor for the low-code platform has finished loading.
[0005] In one possible implementation, the method further includes: Based on the inversion of control technique, the decorator is used to mark the classes that can be injected and the interfaces that are declared for each application plugin. The mapping relationship between the classes and interfaces is registered based on the dependency injection container, and instances are automatically injected based on the dependency injection container.
[0006] In one possible implementation, the runtime-based general parsing plugin and the target parsing plugin corresponding to the target application in the runtime render or logically parse the target structure description information to obtain the visual configuration information adapted to the target component code corresponding to the target application, including: The core fields are parsed using the general parsing plugin, and the extensible fields are processed using the renderer plugin corresponding to the target application in the target parsing plugin, to obtain the visual configuration information adapted to the target component code corresponding to the target application.
[0007] In one possible implementation, the method further includes: During the initialization phase of the runtime, the runtime's general parsing plugin is loaded in a preset order; When the runtime processes the business logic or rendering components of the target application, the renderer plugin corresponding to the target application is dynamically loaded.
[0008] In one possible implementation, the method further includes: During the runtime destruction phase, in response to the destruction timing event of the loaded target plugin, the unified modeling language class diagram of the runtime is obtained; the loaded target plugin is any of the general parsing plugins or any of the renderer plugins; The inheritance relationship of the loaded target plugin is obtained based on the unified modeling language class diagram, and the inherited plugin destruction class is obtained based on the inheritance relationship; The loaded target plugin is destroyed according to the destruction processing strategy of the plugin destruction class.
[0009] In one possible implementation, the method further includes: In response to a new business field configured by the target application based on the extensible field, a parsing plugin for parsing the new business field is configured in the runtime, and the parsing plugin for the new business field is associated with and stored with the target application.
[0010] According to a second aspect of the present disclosure, a low-code processing apparatus is provided, comprising: An editor loading module is configured to execute a processing request in response to visual configuration information in a low-code platform and load the editor for the low-code platform. The structured description module is configured to use the loaded editor to translate the visual configuration information into target structured description information based on a preset configuration mode; the protocol fields in the preset configuration mode include extensible fields and core fields of various applications compatible with the low-code platform; The component code acquisition module is configured to execute a runtime-based general parsing plugin and a target parsing plugin corresponding to the target application in the runtime, to render or logically parse the target structure description information, and obtain the visual configuration information adapted to the target component code corresponding to the target application.
[0011] In one possible implementation, the editor loading module includes: The application plugin loading unit is configured to load application plugins. During the loading process, it scans the decorators declared by each application plugin. The decorators are used to mark the classes that can be injected by the application plugin. The application plugin injection unit is configured to inject the application plugin into the global inversion of control container and store the mapping relationship between the application plugin and the plugin identifier in the global inversion of control container. The contribution point scheduling unit is configured to retrieve the main application instance and, when the main application instance is started, retrieve all contribution point instances from the global inversion of control container for cyclic scheduling; the hook functions declared by the contribution points correspond to the functions of the application plugins. The editor loading unit is configured to perform scheduling processing on the loop to complete all contribution points and determine that the editor for the low-code platform has finished loading.
[0012] In one possible implementation, the device further includes: The dependency injection module is configured to perform operations based on inversion of control, using the decorator to mark the classes that each application plugin can inject and declare the dependent interfaces, registering the mapping relationship between the classes and interfaces based on the dependency injection container, and automatically injecting instances based on the dependency injection container.
[0013] In one possible implementation, the component code acquisition module includes: The component code acquisition unit is configured to execute the parsing of the core fields based on the general parsing plugin, and the processing of the extensible fields based on the renderer plugin corresponding to the target application in the target parsing plugin, to obtain the visualization configuration information adapted to the target component code corresponding to the target application.
[0014] In one possible implementation, the device further includes: The general parsing plugin loading module is configured to execute during the initialization phase of the runtime and load the general parsing plugins of the runtime in a preset order; The renderer plugin loading module is configured to dynamically load the renderer plugin corresponding to the target application when the runtime processes the business logic or rendering components of the target application.
[0015] In one possible implementation, the device further includes: The class diagram acquisition module is configured to execute during the destruction phase of the runtime, and in response to the destruction timing event of the loaded target plugin, acquire the unified modeling language class diagram of the runtime; the loaded target plugin is any of the general parsing plugins or any of the renderer plugins; The plugin destruction class acquisition module is configured to obtain the inheritance relationship of the loaded target plugin based on the unified modeling language class diagram, and obtain the inherited plugin destruction class based on the inheritance relationship; The plugin destruction module is configured to execute the destruction processing strategy according to the plugin destruction class to destroy the loaded target plugin.
[0016] In one possible implementation, the device further includes: An extension module is configured to execute a parsing plugin in response to a new business field configured by the target application based on the extensible field, and to associate and store the parsing plugin corresponding to the new business field with the target application during runtime.
[0017] According to a third aspect of the present disclosure, an electronic device is provided, comprising: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the method as described in any one of the first aspects above.
[0018] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided such that, when instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is enabled to perform any of the methods described in the first aspect of the present disclosure. According to a fifth aspect of the present disclosure, a computer program product is provided, including computer instructions that, when executed by a processor, cause a computer to perform the method described in any one of the first aspects of the present disclosure.
[0019] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects: In response to a request to process visual configuration information in a low-code platform, the editor of the low-code platform is loaded. Using the loaded editor, the visual configuration information is translated into target structure description information based on a preset configuration mode. The protocol fields in the preset configuration mode include extensible fields and core fields of various applications compatible with the low-code platform. Based on a runtime general parsing plugin and a target parsing plugin corresponding to the target application in the runtime, the target structure description information is rendered or logically parsed to obtain the visual configuration information adapted to the target component code corresponding to the target application. By removing redundant fields through intersection design, the schema size is effectively reduced, avoiding bloat and bulkiness, thereby improving data parsing efficiency by several times. Furthermore, by designing a pluggable runtime, specific rendering logic and business logic are encapsulated in plugins. The runtime kernel only needs to be responsible for loading and scheduling plugins, without needing to include all the unique functions of the compatible products. This makes the runtime more lightweight, concise, and easier to maintain and upgrade.
[0020] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description
[0021] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.
[0022] Figure 1 This is a schematic diagram illustrating an application environment according to an exemplary embodiment.
[0023] Figure 2This is a flowchart illustrating a low-code processing method according to an exemplary embodiment.
[0024] Figure 3 This is a layered schematic diagram illustrating a visual interface and editor according to an exemplary embodiment.
[0025] Figure 4 This is a schematic diagram illustrating the loading process of an editor in a low-code platform according to an exemplary embodiment.
[0026] Figure 5 This is a schematic diagram illustrating an inheritance-based plugin destruction process during a runtime destruction phase, according to an exemplary embodiment.
[0027] Figure 6 This is a schematic diagram of a class diagram of the Unified Modeling Language (UML) according to an exemplary embodiment.
[0028] Figure 7 This is a schematic diagram illustrating the inheritance relationship of a plugin destruction class according to an exemplary embodiment.
[0029] Figure 8 This is a block diagram of a low-code processing apparatus according to an exemplary embodiment.
[0030] Figure 9 This is a block diagram illustrating an electronic device for low-code processing according to an exemplary embodiment.
[0031] Figure 10 This is a block diagram illustrating an electronic device for low-code processing based on an exemplary embodiment. Detailed Implementation
[0032] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.
[0033] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.
[0034] Please see Figure 1 , Figure 1This is a schematic diagram illustrating an application environment according to an exemplary embodiment, such as... Figure 1 As shown, the application environment may include server 01 and terminal 02.
[0035] In an optional embodiment, server 01 can be used for low-code processing. Specifically, server 01 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN (Content Delivery Network), and big data and artificial intelligence platforms.
[0036] In an optional embodiment, terminal 02 can be used to provide a low-code visual configuration interface during low-code processing. Specifically, terminal 02 can be, but is not limited to, electronic devices such as smartphones, desktop computers, tablets, laptops, smart speakers, digital assistants, augmented reality (AR) / virtual reality (VR) devices, and smart wearable devices. Optionally, the operating system running on the electronic device can be, but is not limited to, Android, iOS, Linux, and Windows.
[0037] In addition, it should be noted that, Figure 1 The example shown is merely one application environment of the low-code processing method provided in this disclosure.
[0038] In the embodiments described in this specification, the server 01 and the terminal 02 can be directly or indirectly connected through wired or wireless communication, and this application does not impose any restrictions on this.
[0039] It should be noted that the following diagram illustrates one possible sequence of steps, and it is not strictly required to follow this order. Some steps can be performed in parallel without interdependence. The user information (including but not limited to user device information, user personal information, user behavior information, etc.) and data (including but not limited to data used for display, training data, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.
[0040] Before introducing the method embodiments provided in this application, a brief introduction will be given on the application scenarios, related terms or nouns that may be involved in the method embodiments of this application, so as to facilitate the understanding of those skilled in the art.
[0041] Low-Code: Low-Code Application Development Platform, also known as low-code application development platform. Schema: Data Schema / Interface Description Schema. JSON: JavaScript Object Notation. JSX (JavaScript XML): is a syntax extension for JavaScript, primarily used in the React framework to describe the structure and appearance of user interfaces. UI: User Interface. IoC (Inversion of Control) is a design principle in software engineering that aims to reduce coupling between code and improve system flexibility and maintainability. In traditional programming, objects typically create and manage their dependent objects. However, in the IoC pattern, objects no longer directly control the creation and lifecycle of their dependencies. The creation and assembly of dependencies are handled by an external container, and control is transferred from the application code to the container, hence the name "Inversion of Control".
[0042] DI: Dependency Injection. TS: TypeScript, a programming language.
[0043] API: Application Programming Interface. Runtime: The core engine that loads and runs the low-code schema at runtime.
[0044] Figure 2 This is a flowchart illustrating a low-code processing method according to an exemplary embodiment. For example... Figure 2 As shown, the low-code processing method may include the following steps.
[0045] In step S201, in response to a request to process the visual configuration information in the low-code platform, the editor of the low-code platform is loaded.
[0046] In the embodiments described in this specification, the visual configuration information may refer to the digital product or business system module built in the visual interface of the low-code platform. The low-code platform automatically completes the technical implementation through pre-built visual components, logic templates, and data links, ultimately producing "ready-to-use" digital products (such as management systems, business tools, data dashboards, etc.).
[0047] The processing request for visual configuration information can be triggered by the target business party, which may be the business party that built the visual configuration information. For example, the target business party needs to convert the visual configuration information into a processing request for the executable code corresponding to the target application. Exemplarily, the target application may be a mobile application, mini-program, web application, etc. under the target business party, and this disclosure does not limit it.
[0048] In one possible implementation, the target business party can trigger a request to process visual configuration information. The terminal can send the request to the server. In response to the request to process visual configuration information in the low-code platform, the server can load the editor of the low-code platform.
[0049] like Figure 3 As shown in the example, a layered architecture can be adopted, including a bottom dependency layer, an editor kernel layer, an editor plugin layer, and a built-in service layer. Each layer can work together through a contribution point mechanism and an IoC container. The descriptions of each layer are as follows.
[0050] The underlying dependency layer utilizes inversify and reflectMetadata for dependency injection, providing robust support for inter-module dependency management. Views are built using Lumino and @m-ui / react. Mobx and Mobx-react-tile are used for state management, ensuring consistency and real-time performance across modules. Inversify is a lightweight TypeScript / JavaScript-based dependency injection (DI) container, while reflect-metadata is a library for obtaining and setting metadata at runtime. Both are typically used in conjunction with inversify to configure dependencies via decorators. Lumino and @mui / react (Material-UI) are two front-end development tools from different domains, focusing on different technical scenarios. Lumino is better suited for building complex applications requiring "desktop-level interaction," while @mui / react is a tool for quickly implementing standardized UIs in React projects. MobX is a state management library based on the observer pattern, enabling automatic synchronization between state and UI through reactive programming. mobx-react-lite is a lightweight binding library for React functional components, providing tools to connect MobX state to React components. Combining the two allows for concise and efficient state management in React applications.
[0051] Editor kernel layer: Provides core capabilities such as application (e.g., target application) management, skeleton management, control management, shortcut key management, and command management. Application management is responsible for the entire lifecycle management of the low-code application; skeleton management is used to define and manage the application's page skeleton structure, providing a basic framework for page building; control management provides unified management of various controls available in the designer; shortcut key management implements the definition and response of various shortcut keys in the editor; command management is used to define and execute various operation commands in the editor, realizing modularity and reusability of functions.
[0052] Editor Plugin Layer: Used for extending editor functionality based on plugins. It can store and manage plugins for various editors, such as... Figure 3 The present disclosure does not limit the use of plugins A, B, and C. Built-in Service Layer: This layer provides core built-in services for direct communication between plugins. These services include an event bus and a data sharing service. The event bus allows plugins to communicate by publishing and subscribing to events, achieving decoupling between modules. The data sharing service provides a unified data storage and access interface, facilitating data sharing between plugins and ensuring data consistency and integrity.
[0053] In one alternative implementation, the editor loaded with the low-code platform described above may include: The application plugin is loaded, and during the loading process, the decorators declared by each application plugin are scanned; the decorators are used to mark the classes that the application plugin can inject; for example, the decorator may include the injectable decorator.
[0054] Furthermore, application plugins can be injected into a global inversion of control container (or global IoC container, globally unique IoC container), and the mapping relationship between application plugins and plugin identifiers can be stored in this global inversion of control container; whereby the plugin identifier can be used to uniquely identify the application plugin.
[0055] Obtain the main application instance, and when the main application instance is running, retrieve all contribution point instances from the global inversion of control container for cyclic scheduling; where the hook functions declared by the contribution points correspond to the functions of the application plugins and are used to implement the functions of the application plugins.
[0056] Finally, after the cyclic scheduling completes the scheduling of all contribution points, it can be determined that the editor of the low-code platform has finished loading.
[0057] For example, refer to Figure 4 After the framework starts, it can first load application plugins (e.g. Figure 3 In the context of plugins A through C, during the application plugin loading process, the `injectable` decorator declared by each plugin can be scanned, and the `register` method is called to inject the application plugin into the globally unique IoC container. The `injectable` decorator is used to mark injectable classes, and the `register` method associates these classes with their corresponding tokens (i.e., the plugin identifiers mentioned above). The IoC container stores a mapping table of all application plugins and tokens. After all application plugins are loaded, the main application instance is obtained and started. After the main application instance starts, it obtains instances of all application contribution points and performs a cyclical scheduling (e.g., ...). Figure 4The system determines whether the loop scheduling has ended by checking if the length of the contribution point array is greater than 0. The length of the contribution point array can refer to the number of contribution points to be invoked (here, the contribution points are in array format). These contribution points can be the mechanism used in this embodiment for interaction between the application plugin and the editor kernel. Each contribution point can declare different hook functions, such as initialization hooks, rendering hooks, and destruction hooks. During scheduling, the hook functions declared by the current contribution point are executed. For example, the initialization hook can perform plugin initialization configuration, and the rendering hook can perform UI element rendering. After scheduling all contribution points, the editor loading is complete. By decoupling the application plugin from the main program and dynamically injecting based on the contribution point mechanism, the editor can be customized.
[0058] In one possible implementation, the method may further include: using Inversion of Control (IoC) technology, using decorators to mark the classes that each application plugin can inject and declaring dependent interfaces, registering the mapping relationship between the classes and interfaces based on a dependency injection container, and automatically injecting instances based on the dependency injection container. By employing IoC technology, hard-coded dependencies between modules are converted into interface dependencies, enabling flexible adaptation to rapidly changing business needs.
[0059] In one example, to address the existing mesh dependency problem, this embodiment of the specification employs Inversion of Control (IoC) technology to convert hard-coded dependencies between modules into interface dependencies. For example, interface dependencies can be implemented based on the following interface definition.
[0060] Interface Definition: The consumer module depends only on the TypeScript interface, not the concrete implementation class, and defines the interaction contract through an abstract class. / / 1. Define the interface export abstract class Contribution {} Abstract classes implemented based on interfaces: Classes are marked as injectable using the `@injectable()` decorator, and internally, a Dependency Injection (DI) container registers the mapping between interfaces and their implementation classes. / / 2. Interface-based implementation @injectable() export class AContribution implement Contribution {} Dependency type consumption: The target module declares the dependency interface through the @inject() decorator, and the instance is automatically injected by the internal DI container. @injectable() export class Application { @inject() private contributions: Contributions[] } In step S203, the loaded editor is used to translate the visual configuration information into target structure description information based on the preset configuration mode.
[0061] In the embodiments of this specification, the preset configuration mode can refer to a schema. To avoid the schema bloat problem of existing union strategies, the embodiments of this specification adopt an intersection strategy. This intersection strategy can refer to selecting the intersection of the corresponding fields of various applications to obtain the fields with common requirements to set the core fields of the schema, effectively avoiding schema bloat. Based on this, for example, the protocol fields in the preset configuration mode can include extensible fields and core fields of various applications compatible with low-code platforms. This can both avoid schema bloat and be compatible with diverse business requirements based on extensible fields.
[0062] In one example, a standardized schema interface definition can define protocol fields that include core fields and extensible fields. For example, a table can be used to describe the functions and hierarchical calling relationships of the core fields and extensible fields. That is, the content defined below using the TypeScript interface specification can be described based on a table, and this disclosure does not limit it.
[0063] In another example, a standardized schema interface definition can define protocol fields that include core fields and extensible fields, which can be defined using the TypeScript interface specification, as shown below.
[0064] Schema Meta-information Structure / ** * Schema, describing the interface and its logic / export interface Schema { / ** * Extended fields, such as the page ID.
[0065] / / / eslint-disable-next-line @typescript-eslint / no-explicit-any [key: string]: any / ** * Schema version / schemaVersion: string / ** * The view, or root component of the component tree, is used to define the data structure for describing the visual configuration as a tree-like nested component structure. / view: SchemaComponent }
[0066] The schemaVersion field mentioned above is used for version management. When the underlying protocol is upgraded, the old schema version can be smoothly transitioned through the compatibility resolver. The view field uses a JSX-like data structure (such as a tree-like nested component), which aligns with the understanding of front-end developers and reduces the learning curve.
[0067] For example, the structure of the root component in the component tree described above can be implemented based on a further component definition structure. The core fields mentioned above can be considered as first-level fields, and the further component definition structure can be considered as second-level fields, which may also include extended fields to meet extended business needs. The component definition structure may include component definitions, extended fields, component types, component properties, and sub-components (which can be described using expressions), etc., which are not limited in this disclosure. Component properties can define dynamic properties (such as styles and data binding), supporting various modes such as static values, variable references, and function calculations. Sub-components can support nested components or expressions to generate text, achieving flexible interface layouts.
[0068] For example, in the expression-based sub-components described above, the expression can be configured with an expression definition structure, which can be viewed as a third-level field. For instance, the expression definition structure can include standardized expression definitions, extended fields, expression types, etc. This expression structure can support types such as static (static values), variable (variable references), and function (function evaluation), effectively covering a wide variety of business logic scenarios.
[0069] For example, for the extensible fields in the above layers, custom extensible fields can be reserved using `[key: string]: any`, allowing business users to add exclusive fields without modifying the underlying protocol. Here, `key` can be any custom value. For instance, a logistics low-code platform could add a tracking number validation rule field to the second-layer extensible fields for customized form validation logic; or, a medical low-code platform could extend the medical formula calculation type in the third-layer extensible fields to flexibly meet the needs of specific professional fields. In one possible implementation, a loaded editor can be used to translate the visual configuration information into target structure description information based on a preset configuration schema. For example, the editor can be used to translate the visual configuration information into a structured description of the preset configuration schema, thus obtaining the target structure description information. Exemplarily, this target structure description information can be stored in JSON format.
[0070] In step S205, based on the runtime general parsing plugin and the target parsing plugin corresponding to the target application in the runtime, the target structure description information is rendered or logically parsed to obtain visual configuration information adapted to the target component code corresponding to the target application.
[0071] In the embodiments of this specification, the general parsing plugin at runtime can refer to a parsing plugin used to implement basic runtime functions. The target parsing plugin corresponding to the target application at runtime can refer to a dedicated parsing plugin for the target business party corresponding to the target application, which can be used to parse the extended fields (i.e., extended fields) of the extended business of the target application.
[0072] In one possible implementation, the aforementioned runtime-based general parsing plugin and the target parsing plugin corresponding to the target application in the runtime, which render or logically parse the target structure description information to obtain the visual configuration information adapted to the target component code corresponding to the target application, may include: parsing the core fields based on the general parsing plugin, and processing the extensible fields based on the renderer plugin corresponding to the target application in the target parsing plugin to obtain the visual configuration information adapted to the target component code corresponding to the target application.
[0073] For example, the target structure description information is stored in JSON format, which naturally supports cross-language (such as Java, Python, JavaScript) and cross-platform (Web, Mini Program, Native App) parsing. Based on this, the core fields of the schema can be parsed through a general runtime (i.e., a general parsing plugin); the extended fields can be processed through the target business's dedicated renderer plugin (such as a React renderer or a Vue renderer) to obtain the target component code corresponding to the visual configuration information, which is adapted to the target application. Optionally, the target component code can be further converted into source code through a framework, that is, the executable code for the target platform can be generated in the end. By parsing the core fields based on the general parsing plugin and processing the extended fields based on the renderer plugin corresponding to the target application in the target parsing plugin, the visual configuration information is obtained and the target component code corresponding to the target application is obtained, so that the runtime can have both general parsing function and flexible adaptation to the extended needs of different business parties.
[0074] In response to a request to process visual configuration information in a low-code platform, the editor of the low-code platform is loaded. Using the loaded editor, the visual configuration information is translated into target structure description information based on a preset configuration mode. The protocol fields in the preset configuration mode include extensible fields and core fields of various applications compatible with the low-code platform. Based on a runtime general parsing plugin and a target parsing plugin corresponding to the target application in the runtime, the target structure description information is rendered or logically parsed to obtain the visual configuration information adapted to the target component code corresponding to the target application. By removing redundant fields through intersection design, the schema size is effectively reduced, avoiding bloat and bulkiness, thereby improving data parsing efficiency by several times. Furthermore, by designing a pluggable runtime, specific rendering logic and business logic are encapsulated in plugins. The runtime kernel only needs to be responsible for loading and scheduling plugins, without needing to include all the unique functions of the compatible products. This makes the runtime more lightweight, concise, and easier to maintain and upgrade.
[0075] In one possible implementation, the above method may further include: during the runtime initialization phase, loading the runtime's general parsing plugins in a preset order; and dynamically loading the renderer plugins corresponding to the target application when the runtime is processing the target application's business logic or rendering components. The timing of plugin loading and destruction can be reasonably arranged according to the runtime's lifecycle and business needs. During the runtime initialization phase, built-in plugins (i.e., general parsing plugins) are loaded in a preset order to provide basic functional support for the runtime. When the runtime needs to process the target application's business logic or render its components, the plugins corresponding to the target application can be dynamically loaded. This allows runtime plugin loading to be performed in stages, making plugin loading more orderly and enabling more rational use of processing resources.
[0076] Reference Figure 5 In one possible implementation, the above method may further include: In step S501, during the runtime destruction phase, in response to the destruction event of the loaded target plugin, the runtime Unified Modeling Language (UML) class diagram is obtained, for example... Figure 6 As shown; the target plugin loaded here can be any of the general parsing plugins or any of the renderer plugins described. For example, the destruction timing event may include events such as closing the page, which is not limited in this disclosure.
[0077] In step S503, the inheritance relationship of the loaded target plugin is obtained based on the class diagram of the Unified Modeling Language, and the inherited plugin destruction class is obtained based on the inheritance relationship; In step S505, the loaded target plugin is destroyed according to the destruction processing strategy of the plugin destruction class.
[0078] For example, refer to Figure 7 For example, after the plugin is loaded and running, if a destruction event is triggered, the inherited plugin destruction class can be called. Figure 7 The `dispose` class in the context can be used to destroy plugins loaded by the `Context`. Optionally, such as... Figure 7 As shown, the constructor can be used to describe the relationship between two objects in terms of inheritance, plugin, and destruction classes; however, this disclosure does not limit this.
[0079] By abstracting a plugin destruction class (for example) Figure 7 The `dispose` property in the `dispose` property is used to perform the destruction process triggered by the destruction timing. Because of the inheritance relationship, it only needs to be written once. In this way, during the runtime destruction phase, the loaded plugins can be destroyed one by one in a lightweight manner, releasing the occupied resources.
[0080] As an example, refer to Figure 6 UML class diagrams can be used to represent the runtime settings for preparing results, as described below.
[0081] Disposable base class: Provides an interface for destroying objects, ensuring the proper release of resources. Runtime: This refers to the general runtime mentioned above, which is responsible for loading, scheduling, and managing plugins and is the core of the entire architecture. Extensible base class: Serves as the place where plugins run, providing the basic functionality and interface for plugin extensions. Context: Serves as the context for expression execution, storing relevant runtime data and environment information, providing support for expression execution. Container: Corresponding to the entry object in the Schema (i.e., the root component of the component tree mentioned above), it is the root node for component rendering and is responsible for the organization and management of components. Component: Corresponds to the component definition in the Schema, encapsulating the component's attributes, behaviors, and rendering logic. ComponentController: Provides the component with the ability for conditional rendering and iterative rendering, controls the component's display and hiding, and manages data binding and updates.
[0082] in, Figure 6A solid line with a hollow triangle, where the hollow triangle points to the "parent class / interface" and the arrow points to the "child class," can represent an inheritance relationship. This means the child class inherits the attributes and methods of the parent class and can extend its own features. A solid diamond at one end (connecting the "whole class") and an arrow at the other end (pointing to the "part class") indicates a strong association between the whole and its parts. The part cannot exist independently of the whole, and its lifecycle depends entirely on the whole.
[0083] In one possible implementation, the method may further include: in response to a new business field configured by the target application based on the extensible field, configuring a parsing plugin for parsing the new business field at runtime, and associating the parsing plugin for the new business field with the target application for storage. This way, when functional iterations occur due to changes in the schema, only the corresponding plugin needs to be developed or updated at runtime, resulting in lower maintenance costs.
[0084] The embodiments described in this specification achieve the following effects: lightweight and efficient operation. By eliminating redundant fields through intersection design, the schema size is reduced by 60%-80% compared to existing solutions, and data parsing efficiency is improved by more than 3 times. Through plug-in design, specific rendering logic and business functions are encapsulated in plug-ins, and the runtime kernel only needs to be responsible for loading and scheduling plug-ins, without needing to include all the unique functions of compatible products. This makes the runtime more lightweight, concise, and easier to maintain and upgrade.
[0085] Flexible Expansion: Reserved customizable and extensible fields allow business users to quickly implement domain-specific functions without modifying the underlying protocol, shortening the development cycle by 50%; runtime plugins are developed and maintained independently. When a low-code / no-code product needs to iterate on features involving schema changes, only the corresponding plugin needs to be developed and updated, without relying on modifications to the general engine. This breaks through the single point of failure bottleneck in existing technologies, enabling each independent product to achieve agile development and rapid response to market demands.
[0086] Cross-platform compatibility: The JSON format and JSX-like structure are naturally compatible with multiple technology stacks, enabling one-click generation of code for multiple platforms such as Web, Mini Programs, and native Apps, reducing cross-platform development costs by 70%. Efficiently decoupling complex module structures: By employing Inversion of Control (IoC) and Dependency Injection (DI), direct dependencies between modules are transformed into dependencies on interfaces, achieving loose coupling between modules. In actual development, when a module needs to be modified or removed, there is no need to modify the source code of other dependent modules, greatly reducing code maintenance costs and improving system maintainability.
[0087] Powerful extensibility: Developers can easily extend the editor's functionality by defining plugins and contribution points. Whether it's adding new controls, customizing logic orchestration rules, or implementing new data interaction methods, all can be achieved by developing plugins without modifying the core source code.
[0088] Figure 8 This is a block diagram illustrating a low-code processing apparatus according to an exemplary embodiment. (Refer to...) Figure 8 The low-code processing device may include: The editor loading module 801 is configured to execute a processing request in response to visual configuration information in the low-code platform and load the editor of the low-code platform. The structured description module 803 is configured to use the loaded editor to translate the visual configuration information into target structured description information based on a preset configuration mode; the protocol fields in the preset configuration mode include extensible fields and core fields of various applications compatible with the low-code platform; The component code acquisition module 805 is configured to execute a runtime-based general parsing plugin and a target parsing plugin corresponding to the target application in the runtime, to render or logically parse the target structure description information, and obtain the visual configuration information adapted to the target component code corresponding to the target application.
[0089] In response to a request to process visual configuration information in a low-code platform, the editor of the low-code platform is loaded. Using the loaded editor, the visual configuration information is translated into target structure description information based on a preset configuration mode. The protocol fields in the preset configuration mode include extensible fields and core fields of various applications compatible with the low-code platform. Based on a runtime general parsing plugin and a target parsing plugin corresponding to the target application in the runtime, the target structure description information is rendered or logically parsed to obtain the visual configuration information adapted to the target component code corresponding to the target application. By removing redundant fields through intersection design, the schema size is effectively reduced, avoiding bloat and bulkiness, thereby improving data parsing efficiency by several times. Furthermore, by designing a pluggable runtime, specific rendering logic and business logic are encapsulated in plugins. The runtime kernel only needs to be responsible for loading and scheduling plugins, without needing to include all the unique functions of the compatible products. This makes the runtime more lightweight, concise, and easier to maintain and upgrade.
[0090] In one possible implementation, the editor loading module 801 may include: The application plugin loading unit is configured to load application plugins. During the loading process, it scans the decorators declared by each application plugin. The decorators are used to mark the classes that can be injected by the application plugin. The application plugin injection unit is configured to inject the application plugin into the global inversion of control container and store the mapping relationship between the application plugin and the plugin identifier in the global inversion of control container. The contribution point scheduling unit is configured to retrieve the main application instance and, when the main application instance is started, retrieve all contribution point instances from the global inversion of control container for cyclic scheduling; the hook functions declared by the contribution points correspond to the functions of the application plugins. The editor loading unit is configured to perform scheduling processing on the loop to complete all contribution points and determine that the editor for the low-code platform has finished loading.
[0091] In one possible implementation, the device may further include: The dependency injection module is configured to perform operations based on inversion of control, using the decorator to mark the classes that each application plugin can inject and declare the dependent interfaces, registering the mapping relationship between the classes and interfaces based on the dependency injection container, and automatically injecting instances based on the dependency injection container.
[0092] In one possible implementation, the component code acquisition module 805 may include: The component code acquisition unit is configured to execute the parsing of the core fields based on the general parsing plugin, and the processing of the extensible fields based on the renderer plugin corresponding to the target application in the target parsing plugin, to obtain the visualization configuration information adapted to the target component code corresponding to the target application.
[0093] In one possible implementation, the device may further include: The general parsing plugin loading module is configured to execute during the initialization phase of the runtime and load the general parsing plugins of the runtime in a preset order; The renderer plugin loading module is configured to dynamically load the renderer plugin corresponding to the target application when the runtime processes the business logic or rendering components of the target application.
[0094] In one possible implementation, the device may further include: The class diagram acquisition module is configured to execute during the destruction phase of the runtime, and in response to the destruction timing event of the loaded target plugin, acquire the unified modeling language class diagram of the runtime; the loaded target plugin is any of the general parsing plugins or any of the renderer plugins; The plugin destruction class acquisition module is configured to obtain the inheritance relationship of the loaded target plugin based on the unified modeling language class diagram, and obtain the inherited plugin destruction class based on the inheritance relationship; The plugin destruction module is configured to execute the destruction processing strategy according to the plugin destruction class to destroy the loaded target plugin.
[0095] In one possible implementation, the device may further include: An extension module is configured to execute a parsing plugin in response to a new business field configured by the target application based on the extensible field, and to associate and store the parsing plugin corresponding to the new business field with the target application during runtime.
[0096] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.
[0097] Figure 9 This is a block diagram illustrating an electronic device for low-code processing according to an exemplary embodiment. The electronic device may be a terminal, and its internal structure diagram may be as follows: Figure 9 As shown, the electronic device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a low-code processing method. The display screen can be a liquid crystal display (LCD) or an e-ink display. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the device's casing, or an external keyboard, touchpad, or mouse. Those skilled in the art will understand that Figure 9The structure shown is merely a block diagram of a portion of the structure related to the present disclosure and does not constitute a limitation on the electronic device to which the present disclosure is applied. A specific electronic device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.
[0098] Figure 10 This is a block diagram of an electronic device for low-code processing, based on an exemplary embodiment. The electronic device may be a server, and its internal structure diagram may be as follows: Figure 10 As shown, this electronic device includes a processor, memory, and a network interface connected via a system bus. The processor provides computing and control capabilities. The memory includes a non-volatile storage medium and internal memory. The non-volatile storage medium stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage medium. The network interface is used to communicate with external terminals via a network connection. When the computer program is executed by the processor, it implements a low-code processing method. Those skilled in the art will understand that Figure 10 The structure shown is merely a block diagram of a portion of the structure related to the present disclosure and does not constitute a limitation on the electronic device to which the present disclosure is applied. A specific electronic device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements. In an exemplary embodiment, an electronic device is also provided, including: a processor; and a memory for storing processor-executable instructions; wherein the processor is configured to execute the instructions to implement the low-code processing method as described in the embodiments of this disclosure.
[0099] In an exemplary embodiment, a computer-readable storage medium is also provided, which, when executed by a processor of an electronic device, enables the electronic device to perform the low-code processing method of the embodiments of this disclosure. The computer-readable storage medium may be a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, or optical data storage device, etc.
[0100] In an exemplary embodiment, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to perform the low-code processing method of the embodiments of this disclosure.
[0101] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. This computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM), etc.
[0102] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the following claims.
[0103] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.
Claims
1. A low-code processing method, characterized in that, include: In response to a request to process visual configuration information in a low-code platform, the editor of the low-code platform is loaded; Using the loaded editor, the visual configuration information is translated into target structure description information based on the preset configuration mode; The protocol fields in the preset configuration mode include extensible fields as well as core fields of various applications compatible with the low-code platform; Based on the runtime general parsing plugin and the target parsing plugin corresponding to the target application in the runtime, the target structure description information is rendered or logically parsed to obtain the visual configuration information adapted to the target component code corresponding to the target application.
2. The method according to claim 1, characterized in that, The editor that loads the low-code platform includes: Load application plugins. During the loading process, scan the decorators declared by each application plugin. The decorators are used to mark the classes that can be injected by the application plugin. The application plugin is injected into the global inversion of control container, and the mapping relationship between the application plugin and the plugin identifier is stored in the global inversion of control container; Obtain the main application instance, and when the main application instance is started, obtain all contribution point instances from the global inversion of control container and perform cyclic scheduling; the hook functions declared by the contribution points correspond to the functions of the application plugins; After the cyclic scheduling completes the scheduling process for all contribution points, it is determined that the editor for the low-code platform has finished loading.
3. The method according to claim 2, characterized in that, The method further includes: Based on the inversion of control technique, the decorator is used to mark the classes that can be injected and the interfaces that are declared for each application plugin. The mapping relationship between the classes and interfaces is registered based on the dependency injection container, and instances are automatically injected based on the dependency injection container.
4. The method according to claim 1, characterized in that, The runtime-based general parsing plugin and the target parsing plugin corresponding to the target application in the runtime render or logically parse the target structure description information to obtain the visual configuration information adapted to the target component code corresponding to the target application, including: The core fields are parsed using the general parsing plugin, and the extensible fields are processed using the renderer plugin corresponding to the target application in the target parsing plugin, to obtain the visual configuration information adapted to the target component code corresponding to the target application.
5. The method according to claim 1 or 4, characterized in that, The method further includes: During the initialization phase of the runtime, the runtime's general parsing plugin is loaded in a preset order; When the runtime processes the business logic or rendering components of the target application, the renderer plugin corresponding to the target application is dynamically loaded.
6. The method according to claim 5, characterized in that, The method further includes: During the runtime destruction phase, in response to the destruction timing event of the loaded target plugin, the unified modeling language class diagram of the runtime is obtained; the loaded target plugin is any of the general parsing plugins or any of the renderer plugins; The inheritance relationship of the loaded target plugin is obtained based on the unified modeling language class diagram, and the inherited plugin destruction class is obtained based on the inheritance relationship; The loaded target plugin is destroyed according to the destruction processing strategy of the plugin destruction class.
7. The method according to claim 1, characterized in that, The method further includes: In response to a new business field configured by the target application based on the extensible field, a parsing plugin for parsing the new business field is configured in the runtime, and the parsing plugin for the new business field is associated with and stored with the target application.
8. A low-code processing device, characterized in that, include: An editor loading module is configured to execute a processing request in response to visual configuration information in a low-code platform and load the editor for the low-code platform. The structured description module is configured to use the loaded editor to translate the visual configuration information into target structured description information based on a preset configuration mode; the protocol fields in the preset configuration mode include extensible fields and core fields of various applications compatible with the low-code platform; The component code acquisition module is configured to execute a runtime-based general parsing plugin and a target parsing plugin corresponding to the target application in the runtime, to render or logically parse the target structure description information, and obtain the visual configuration information adapted to the target component code corresponding to the target application.
9. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the method as described in any one of claims 1 to 7.
10. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is enabled to perform the method as described in any one of claims 1 to 7.
11. A computer program product, characterized in that, Includes computer instructions, which, when executed by a processor, cause the computer to perform the method as described in any one of claims 1 to 7.