A method, apparatus, device, and program product for implementing a low-code platform.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-04-10
- Publication Date
- 2026-08-14
AI Technical Summary
本申请提供的一种低代码平台的实现方法,包括:通过可视化设计器接收用户针对预设的平台元模型输入的应用界面配置指令,并生成元数据描述文件;不同的目标平台对应相同的元数据描述文件;获取用户选择的目标平台的平台类型;根据平台类型,将元数据描述文件转换为适用于目标平台的源代码。通过生成统一的元数据描述文件并基于平台类型自动转换源代码,解决了跨平台适配问题,具有能够通过统一的元数据描述文件适配不同目标平台,减少重复开发工作,降低维护复杂度,提高开发效率。
Smart Images

Figure CN122569903A_ABST
Abstract
Description
Technical Field
[0001] This application belongs to the field of computer software technology, and in particular relates to a method, apparatus, device and program product for implementing a low-code platform. Background Technology
[0002] Low-code development platforms significantly simplify the application building process by providing a visual drag-and-drop interface and a model-driven mechanism, enabling non-professional developers to participate in application development, effectively shortening the development cycle and lowering the technical threshold.
[0003] However, existing low-code platforms face significant challenges in practical applications, with the core issue being insufficient platform adaptability. Specifically, most low-code tools are optimized only for a single target platform (such as web applications or specific mobile operating systems), resulting in application configurations that are not universally applicable across different platforms. When developers need to deploy the same application to multiple platforms (e.g., extending from web to iOS or Android), they must redesign the interface layout, adjust data binding logic, and rewrite business rules. This not only creates a large amount of repetitive work but also significantly increases maintenance complexity and resource consumption. It is clear that existing low-code platforms offer limited convenience. Summary of the Invention
[0004] In view of this, this application provides a method, apparatus, device, and program product for implementing a low-code platform to solve the technical problem of low convenience of existing low-code platforms.
[0005] In a first aspect, embodiments of this application provide a method for implementing a low-code platform, comprising: The system receives application interface configuration instructions from the user for a preset platform metamodel through a visual designer and generates a metadata description file; different target platforms correspond to the same metadata description file; and obtains the platform type of the target platform selected by the user. Based on the platform type, the metadata description file is converted into source code suitable for the target platform.
[0006] Optionally, if the platform type is a first type, then converting the metadata description file into source code suitable for the target platform according to the platform type includes: Based on the platform type, determine the first target code generator; The first target code generator parses the metadata description file to determine the UI element information, layout information, data binding relationships, business logic relationships, and decoration attribute information corresponding to the metadata description file, and generates the source code based on the UI element information, layout information, data binding relationships, business logic relationships, and decoration attribute information.
[0007] Optionally, generating the source code based on the UI element information, the layout information, the data binding relationship, the business logic relationship, and the decoration attribute information includes: Based on the UI element information and the layout information, a first file of a first preset type for describing the interface structure is determined; Generate a second file of a second preset type used to describe the data binding relationship and the business logic relationship; Convert the decorative attribute information into a third file of a third preset type; The source code is generated based on the first file, the second file, and the third file.
[0008] Optionally, if the platform type is the second type, then converting the metadata description file into source code suitable for the target platform according to the platform type includes: Based on the platform type, determine the second target code generator; The metadata description file is loaded by the second target code generator, and the metadata description file is converted into intermediate representation data; For each first element in the intermediate representation data, according to a preset mapping rule library, the first element is converted into a first sub-code suitable for the target platform; for each first attribute in the intermediate representation data, according to the mapping rule library, the first attribute is converted into a second sub-code suitable for the target platform; and according to the mapping rule library, the first layout information corresponding to the intermediate representation data is converted into a third sub-code suitable for the target platform. The source code is determined based on the first sub-code corresponding to each of the first elements, the second sub-code corresponding to each of the first attributes, and the third sub-code.
[0009] Optionally, the mapping rule base includes element type mapping relationships, which describe the relationship between the type of the first element in the intermediate representation data and the type of the second element in the target platform; the step of converting the first element into a first sub-code suitable for the target platform according to the preset mapping rule base includes: Based on the element type mapping relationship and the type of the first element, determine the type of the second element corresponding to the first element; The first sub-code is determined based on the type of the second element corresponding to the first element.
[0010] Optionally, the mapping rule base includes an attribute conversion rule table, which describes the relationship between the type of the first attribute in the intermediate representation data and the type of the second attribute in the target platform; the step of converting the first attribute into a second sub-code suitable for the target platform according to the mapping rule base includes: Based on the attribute conversion rule table and the type of the first attribute, determine the type of the second attribute corresponding to the first attribute; The second sub-code is determined based on the type of the second attribute corresponding to the first attribute.
[0011] Optionally, the mapping rule base includes a layout adaptation algorithm, which describes the relationship between the first layout information and the second layout information of the target platform; the step of converting the first layout information corresponding to the intermediate representation data into third sub-code suitable for the target platform includes: Based on the layout adaptation algorithm, the second layout information corresponding to the first layout information is determined; The third sub-code is determined based on the second layout information corresponding to the first layout information.
[0012] Secondly, embodiments of this application provide an implementation apparatus for a low-code platform, comprising: The metadata description file generation unit is used to receive application interface configuration instructions input by the user for a preset platform metamodel through a visual designer, and generate a metadata description file; different target platforms correspond to the same metadata description file; and obtain the platform type of the target platform selected by the user; The conversion unit is used to convert the metadata description file into source code suitable for the target platform according to the platform type.
[0013] Thirdly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the low-code platform implementation method as described in any of the first aspects above.
[0014] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the low-code platform implementation method as described in any of the first aspects above.
[0015] Fifthly, embodiments of this application provide a computer program product that, when run on a control device, causes the control device to perform the steps of the low-code platform implementation method as described in any of the first aspects above.
[0016] The implementation method, apparatus, device, and program product of a low-code platform provided in this application have the following beneficial effects: This application provides a method for implementing a low-code platform, comprising: receiving application interface configuration instructions input by a user for a preset platform metamodel through a visual designer, and generating a metadata description file; different target platforms correspond to the same metadata description file; obtaining the platform type of the target platform selected by the user; and converting the metadata description file into source code suitable for the target platform according to the platform type. By generating a unified metadata description file and automatically converting the source code based on the platform type, the cross-platform adaptation problem is solved. It has the ability to adapt to different target platforms through a unified metadata description file, reducing repetitive development work, lowering maintenance complexity, and improving development efficiency. Attached Figure Description
[0017] To more clearly illustrate the technical solutions in the embodiments of this application, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 A flowchart illustrating the implementation method of the low-code platform provided in this application embodiment; Figure 2 A schematic diagram of the structure of an implementation device for a low-code platform provided in an embodiment of this application; Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation
[0019] It should be noted that the terminology used in the embodiments of this application is only for explaining specific embodiments of this application and is not intended to limit this application. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more, "at least one" or "one or more" means one, two or more. The terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.
[0020] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.
[0021] In the application development process of low-code platforms, the singular design of the platform's metamodel means that the generated metadata description files can only adapt to specific types of target platforms. This platform dependency necessitates re-executing the interface configuration process when the target platform type changes, leading to breaks in the development workflow and the non-reusability of configuration data. Furthermore, this issue directly weakens the cross-platform adaptability of the system architecture, making it impossible for the low-code platform to maintain consistency in metadata description files across heterogeneous target environments, thus affecting the continuous optimization of development efficiency and the rational utilization of resources.
[0022] For example, when developing cross-platform mobile applications, users complete the layout of interface elements and configuration of business logic through a visual designer, generating a metadata description file. When the target platform is iOS, this metadata description file is converted into Swift source code; if it needs to be adapted to the target platform Android, the application interface configuration instructions must be re-entered to generate a new metadata description file, and the original file cannot be directly reused. In this scenario, the switching of platform types causes the binding relationship between the metadata description file and the target platform to be unable to be decoupled, resulting in the same application interface configuration needing to be executed repeatedly for different platforms, causing redundancy in the development process and fragmentation of configuration data.
[0023] If the above issues are not addressed, the technical scalability of low-code platforms in multi-platform application scenarios will be fundamentally constrained, and the flexibility and maintainability of the system architecture will be significantly reduced. Consequently, the single-source nature of the platform metamodel may lead to the duplication of technical solutions and inefficient resource allocation, thereby hindering the large-scale deployment of low-code technology in heterogeneous environments.
[0024] To address the above issues, this application provides a method for implementing a low-code platform. The execution entity of this low-code platform implementation method can be an electronic device, which may include, but is not limited to, laptops, desktop computers, tablets, and mobile phones.
[0025] Please see Figure 1 , Figure 1 The flowchart illustrates the implementation method of the low-code platform provided in this application embodiment. The implementation method of the low-code platform provided in this application embodiment may include S101~S102, as detailed below: In S101, the application interface configuration instructions input by the user for the preset platform metamodel are received through the visual designer, and a metadata description file is generated; different target platforms correspond to the same metadata description file; the platform type of the target platform selected by the user is obtained.
[0026] In this embodiment, the visual designer is a core component of the low-code platform, which allows users to interact through a graphical interface, such as dragging and clicking, to design the user interface and business logic of the application in an intuitive way.
[0027] A platform metamodel is a predefined set of abstract rules and structures used to describe the common components, attributes, behaviors, and relationships of an application. This metamodel is independent of specific programming languages or target platforms, providing a foundation for a unified description of applications.
[0028] Application interface configuration commands are the operation commands or data generated by users when designing and configuring the functionality of an application interface through a visual designer. These commands reflect the user's intent regarding interface elements, layout, data binding, and business logic.
[0029] Metadata description files are application design information stored in a structured form, generated based on application interface configuration instructions. These files contain abstract descriptions of the application's UI elements, layout, data binding relationships, and business logic. A key characteristic is their independence from specific programming languages or target platforms, thus achieving decoupling between design and implementation.
[0030] The target platform refers to the specific environment in which the application ultimately runs, such as cross-platform desktop apps (Windows / Linux), cross-platform mobile apps (Android / iOS / HarmonyOS), and websites (Vue.js).
[0031] Platform type is a specific classification identifier for a target platform, used to distinguish different operating environments and technology stacks. For example, Web platform, iOS platform, and Android platform can all be considered different platform types.
[0032] This method receives application interface configuration instructions from users for a preset platform metamodel through a visual designer and generates metadata description files.
[0033] In one implementation, the visual designer can provide a basic component library that users can drag and drop onto the canvas and manually set the component properties and events. For example, a user can drag a text box component and a button component, and then manually enter the initial value for the text box and the click event handling logic for the button. This manually configured information is then parsed and organized into a structured metadata description file.
[0034] In another implementation, the visual designer can provide a form-based configuration interface where users define the application's UI elements, layout, and basic logic by filling in form fields. For example, a user can select "Add a list" in the form, then define fields for list items and manually specify the data source. This form input is converted into a metadata description file. Notably, this metadata description file is designed to be independent of specific programming languages or target platforms, meaning different target platforms can correspond to the same metadata description file, thus achieving platform neutrality at the design level.
[0035] In S102, the metadata description file is converted into source code suitable for the target platform, based on the platform type.
[0036] In this embodiment of the application, after generating the metadata description file, the electronic device can convert the metadata description file into source code suitable for the target platform according to the platform type.
[0037] In one possible implementation, if the platform type is the first type, the metadata description file is converted into source code suitable for the target platform according to the platform type, including: determining a first target code generator according to the platform type; parsing the metadata description file through the first target code generator to determine the UI element information, layout information, data binding relationship, business logic relationship and decoration attribute information corresponding to the metadata description file, and generating source code according to the UI element information, layout information, data binding relationship, business logic relationship and decoration attribute information.
[0038] The first type refers to a specific target platform category, such as cross-platform desktop apps and cross-platform mobile apps.
[0039] This type of platform typically requires the generation of structured code files, including user interface components, style definitions, and interaction logic. The first target code generator is a software module or tool specifically designed and implemented for this type of platform. Its core function is to convert generic metadata description files into source code that can be recognized and executed by this specific platform.
[0040] The solution proposed in this application equips a dedicated first target code generator for a specific platform type (Type 1), enabling the accurate parsing of generic metadata description files. This generator deeply understands the UI elements, layout, data binding, business logic, and decoration attributes contained in the metadata, and based on this detailed information, generates highly adapted source code according to the specifications and requirements of Type 1 platform. This mechanism ensures that the conversion process from abstract application interface configuration instructions to platform-specific executable code is efficient and accurate, effectively solving the complexity and accuracy problems of converting generic metadata to platform-specific code. In this way, generic application configuration instructions are transformed into platform-specific recognizable and executable code, thereby resolving the complexity and accuracy issues of converting generic metadata to platform-specific code.
[0041] This application further proposes a step for generating source code based on UI element information, layout information, data binding relationships, business logic relationships, and decoration attribute information, including: determining a first file of a first preset type for describing the interface structure based on UI element information and layout information; generating a second file of a second preset type for describing data binding relationships and business logic relationships; and converting decoration attribute information into a third file of a third preset type. Generate source code based on the first, second, and third files.
[0042] Specifically, based on UI element information and layout information, a first file of a first preset type is determined to describe the interface structure. This file aims to transform the interface elements (e.g., buttons, text boxes, images, etc.) defined by the user in the visual designer and their arrangement on the interface (e.g., relative position, size, hierarchy, etc.) into a structured file format. This file is specifically used to describe the static structure of the user interface, achieving separation between the interface and the logic.
[0043] A second file of a second preset type is generated to describe data binding relationships and business logic relationships. This file is used to abstract and encapsulate the association between UI elements and backend data (data binding) and the business processing flow (business logic) triggered by user interaction into a separate file. This helps to separate data flow and behavioral logic from the UI structure, improving code clarity and reusability.
[0044] Converting decorative attribute information into a third-preset type of third file aims to isolate the visual attributes such as styles, themes, and animation effects set by the user for interface elements, forming a dedicated style file. This separation allows the appearance of the interface to be modified and managed independently of its structure and logic, facilitating functions such as theme switching and responsive design.
[0045] The final code generation step involves generating the source code based on the first, second, and third files. This step integrates the interface structure files, logic files, and style files generated in the previous steps to form a complete and executable source code for the target platform.
[0046] This application's solution refines and categorizes UI element information, layout information, data binding relationships, business logic relationships, and decorative attribute information in the metadata description file. Specifically, UI element information and layout information are used to construct a first file of a first preset type describing the interface structure, focusing on the static skeleton of the interface. Simultaneously, data binding relationships and business logic relationships are independently generated as a second file of a second preset type, carrying the dynamic behavior and data interaction logic of the interface. Furthermore, decorative attribute information is converted into a third file of a third preset type, specifically responsible for the visual presentation of the interface. Finally, the first, second, and third files are integrated to generate source code suitable for the target platform. This divide-and-conquer strategy makes the source code generation process more modular and structured. By encapsulating the interface structure, business logic, and visual styles into different files, not only is the readability and maintainability of the generated code improved, but it also greatly facilitates subsequent development, debugging, and iteration. For example, when only the interface style needs modification, developers only need to focus on the third file; when the business logic changes, the second file is mainly modified without affecting the interface structure or style, thereby effectively reducing code coupling and improving development efficiency and code quality. This separation of concerns design allows the conversion process from a unified metadata description file to platform-specific source code to better adapt to the modularity and scalability requirements of modern software engineering.
[0047] This application further proposes that if the platform type is a second type, the metadata description file is converted into source code suitable for the target platform according to the platform type, including: determining a second target code generator according to the platform type; loading the metadata description file through the second target code generator and converting the metadata description file into intermediate representation data; for each first element in the intermediate representation data, converting the first element into first sub-code suitable for the target platform according to a preset mapping rule library, and for each first attribute in the intermediate representation data, converting the first attribute into second sub-code suitable for the target platform according to the mapping rule library, and converting the first layout information corresponding to the intermediate representation data into third sub-code suitable for the target platform according to the mapping rule library; and determining the source code based on the first sub-code corresponding to each first element, the second sub-code corresponding to each first attribute, and the third sub-code.
[0048] The second type refers to a specific target platform category, such as a website.
[0049] The second target code generator is a code generation module or tool specifically designed for second-type platforms. Its function is to execute specific transformation logic based on the characteristics and requirements of the second-type platform.
[0050] Loading metadata description files refers to reading previously generated, platform-independent metadata description files into memory for subsequent processing.
[0051] The transformation of metadata description files into intermediate representation data is a crucial abstraction layer. Intermediate representation (IR) is a structured and standardized internal representation of the metadata description file, independent of the original metadata format and the final target platform code. The role of IR is to provide a unified and easily processed data model, facilitating subsequent transformations and code generation.
[0052] For example, an IR can be an abstract syntax tree (AST), a unified component model (such as a UI component tree), or a graph structure that contains all UI elements, attributes, layouts, and logical relationships.
[0053] For each first element in the intermediate representation data, "first element" refers to the basic building block that constitutes the application interface, such as buttons, text boxes, images, containers, etc. Processing each first element means that the code generation process is based on these basic units.
[0054] Based on a pre-defined mapping rule base, which is a knowledge base storing rules for transforming intermediate representation data into target platform code, this system defines how to convert abstract elements, attributes, and layouts into concrete implementations on the target platform. For example, it can be a database, a collection of configuration files, or a program module containing mapping logic. The process of converting this first element into first sub-code suitable for the target platform involves transforming abstract elements in the intermediate representation data into target platform-specific code snippets.
[0055] In one possible implementation, the mapping rule base includes an element type mapping relationship, which describes the relationship between the type of a first element in the intermediate representation data and the type of a second element in the target platform. According to the preset mapping rule base, the first element is converted into a first sub-code applicable to the target platform, including: determining the type of the second element corresponding to the first element based on the element type mapping relationship and the type of the first element; and determining the first sub-code based on the type of the second element corresponding to the first element.
[0056] The mapping rule base is the core knowledge base used to guide metadata transformation. Element type mapping is an important component of this knowledge base, and its function is to establish the correspondence between abstract UI element types in intermediate representation data and specific UI element types in a particular target platform.
[0057] For each first attribute in the intermediate representation data, where "first attribute" refers to a parameter in the intermediate representation data that describes the characteristics of the first element, such as the button's text, color, size, click event, etc., the first attribute is converted into second sub-code suitable for the target platform. This is the process of converting the abstract attributes in the intermediate representation data into target platform-specific code snippets.
[0058] In one possible implementation, the mapping rule base includes an attribute transformation rule table, which describes the relationship between the type of a first attribute in the intermediate representation data and the type of a second attribute in the target platform. The mapping rule base is used to convert the first attribute into a second sub-code suitable for the target platform, including: determining the type of the second attribute corresponding to the first attribute based on the attribute transformation rule table and the type of the first attribute; and determining the second sub-code based on the type of the second attribute corresponding to the first attribute.
[0059] The attribute conversion rule table is a data structure used to store and manage a collection of attribute type mapping relationships between different platforms. It defines the conversion rules from general attribute types in intermediate representation data to specific attribute types in a particular target platform.
[0060] The first layout information corresponding to the intermediate representation data is converted into third sub-code suitable for the target platform. The "first layout information" refers to the data in the intermediate representation data that describes the arrangement and positional relationships of interface elements. Converting it into "third sub-code" means generating layout code specific to the target platform.
[0061] In one possible implementation, the mapping rule base includes a layout adaptation algorithm for describing the relationship between first layout information and second layout information of the target platform; the conversion of the first layout information corresponding to the intermediate representation data into third sub-code applicable to the target platform includes: determining the second layout information corresponding to the first layout information according to the layout adaptation algorithm; and determining the third sub-code according to the second layout information corresponding to the first layout information.
[0062] The mapping rule base is a collection of knowledge used to guide the transformation of intermediate representation data into the source code of the target platform. Building upon this, the mapping rule base further includes a layout adaptation algorithm. The layout adaptation algorithm is a logic or model specifically designed to handle interface layout transformations. Its function is to intelligently convert one layout description form (e.g., a platform-independent general layout description) into another layout description form (e.g., a layout description supported by a specific target platform).
[0063] Based on the first sub-code corresponding to each first element, and the second and third sub-code corresponding to each first attribute, the source code is determined. This is the process of combining all the generated sub-code fragments to form the final, complete source code suitable for the target platform. This typically involves operations such as code splicing, template filling, and file organization to generate a complete, compileable, or runnable project file.
[0064] The proposed solution first identifies the target platform as a second type and then invokes a specialized second target code generator. This generator does not directly convert metadata into source code; instead, it first converts the platform-independent metadata description file into structured intermediate representation data. This intermediate representation data acts as a standardized bridge, decoupling the input metadata format from the final target platform code. Subsequently, this intermediate representation data is systematically processed, querying a pre-defined mapping rule base for each first element, first attribute, and first layout information. This rule base defines how to convert these abstract concepts into first, second, and third sub-codes specific to the second-type target platform. Finally, these generated sub-code fragments are intelligently assembled to generate complete source code. This multi-stage, rule-driven approach ensures that even the complex and diverse needs of second-type platforms can be met efficiently and accurately, significantly improving the flexibility and maintainability of code generation and solving the adaptability problems that direct conversion might face.
[0065] As can be seen from the above, the low-code platform implementation method provided in this application includes: receiving application interface configuration instructions input by the user for a preset platform metamodel through a visual designer, and generating a metadata description file; different target platforms correspond to the same metadata description file; obtaining the platform type of the target platform selected by the user; and converting the metadata description file into source code suitable for the target platform according to the platform type. By generating a unified metadata description file and automatically converting the source code based on the platform type, the cross-platform adaptation problem is solved. It has the ability to adapt to different target platforms through a unified metadata description file, reducing repetitive development work, reducing maintenance complexity, and improving development efficiency.
[0066] Based on the low-code platform implementation method provided in the above embodiments, this application further provides an implementation apparatus for the low-code platform that implements the above method embodiments. Please refer to [link to relevant documentation]. Figure 2 , Figure 2 This is a schematic diagram of the structure of an implementation device for a low-code platform provided in an embodiment of this application. Figure 2 As shown, the implementation device 20 for the low-code platform may include: a description file generation unit 21 and a conversion unit 22. Wherein: The description file generation unit 21 is used to receive application interface configuration instructions input by the user for the preset platform metamodel through the visual designer and generate metadata description files; different target platforms correspond to the same metadata description file; and obtain the platform type of the target platform selected by the user.
[0067] The conversion unit 22 is used to convert the metadata description file into source code suitable for the target platform, based on the platform type.
[0068] Optionally, if the platform type is type 1, the conversion unit 22 is specifically used for: Determine the primary target code generator based on the platform type; The first target code generator parses the metadata description file to determine the UI element information, layout information, data binding relationships, business logic relationships, and decoration attribute information corresponding to the metadata description file, and generates source code based on the UI element information, layout information, data binding relationships, business logic relationships, and decoration attribute information.
[0069] Optionally, the conversion unit 22 is specifically used for: Based on UI element information and layout information, determine the first file of the first preset type used to describe the interface structure; Generate a second file of a second preset type used to describe data binding relationships and business logic relationships; Convert the decoration attribute information into a third file of a third preset type; Generate source code based on the first, second, and third files.
[0070] Optionally, if the platform type is type two, the conversion unit 22 is specifically used for: Determine the second target code generator based on the platform type; The metadata description file is loaded through the second target code generator, and the metadata description file is converted into intermediate representation data; For each first element in the intermediate representation data, according to the preset mapping rule library, the first element is converted into a first sub-code suitable for the target platform. For each first attribute in the intermediate representation data, according to the mapping rule library, the first attribute is converted into a second sub-code suitable for the target platform. And according to the mapping rule library, the first layout information corresponding to the intermediate representation data is converted into a third sub-code suitable for the target platform. The source code is determined based on the first sub-code corresponding to each first element, the second sub-code corresponding to each first attribute, and the third sub-code.
[0071] Optionally, the mapping rule base includes element type mapping relationships, which describe the relationship between the type of the first element in the intermediate representation data and the type of the second element in the target platform; the conversion unit 22 is specifically used for: Based on the element type mapping relationship and the type of the first element, determine the type of the second element corresponding to the first element; The first sub-code is determined based on the type of the second element corresponding to the first element.
[0072] Optionally, the mapping rule base includes an attribute transformation rule table, which describes the relationship between the type of the first attribute in the intermediate representation data and the type of the second attribute in the target platform; the transformation unit 22 is specifically used for: Based on the attribute conversion rule table and the type of the first attribute, determine the type of the second attribute corresponding to the first attribute; The second sub-code is determined based on the type of the second attribute corresponding to the first attribute.
[0073] Optionally, the mapping rule base includes a layout adaptation algorithm, which describes the relationship between the first layout information and the second layout information of the target platform; the conversion unit 22 is specifically used for: Based on the layout adaptation algorithm, determine the second layout information corresponding to the first layout information; The third sub-code is determined based on the second layout information corresponding to the first layout information.
[0074] It should be noted that the information interaction and execution process between the above-mentioned units are based on the same concept as the method embodiments of this application. Their specific functions and technical effects can be referred to the method embodiments section, and will not be repeated here.
[0075] Please see Figure 3 , Figure 3 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 3 As shown, the electronic device 3 provided in this embodiment may include: a processor 30, a memory 31, and a computer program 32 stored in the memory 31 and executable on the processor 30, such as a program corresponding to the implementation method of a low-code platform. When the processor 30 executes the computer program 32, it implements the steps described above in the implementation method embodiment applied to the low-code platform, for example... Figure 1 S101~S102 are shown. Alternatively, when the processor 30 executes the computer program 32, it implements the functions of each module / unit in the above-described low-code platform implementation device embodiment, for example... Figure 2 The functions of units 21-22 shown.
[0076] For example, computer program 32 can be divided into one or more modules / units, one or more of which are stored in memory 31 and executed by processor 30 to complete this application. One or more modules / units can be a series of computer program instruction segments capable of performing specific functions, which describe the execution process of computer program 32 in electronic device 3. For example, computer program 32 can be divided into a description file generation unit 21 and a conversion unit 22; the specific functions of each unit are described in [reference needed]. Figure 2 The relevant descriptions in the corresponding embodiments are not repeated here.
[0077] Those skilled in the art will understand that Figure 3 This is merely an example of electronic device 3 and does not constitute a limitation on electronic device 3. It may include more or fewer components than shown, or combine certain components, or use different components.
[0078] The processor 30 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.
[0079] The memory 31 can be an internal storage unit of the electronic device 3, such as a hard disk or RAM. The memory 31 can also be an external storage device of the electronic device 3, such as a plug-in hard disk, smart media card (SMC), secure digital (SD) card, or flash card. Furthermore, the memory 31 can include both internal and external storage units of the electronic device 3. The memory 31 is used to store computer programs and other programs and data required by the electronic device. The memory 31 can also be used to temporarily store data that has been output or will be output.
[0080] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units is merely an example. In practical applications, the above functions can be assigned to different functional units as needed, that is, the internal structure of the low-code platform implementation device can be divided into different functional units to complete all or part of the functions described above. The functional units in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.
[0081] This application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, can implement the steps in the various method embodiments described above.
[0082] This application provides a computer program product that, when run on a terminal device, enables the terminal device to implement the steps described in the various method embodiments above.
[0083] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, refer to the relevant descriptions of other embodiments.
[0084] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0085] The above-described embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.
Claims
1. A method for implementing a low-code platform, characterized in that, include: The visual designer receives application interface configuration instructions from users for the preset platform metamodel and generates metadata description files. Different target platforms correspond to the same metadata description file; Obtain the platform type selected by the user for the target platform; Based on the platform type, the metadata description file is converted into source code suitable for the target platform.
2. The method according to claim 1, characterized in that, If the platform type is the first type, then converting the metadata description file into source code suitable for the target platform according to the platform type includes: Based on the platform type, determine the first target code generator; The first target code generator parses the metadata description file to determine the UI element information, layout information, data binding relationships, business logic relationships, and decoration attribute information corresponding to the metadata description file, and generates the source code based on the UI element information, layout information, data binding relationships, business logic relationships, and decoration attribute information.
3. The method according to claim 2, characterized in that, The step of generating the source code based on the UI element information, the layout information, the data binding relationship, the business logic relationship, and the decoration attribute information includes: Based on the UI element information and the layout information, a first file of a first preset type for describing the interface structure is determined; Generate a second file of a second preset type used to describe the data binding relationship and the business logic relationship; Convert the decorative attribute information into a third file of a third preset type; The source code is generated based on the first file, the second file, and the third file.
4. The method according to any one of claims 1 to 3, characterized in that, If the platform type is the second type, then converting the metadata description file into source code suitable for the target platform according to the platform type includes: Based on the platform type, determine the second target code generator; The metadata description file is loaded by the second target code generator, and the metadata description file is converted into intermediate representation data; For each first element in the intermediate representation data, according to a preset mapping rule library, the first element is converted into a first sub-code suitable for the target platform; for each first attribute in the intermediate representation data, according to the mapping rule library, the first attribute is converted into a second sub-code suitable for the target platform; and according to the mapping rule library, the first layout information corresponding to the intermediate representation data is converted into a third sub-code suitable for the target platform. The source code is determined based on the first sub-code corresponding to each of the first elements, the second sub-code corresponding to each of the first attributes, and the third sub-code.
5. The method according to claim 4, characterized in that, The mapping rule base includes element type mapping relationships, which are used to describe the relationship between the type of the first element in the intermediate representation data and the type of the second element in the target platform. The step of converting the first element into a first sub-code suitable for the target platform according to a preset mapping rule library includes: Based on the element type mapping relationship and the type of the first element, determine the type of the second element corresponding to the first element; The first sub-code is determined based on the type of the second element corresponding to the first element.
6. The method according to claim 4, characterized in that, The mapping rule base includes an attribute conversion rule table, which is used to describe the relationship between the type of the first attribute in the intermediate representation data and the type of the second attribute in the target platform. The step of converting the first attribute into second sub-code suitable for the target platform according to the mapping rule base includes: Based on the attribute conversion rule table and the type of the first attribute, determine the type of the second attribute corresponding to the first attribute; The second sub-code is determined based on the type of the second attribute corresponding to the first attribute.
7. The method according to claim 4, characterized in that, The mapping rule base includes a layout adaptation algorithm, which describes the relationship between the first layout information and the second layout information of the target platform; the step of converting the first layout information corresponding to the intermediate representation data into third sub-code suitable for the target platform includes: Based on the layout adaptation algorithm, the second layout information corresponding to the first layout information is determined; The third sub-code is determined based on the second layout information corresponding to the first layout information.
8. An implementation apparatus for a low-code platform, characterized in that, include: The description file generation unit is used to receive application interface configuration instructions input by the user for the preset platform metamodel through the visual designer, and generate metadata description files. Different target platforms correspond to the same metadata description file; Obtain the platform type selected by the user for the target platform; The conversion unit is used to convert the metadata description file into source code suitable for the target platform according to the platform type.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements each step of the method for implementing the low-code platform as described in any one of claims 1 to 7.
10. A computer program product, characterized in that, When the computer program product is executed by a processor, it implements the steps of the implementation method of the low-code platform as described in any one of claims 1 to 7.