Event orchestration method and device based on low-code development platform of native JS

Abstract

The application discloses a low-code development platform event arrangement method and device based on native JS, relates to the technical field of visual programming, and comprises the following steps: in response to an event arrangement request sent by a user through a visual development interface, calling a visual framework and presenting an event arrangement canvas in the visual development interface; configuring event nodes and event flow connections in the event arrangement canvas; generating event flow configuration data based on the event nodes and the event flow connections; converting the event flow configuration data into native JavaScript code, calling a rendering engine, and rendering page styles and page data of the visual development interface according to the native JavaScript code; and in response to an interactive operation of the user on the visual development interface, triggering corresponding native JavaScript code to execute corresponding event flows. The application can effectively improve development efficiency and reduce the development cycle.

Description

TECHNICAL FIELD

[0001] The embodiment of the present application relates to the technical field of visual programming, in particular to a low-code development platform event arrangement method and device based on native JS. BACKGROUND

[0002] With the rapid development of information technology and the deepening of enterprise digital transformation, software application systems have become an indispensable core tool to support business operations in various industries. Software systems penetrate into production, management, sales, service and other aspects. User interface (UI) as the main window of human-computer interaction, its friendly design, complete function and timely response directly affect user experience and work efficiency. Modern software applications, especially web applications, often need to handle complex interaction logic and business processes. Each operation of the user on the interface, such as clicking buttons, filling in forms, dragging elements (collectively referred to as "events"), may trigger a series of background data processing, interface state updates or linkage with other systems. How to efficiently and accurately realize the binding and arrangement of these events and corresponding business logic is a key link in software development.

[0003] In current software development practice, front-end development occupies an important position, responsible for implementing the interface and logic that users directly interact with. For traditional software development processes, especially the part involving interface interaction and business logic implementation, in typical project models, the business department or customer will propose a series of requirements on business processes, data collection, interface display, etc. These requirements are often passed to the technical development team in the form of documents, prototypes or oral communication. After receiving the requirements, the technical team needs to go through a series of steps such as requirement analysis, system design, coding implementation, testing and verification. In this process, there is often a gap in understanding and communication between the demand side and the technical side. Business personnel usually do not understand the implementation details at the code level, while technical personnel may not fully and accurately understand the nuances of the business process and potential constraints. This information asymmetry and understanding bias can easily lead to a mismatch between the developed function and the actual business requirements, resulting in logical inconsistencies, process interruptions, hidden bugs, etc. The risk of information loss and distortion is high in the conversion process from natural language or flowchart to code, which further prolongs the development cycle.

[0004] Therefore, a new technical solution is needed to improve development efficiency and reduce development cycle. SUMMARY

[0005] The embodiment of the present application provides a low-code development platform event arrangement method and device based on native JS, which is used to improve development efficiency and reduce development cycle.

[0006] To achieve the above-mentioned purpose, the embodiments of the present application adopt the following technical solutions:

[0007] In a first aspect, a native JS-based low-code development platform event orchestration method is provided, applied to a server, the server being deployed with a low-code development platform, the low-code development platform including a visual development interface, a visual framework, a rendering engine, and an event orchestration module, and the method includes:

[0008] In response to an event orchestration request sent by a user through the visual development interface, calling the visual framework to present an event orchestration canvas in the visual development interface;

[0009] Configuring event nodes and event flow connections in the event orchestration canvas;

[0010] Generating event flow configuration data based on the event nodes and the event flow connections;

[0011] Converting the event flow configuration data into native JavaScript code, and calling the rendering engine to render the page style and page data of the visual development interface according to the native JavaScript code;

[0012] In response to the user's interactive operation in the visual development interface, triggering the corresponding native JavaScript code to execute the corresponding event flow.

[0013] In a possible implementation manner of the first aspect, before calling the visual framework, the method includes:

[0014] Verifying the access authority of the user;

[0015] In the case where the access authority verification is passed, loading an event component library, wherein the event component library includes a plurality of event components;

[0016] Reading metadata information of each event component from the event component library;

[0017] According to the metadata information, rendering and displaying the event components in the event component library in a preset component panel area of the visual development interface.

[0018] In another possible implementation manner of the first aspect, configuring the event nodes and the event flow connections in the event orchestration canvas includes:

[0019] In response to an event component dragging instruction, converting the event component into a corresponding event node on the event orchestration canvas;

[0020] In response to a configuration request of a specific event node by the user, popping up an attribute configuration panel;

[0021] Receiving node attribute information input by the user through the attribute configuration panel, and performing attribute configuration on each event node to determine the node attribute of each event node.

[0022] determine the connection relationship of the different event nodes based on the node attributes of each event node, and draw a connection line on the event orchestration canvas according to the connection relationship;

[0023] determine the execution order of the event flow according to the connection relationship, and configure the event flow connection according to the execution order of the event flow.

[0024] In a possible implementation of the first aspect, the event nodes include a trigger event node, a logic processing node, and a response event node, and the node attributes of each event node are configured to determine the node attributes of each event node, including:

[0025] for the trigger event node, the node attributes are configured as a trigger condition, a trigger source, and / or a trigger parameter;

[0026] for the logic processing node, the node attributes are configured as processing logic, conditional branching, and / or data conversion rules;

[0027] for the response event node, the node attributes are configured as a response action, a target object, and / or a response parameter.

[0028] In a possible implementation of the first aspect, the connection relationship of the different event nodes is determined based on the node attributes of each event node, including:

[0029] identify the starting node and the target node corresponding to the connection instruction;

[0030] obtain the node type and the node attributes of the starting node and the target node;

[0031] determine whether the output type of the starting node and the input type of the target node are compatible according to the preset connection rule;

[0032] determine whether the dependency relationship or the constraint condition defined in the node attributes is met between the starting node and the target node;

[0033] if the types are compatible and the dependency or constraint condition is met, it is determined that there is a connection relationship between the starting node and the target node.

[0034] In a possible implementation of the first aspect, the event flow configuration data is generated based on the event nodes and the event flow connection, including:

[0035] traverse all the event nodes on the event orchestration canvas to obtain the node identifier and the node attributes of each event node;

[0036] traversing all event flow connections on the event orchestration canvas, determining a starting node identifier and a target node identifier of each connection according to a graphical representation of the event flow connection;

[0037] determining a connection condition of the event flow connection according to a node attribute of the connection starting node;

[0038] generating JSON format configuration data containing event flow structure and execution logic according to the node attribute of the event node and the execution order of the event flow connection.

[0039] In a possible implementation of the first aspect, the event flow configuration data is converted into native JavaScript code, including:

[0040] parsing the event flow configuration data to extract a node list and a connection list;

[0041] converting the node type and the node attribute of each node JSON object in the node list into corresponding JavaScript function body logic;

[0042] determining the starting node, the target node and the connection condition according to each connection JSON object in the connection list, and generating event listening / callback functions for controlling function calling order and data passing based on the starting node, the target node and the connection condition;

[0043] assembling the native JavaScript code based on the generated JavaScript function body logic and the event listening / callback functions.

[0044] In a possible implementation of the first aspect, a rendering engine is called to render page style and page data of the visual development interface according to the native JavaScript code, including:

[0045] initializing a running environment of the rendering engine;

[0046] injecting the native JavaScript code into a DOM structure of the visual development interface;

[0047] parsing page component layout and style configuration information of the visual development interface;

[0048] applying CSS rules to render static page style of the visual development interface according to the page component layout and the style configuration information;

[0049] executing an initialization part in the native JavaScript code, and establishing a binding relationship between a page component of the visual development interface and a data source, the data source being determined by the native JavaScript code according to an execution order of the event flow;

[0050] According to the binding relationship and the data source, the content of the page component is filled, and the rendering of the page data is completed.

[0051] In a possible implementation of the first aspect, in response to the user's interactive operation on the visual development interface, the corresponding native JavaScript code is triggered to execute the corresponding event flow, including:

[0052] In response to the user's interactive operation on the visual development interface, the event source and the event type are determined according to the interactive operation, and the JavaScript function of the trigger event node bound in the native JavaScript code is matched according to the event source and the event type;

[0053] The JavaScript function corresponding to the trigger event node is executed;

[0054] The JavaScript functions of the logic processing nodes connected to the trigger event node are sequentially called to generate an execution result;

[0055] According to the execution result and the connection condition of the event flow connection, the execution path of one or more response event nodes is determined, and the JavaScript functions of the corresponding response event nodes are executed according to the execution path.

[0056] In a second aspect, the present application provides a server, comprising:

[0057] a memory configured to store instructions; and

[0058] a processor configured to call the instructions from the memory and enable the above-mentioned native JS-based low-code development platform event arrangement method when executing the instructions.

[0059] Through the above technical solution, a native JS-based low-code development platform event arrangement method is provided. Through the visual event arrangement canvas, business personnel can intuitively design and configure the interactive logic of the application without writing complex code. At the same time, by automatically converting the visual configuration into efficient native JavaScript code, the performance and compatibility of the application are ensured. This method significantly reduces the communication cost between business requirements and technical implementation, reduces the loss and misunderstanding in the information transmission process, and enables business personnel to more directly participate in the application development process. In addition, since the generated is a standard native JavaScript code, rather than a proprietary code that depends on a specific framework or runtime, the developed application has better portability and maintainability. In practical applications, this method can effectively shorten the development cycle, and since the dependence on professional developers is reduced, enterprises can more flexibly allocate technical resources, further improving development efficiency and reducing development costs.

[0060] Other features and advantages of the embodiments of the present application will be described in detail in the following specific embodiments section. BRIEF DESCRIPTION OF DRAWINGS

[0061] Figure 1 A flowchart of an event arrangement method of a low-code development platform based on native JS provided by an embodiment of the present application;

[0062] Figure 2 A structural diagram of a server provided by an embodiment of the present application;

[0063] Figure 3 A visual development interface diagram provided by an embodiment of the present application;

[0064] Figure 4 An event arrangement canvas operation flowchart provided by an embodiment of the present application;

[0065] Figure 5 An event node attribute configuration flowchart provided by an embodiment of the present application;

[0066] Figure 6 An event flow runtime execution flowchart provided by an embodiment of the present application. DETAILED DESCRIPTION

[0067] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme of the embodiments of the present application will be described clearly and completely below in combination with the drawings in the embodiments of the present application. It should be understood that the specific embodiments described herein are only used to illustrate and explain the embodiments of the present application, and are not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative labor fall within the scope of protection of the present application.

[0068] It should be noted that if the embodiments of the present application involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are only used to explain the relative position relationship, movement condition, etc. between components in a certain specific posture (as shown in the drawings), and if the specific posture changes, the directional indications will also change accordingly.

[0069] In addition, if the description of "first", "second" and the like is involved in the embodiments of the present application, the description of "first", "second" and the like is only for the purpose of description, and cannot be understood as indicating or implying the relative importance of the technical features indicated or implying the number of technical features indicated. Therefore, the features limited by "first", "second" can be explicitly or implicitly included at least one of the features. In addition, the technical solutions of various embodiments can be combined with each other, but it must be based on the realization of ordinary skilled in the art, when the combination of technical solutions appears contradictory or unachievable, it should be considered that the combination of technical solutions does not exist, nor in the protection scope required by the present application.

[0070] Figure 1 The flowchart of the low-code development platform event arrangement method based on native JS according to the embodiments of the present application is schematically shown. As shown in Figure 1 The embodiments of the present application provide a low-code development platform event arrangement method based on native JS, which is applied to a server. The server is deployed with a low-code development platform, and the low-code development platform includes a visual development interface, a visual framework, a rendering engine and an event arrangement module. The method can include the following steps.

[0071] S110, in response to the event arrangement request sent by the user through the visual development interface, calling the visual framework to present the event arrangement canvas in the visual development interface;

[0072] S120, configuring event nodes and event flow connections in the event arrangement canvas;

[0073] S130, generating event flow configuration data based on the event nodes and the event flow connections;

[0074] S140, converting the event flow configuration data into native JavaScript code, and calling the rendering engine to render the page style and page data of the visual development interface according to the native JavaScript code;

[0075] S150, in response to the interactive operation of the user in the visual development interface, triggering the corresponding native JavaScript code to execute the corresponding event flow.

[0076] Figure 3 The schematic diagram of the visual development interface provided by the embodiments of the present application is shown. In the specific implementation, when the user sends the event arrangement request through the Figure 3When the visual development interface is clicked or a corresponding menu item is selected, the server captures this user interaction event and identifies it as an event orchestration request. This request is transmitted to the event orchestration module on the server side through an HTTP request or a WebSocket connection. After receiving the request, the event orchestration module first verifies the user's operation authority to ensure that the user has the authorization to perform event orchestration. After the authority verification is passed, the event orchestration module calls the API of the visualization framework to initialize the DOM structure, style and interaction logic required for the event orchestration canvas. The visualization framework creates a drawing area based on HTML5 Canvas or SVG, which has basic interaction capabilities such as grid background, zoom control and drag function. At the same time, the visualization framework also initializes the state management server of the event orchestration canvas to track the position, connection relationship and attribute information of each element on the canvas.

[0077] After the canvas is initialized, the visualization framework renders the event orchestration canvas in the main work area of the visual development interface, and loads the available event component library in the interface sidebar, including trigger event components (such as button click, form submission, page load, etc.), logic processing components (such as conditional judgment, loop, data conversion, etc.) and response event components (such as page jump, data submission, UI update, etc.). Through the above components, users can add draggable components in the left sidebar or right sidebar of the work area to the event orchestration canvas through drag-and-drop. In addition, the visualization framework also initializes the toolbar of the canvas, which is set on the top of the page in this embodiment, and provides save and other operation buttons to enhance the user's editing experience.

[0078] Figure 4 An event orchestration canvas operation flowchart provided by an embodiment of the present application is shown in FIG. 6. Figure 4 As shown in FIG. 6, configuring event nodes and event flow connections in the event orchestration canvas includes the following steps: (a) dragging an event component (such as "button click") from the component library to the canvas to form an event node. (b) There are at least two nodes (for example, a trigger node and a response node) on the canvas. (c) Drag the connection line from the output anchor point of the starting node to the input anchor point of the target node to form an event flow connection.

[0079] When the event orchestration canvas is presented, the user can select the desired event components from the component library by dragging and dropping them into the appropriate location on the canvas. Whenever an event component is dragged and dropped onto the canvas, the visualization framework converts the component into a corresponding event node and assigns it a unique node identifier. The event node is represented on the canvas as a visual graphic (such as a rectangle, circle, or custom icon) and displays basic information about the node, such as the node type and name. The user can open the property configuration panel for a node by double-clicking on it or selecting the “Configure” option from the right-click menu. The property configuration panel dynamically generates different configuration options based on the node type, for example, for a trigger event node, the trigger condition (such as “click,” “hover,” “input,” etc.), trigger source (such as a selector for a specific DOM element), and trigger parameters can be configured; for a logic processing node, the processing logic (such as a conditional expression, loop condition), condition branches, and data transformation rules can be configured; for a response event node, the response action (such as “show,” “hide,” “update,” etc.), target object, and response parameters can be configured. After completing the node property configuration, the visualization framework updates the visual representation of the node in real-time to reflect the changes in configuration. After configuring the event nodes, the user defines the connection relationships between nodes, i.e., the event flow connections. In one embodiment, the event flow connections are automatically generated based on the association relationships between event nodes, in another embodiment, the user can create a connection line by clicking on the output anchor point of the starting node and dragging it to the input anchor point of the target node. The visualization framework automatically verifies the validity of the connection based on the starting and target node types, for example, ensuring that a trigger event node can only be connected to a logic processing node or a response event node, but not to another trigger event node. For logic processing nodes with conditional branches, different condition expressions can be configured for each branch, and different branch paths can be represented by connection lines of different colors or labels. In addition, the path and shape of the connection line can be adjusted to optimize the visual representation of the event flow.

[0080] Based on the event nodes and event flow connections, the event flow configuration data is generated. When the event node configuration and event flow connections are completed, the visualization framework traverses all elements on the event orchestration canvas, collects and organizes relevant information, and generates structured event flow configuration data. First, the visualization framework traverses all event nodes on the canvas, obtains the basic information of each node, including node identifier (usually a unique string in UUID format), node type (trigger event, logic processing, or response event), node position coordinates (used to locate on the canvas), and detailed attribute configuration of the node. For trigger event nodes, attribute configuration includes event type, event source selector (such as "#submitButton", ".form-input", etc.), and event parameters; for logic processing nodes, attribute configuration includes processing function definition, input parameter mapping, and output parameter definition; for response event nodes, attribute configuration includes response action type, target element selector, and response parameters.

[0081] Second, the visualization framework traverses all connection lines on the canvas, obtains the starting node identifier, target node identifier, connection type (such as "normal flow", "conditional branch", "error handling", etc.), and connection condition of each connection line. For conditional branch connections, the connection condition is usually a JavaScript expression or function that evaluates whether the execution should continue along this path at runtime.

[0082] Then, the visualization framework organizes the collected node information and connection information into a structured JSON object, which usually contains two main parts: nodes array (contains detailed information of all nodes) and connections array (contains detailed information of all connections). In addition, the JSON object may also contain metadata part, recording the name of the event flow, creation time, last modification time, version number, etc. Finally, the visualization framework verifies the generated JSON object to ensure its structure is complete, data types are correct, and checks for potential problems such as isolated nodes (nodes without any connections) or circular dependencies (node connection patterns that may cause infinite loops). After verification, the event flow configuration data is temporarily stored in the client memory, waiting for the next step of processing.

[0083] The event process configuration data is converted into native JavaScript code, and the rendering engine is called to render the page style and page data of the visual development interface according to the native JavaScript code. In this step, the low-code platform first parses the event process configuration data (JSON format) generated in the previous step and extracts the node list and connection list. For each node JSON object in the node list, a corresponding JavaScript code snippet is generated according to its node type and attribute configuration. For example, for the trigger event node, event listener code is generated; for the logic processing node, conditional judgment, loop or data processing function is generated; for the response event node, DOM operation or API call code is generated. The code generation process uses template engine technology to predefine code templates for different types of nodes, and then inserts the node attribute values ​​into the placeholders in the template to generate a complete code snippet. For example, for a button click to trigger an event node, the following code template may be generated: document.querySelector('${selector}').addEventListener('click',function(event) { / * processing logic * / }), where ${selector} is a placeholder that will be replaced by the button selector configured in the node properties.

[0084] Next, the low-code platform generates control flow code based on the connection relationships in the connection list to determine the execution order and data transfer method of each node code snippet. For simple sequential execution, you can use a function call chain; for conditional branches, use if-else statements; for parallel execution, you can use asynchronous processing methods such as Promise.all(). For example, if node A is connected to node B and node C, and the connection to node C is a conditional branch, the following control flow code may be generated: if (condition) { executeNodeC(data);} else { executeNodeB(data);}. The platform then combines all generated code snippets and control flow code into a complete JavaScript module and adds the necessary error handling, performance monitoring, and logging code.

[0085] After the code generation is completed, the rendering engine is called to inject the generated JavaScript code into the DOM structure of the visual development interface. The rendering engine first parses the component layout and style configuration information of the page, applies the CSS rules to render the static page style. Then it executes the injected JavaScript code to establish the binding relationship between the page components and the data source, and fills the page content according to the initial data. The rendering process uses the virtual DOM technology to build a DOM tree in memory first, then compares it with the actual DOM, and only updates the changed part, improving the rendering efficiency.

[0086] As shown in Figure 6 , it shows the process of user interaction triggering event flow execution. Specifically, in response to user interaction operations on the visual development interface, the corresponding native JavaScript code is triggered to execute the corresponding event flow. When the user performs interactive operations (such as clicking buttons, entering text, selecting options, etc.) on the rendered visual development interface, these operations will trigger DOM events. The event server of the browser will capture these DOM events and, according to the event type and event target element, find the matching event listener. These event listeners are part of the native JavaScript code generated in the previous step and injected into the page.

[0087] When the matching event listener is triggered, the initialization logic in the event handling function will be executed first, such as preventing default behavior, stopping event bubbling, obtaining event-related data, etc. Then, the event handling function will determine the JavaScript function corresponding to the triggering event node according to the event flow configuration, and execute the function. The JavaScript function of the triggering event node is usually responsible for collecting data generated by user interaction, such as form input values, selected states, click positions, etc., and encapsulating these data into an event context object. Next, according to the connection relationship defined in the event flow, the server will sequentially call the JavaScript functions of the logical processing nodes connected to the triggering event node. The function of the logical processing node will receive the event context object as input, perform data verification, conversion, calculation, etc., and update the event context object according to the processing result. For logical processing nodes containing conditional branches, their JavaScript functions will evaluate the conditional expressions and choose different execution paths according to the results of the expressions. Finally, the server will call the JavaScript functions of the corresponding response event nodes according to the execution path.

[0088] The function of the response event node is responsible for executing specific response actions, such as updating UI elements, sending API requests, triggering animation effects, etc. These response actions will be directly reflected on the user interface, providing immediate feedback to the user. During the execution of the entire event flow, the server maintains a unified event context object to pass data between different nodes.

[0089] In this embodiment, the following steps can also be included:

[0090] An API maintenance interface is provided for configuring data interaction interfaces with external systems. API parameters and authentication information configured by the user through the API maintenance interface are received. API interface configurations are generated and stored in a database. During the execution of the event flow, API interfaces are called as needed to achieve data exchange with external systems.

[0091] During the execution of the event flow, API interfaces are called as needed to achieve data exchange with external systems, including: identifying operations that need to call external APIs during the execution of the logic processing node; reading the corresponding API interface configuration from the database; constructing API request parameters and authentication information according to the API interface configuration; sending API requests to external systems and receiving response data from external systems; parsing and converting the response data for subsequent execution of the event flow.

[0092] The event orchestration method based on native JS provided in this embodiment allows business personnel to intuitively design and configure the interaction logic of the application through a visual event orchestration canvas, without the need to write complex code. At the same time, by automatically converting the visual configuration into efficient native JavaScript code, the performance and compatibility of the application are ensured. This method significantly reduces the communication cost between business requirements and technical implementation, reduces loss and misunderstanding in the information transmission process, and enables business personnel to more directly participate in the application development process. In addition, since standard native JavaScript code is generated rather than proprietary code that relies on specific frameworks or runtimes, the developed application has better portability and maintainability. In practical applications, this method can effectively shorten the development cycle, and since it reduces the dependence on professional developers, enterprises can more flexibly allocate technical resources, further improving development efficiency and reducing development costs.

[0093] In one implementation of this embodiment, before calling the visual framework, the following steps are included:

[0094] S210, verifying the access rights of the user;

[0095] S220, loading an event component library in a case where the access permission verification is passed, wherein the event component library comprises a plurality of event components;

[0096] S230, reading metadata information of each event component from the event component library;

[0097] S240, rendering and displaying the event components in the event component library in a preset component panel area of the visual development interface according to the metadata information.

[0098] Before invoking the visualization framework, the access permission of the user needs to be strictly verified first to ensure that only authorized users can use the event arrangement function of the low-code development platform. When the user tries to access the low-code development platform, the server will automatically trigger the permission verification process. This process first checks the login status of the user, and confirms the user identity by verifying the validity of the user session or token.

[0099] For the logged-in user, the server will obtain the role information and permission configuration of the user from the user management database. User roles are usually divided into multiple levels, such as server administrator, development administrator, business developer, and read-only user, etc., each role corresponds to a different set of operation permissions. The server will compare the current role of the user with the minimum permission level required for the event arrangement function to determine whether the user has the basic permission to access the function. In addition to role-level permission verification, the server will also check the user's access permission to specific projects or applications. In addition, the server will also perform operation-level permission checks to distinguish between the user's read and edit permissions for the event arrangement function. Some users may only be allowed to view existing event flow configurations, but not to create or modify these configurations. During the permission verification process, the server will record detailed information of the verification request, including user ID, IP address, request time, request resource, and verification result, etc., to form a complete audit log for subsequent security audit and problem tracking. If the permission verification fails, the server will return the corresponding error code and prompt information, and redirect the user to the login page or permission insufficient prompt page. At the same time, the server will record the failed access attempts, and for multiple failed access requests within a short period of time, a temporary ban mechanism may be triggered to prevent brute force attacks and malicious attacks.

[0100] When the user's access permission verification is successful, the server will immediately start the loading process of the event component library. The event component library is one of the core resources of the low-code development platform, which contains various pre-defined components that users can use in the event arrangement canvas.

[0101] The loading process first sends a component library request to the server, which usually contains parameters such as user ID, project ID, and platform version number. The server determines the component set to be returned based on these parameters. After receiving the request, the server queries the component repository for components suitable for the current user and project. The component repository usually uses a hierarchical storage structure, including server-level components (available to all users), tenant-level components (customized for specific tenants), and project-level components (customized for specific projects). The query result is filtered according to the user's permission level to ensure that the user can only access the components he is authorized to use.

[0102] To optimize loading performance, the server uses an incremental loading strategy, first loading basic components and frequently used components, and then loading other components asynchronously in the background. Component loading uses HTTP / 2 protocol or WebSocket connection, supporting multiplexing and server push, reducing network latency and resource consumption. For components that have already been loaded, the server uses the browser cache mechanism to determine whether they need to be reloaded by comparing component version numbers, avoiding repeated transmission of the same resources. The loaded event component library usually includes three types of components: trigger event components (such as button clicks, form submissions, page loads, timers, etc.), logic processing components (such as conditional judgments, loop traversals, data conversions, API calls, etc.), and response event components (such as page jumps, popup displays, data updates, animation effects, etc.).

[0103] After the component is loaded, the server establishes a component index in the client memory for quick lookup and access to component definitions. At the same time, the server triggers a component loading completion event to notify related modules that they can start using component library resources.

[0104] When the event component library is loaded, the server needs to read the metadata information of each event component, where metadata is structured data that describes the characteristics, behavior, and usage of components. The metadata reading process first traverses the loaded component library and performs metadata parsing operations for each component. Component metadata is usually stored in JSON format and contains basic properties and configuration information of the component. For each component, the server reads its unique identifier, which is used to uniquely identify the component in the entire platform; component type, such as trigger event, logic processing, or response event; component name and description, used to display to users in the interface; component icon, usually in SVG format or image URL, used to visually display in the component panel; component classification, such as basic components, form components, data components, etc., used for organization and grouping display; version information, used for component update and compatibility management, etc. After metadata reading is completed, the server caches this information in the client memory, establishes a component index and classification mapping, and provides data support for subsequent component rendering and use.

[0105] After the reading and processing of the event component metadata are completed, the server renders and displays each event component in the event component library in the preset component panel area of the visualization development interface according to the metadata information.

[0106] The rendering process first determines the layout structure of the component panel, usually in the form of a categorized accordion panel or tabs, grouping components according to their attributes. For each category, the server creates a corresponding container element and sets appropriate titles, icons, and expansion / collapse controllers. Within the category container, the server iterates through all components belonging to the category and creates a visual representation element for each component. The visual representation of a component is usually a card or list item containing an icon, name, and short description, with its style and size uniformly set according to the platform's design specifications. The component icon is set according to the icon attribute in the component metadata, with SVG format directly embedded into the DOM or image URL creating an img element with the src attribute. The component name and description are obtained from the name and description fields in the metadata, respectively.

[0107] To enhance user experience, the server adds rich interactive effects to each component element, such as hover highlighting, click feedback, and drag preview. When the user hovers the mouse over the component, the server displays more detailed component descriptions and usage tips; when the user clicks on the component, it can display detailed configuration options or usage examples; when the user starts dragging the component, the server creates a visual copy of the component that follows the mouse movement and displays a placement indicator in the available placement area. To support component dragging operations, the server registers drag event listeners for each component element, implementing HTML5 drag-and-drop API or custom drag-and-drop logic. When dragging starts, the server records the identifier and type of the dragged component; when dragging ends and is released in a valid area, the server creates a corresponding event node on the event orchestration canvas. In addition, the server also implements search and filter functions in the component panel, allowing users to quickly find the required components through keyword search or attribute filtering. The search function matches the component's name, description, and tag fields and updates the display results in real time. To adapt to different screen sizes and user preferences, the component panel usually supports adjusting the width, switching display modes (such as list view / grid view), and toggling between fixed / floating states. When there are a large number of components, the server implements virtual scrolling technology, rendering only the components within the visible area, reducing the number of DOM nodes, and improving rendering performance and response speed.

[0108] The user permission verification mechanism ensures secure access to platform resources and prevents unauthorized use and data leakage risks. The intelligent loading strategy of the event component library significantly improves the platform's startup speed and response performance, ensuring the rapid availability of basic functions even in poor network conditions. Structured processing and cache optimization of component metadata enable the server to dynamically adjust interface behavior and function display based on component characteristics and user permissions. In the visual interface, the classification display and interaction optimization of the preset component panel significantly improve user operation efficiency and experience, enabling users with different technical backgrounds to intuitively understand component functions and quickly find the required tools. This enables the entire low-code development platform to help developers quickly build complex business applications in a more secure, efficient, and user-friendly manner, effectively improving development efficiency.

[0109] In one embodiment of the present embodiment, configuring event nodes and event flow connections in the event orchestration canvas includes the following steps:

[0110] S310, in response to the event component dragging instruction, converting the event component into a corresponding event node on the event orchestration canvas;

[0111] S320, in response to the user's configuration request for a specific event node, popping up an attribute configuration panel;

[0112] S330, receiving node attribute information input by the user through the attribute configuration panel, and configuring attributes for each event node to determine the node attributes of each event node;

[0113] S340, in response to the user's connection instruction for different event nodes, and based on the node attributes of each event node, determining the connection relationship of different event nodes, and drawing a connection line on the event orchestration canvas according to the connection relationship;

[0114] S350, determining the execution order of the event flow according to the connection relationship, and configuring the event flow connection according to the execution order of the event flow.

[0115] For Figure 3The visual development interface shown, when the user selects an event component from the component panel and starts dragging, the server immediately captures this drag instruction and starts the component-to-node conversion process. Dragging is achieved by listening to the mousedown, mousemove, and mouseup events on the component element, or using the HTML5 native drag-and-drop API (dragstart, dragover, and drop events). When the drag starts, the server creates a visual feedback element that follows the mouse pointer, which is usually a semi-transparent copy of the original component, containing the component icon and name, so that the user can clearly understand what is being dragged. At the same time, the server records the unique identifier and type information of the dragged component, preparing for subsequent node creation.

[0116] During the dragging process, the server calculates the mouse position relative to the event orchestration canvas in real time, and detects whether the current position is within the valid placement area. When the mouse enters the canvas area, the server highlights the placeable area, and may display grid alignment auxiliary lines or suction effect, helping the user to accurately position. When the user releases the mouse button on the canvas (mouseup or drop event triggers), the server checks the validity of the release position. If the position is valid, it starts the process of converting the component to an event node. The conversion process first creates a new event node object according to the metadata of the component, which contains the type, identifier, name, icon, input and output parameter definition, default configuration, etc. of the node. Then, the server assigns a globally unique node ID to the node, usually using UUID (Universal Unique Identifier) or incrementing the numeric ID with a prefix. Next, the server renders the corresponding visual elements on the canvas according to the information of the node object.

[0117] The visual representation of the node is usually a rectangular container containing node icons, names, type identifiers, and status indicators. The position of the node is set to the coordinate position where the user releases the mouse. For different types of nodes, the server applies different visual styles, such as trigger event nodes with green borders, logic processing nodes with blue borders, and response event nodes with orange borders, so that users can intuitively distinguish different types of nodes. In addition, the server also creates connection points (ports) on the node for subsequent connection with other nodes. Input connection points are usually located on the left or top of the node, and output connection points are usually located on the right or bottom of the node. The number and location of connection points depend on the type and defined input and output parameters of the node. After the node is created, the server adds the node object to the data model of the canvas, updates the canvas state, and triggers a node creation success event notification, so that other modules can respond to this change.

[0118] In response to a user's configuration request for a specific event node, a property configuration panel is popped up. When a user needs to configure a specific event node that has been placed on the event orchestration canvas, he / she usually initiates a configuration request by clicking the node or using the configuration button on the node. After the server captures this request, it immediately starts the creation and display process of the property configuration panel.

[0119] The triggering method of the configuration request can be single-clicking the node, double-clicking the node, selecting the "Configure" option in the right-click menu, or clicking a special configuration icon button on the node, etc. For any triggering method, the server first identifies the specific node selected by the user and obtains the unique identifier and current state information of the node.

[0120] Before the configuration panel is popped up, all configurable properties supported by the node of this type can be read from the node's metadata definition, including property name, data type, default value, value range, whether it is required, etc. At the same time, the current configuration value of the node is read to display the current configuration state in the panel. The property configuration panel is usually displayed in the form of a modal dialog box, located above the canvas, with a semi-transparent mask layer to focus the user's attention.

[0121] The creation of the panel uses DOM manipulation or component rendering mechanisms of the front-end framework to insert panel elements into the document and set appropriate styles and positions. The title area of the panel usually displays the name and type of the node, as well as a close button. The content area dynamically generates form controls according to the configurable properties of the node. Different types of properties correspond to different controls: text type uses input box; numerical type uses numerical input box; boolean type uses checkbox or switch; enumeration type uses drop-down selection box or radio button group; date and time type uses date selector; color type uses color selector; complex object type may use nested form or JSON editor; array type uses list control that can add / delete items, etc.

[0122] After the panel is displayed, the server binds event listeners to each form control to validate the user's input in real time and provides immediate feedback, such as displaying error prompts, input suggestions, or configuration previews, etc.

[0123] When the attribute configuration panel is displayed, the user can input or modify the node's attribute information through various form controls. The server captures these input operations in real time and processes and verifies them. The capture of user input is achieved by listening to the events of various form controls, such as the input and change events of input boxes, the select event of selection boxes, and the click event of check boxes. When the user inputs or modifies values in the form controls, the server immediately performs front-end verification to check whether the input meets the expected format and constraint conditions. The verification rules are obtained from the node metadata and may include: mandatory field checking to ensure that all attributes marked as mandatory have values; data type checking to ensure that the type of the input value matches the attribute definition; format verification to verify the input format using regular expressions or specific algorithms, such as email addresses, URLs, phone numbers, etc.; range checking to ensure that numerical type inputs are within the specified minimum and maximum values; length limit to ensure that text inputs do not exceed the maximum length; uniqueness checking to ensure that certain attribute values are unique throughout the process, such as node IDs or variable names; dependency verification to check whether mutually dependent attributes are consistent, such as condition expressions and branch paths of conditional branches, etc.

[0124] If the verification finds errors, the server will immediately display error prompts, usually by displaying red error information next to the corresponding control or changing the control border to red. In this embodiment, the server can also provide a real-time preview function to allow the user to intuitively see the effects of configuration changes. For example, for style-related attributes, the appearance of the preview area can be updated in real time; for data conversion rules, the results of the converted example data can be displayed; for conditional expressions, the results of the expression can be evaluated according to the current context data. When the user clicks the "OK" button, the server will perform the final verification to ensure that all necessary attributes have been correctly configured. If the verification passes, the server will collect the values of all form controls and construct a complete node attribute object. The node attribute object is a key-value pair set, and the server will apply this attribute object to the corresponding event node to update the internal state and appearance of the node.

[0125] When the user needs to establish a connection relationship between different event nodes, the user can connect from the output port of one node to the input port of another node through a drag-and-drop operation. After the server captures this connection instruction, it will start the creation and verification process of the node connection. The triggering of the connection instruction usually uses a drag-and-drop interaction mode: the user first clicks on the output port of the source node, then drags the mouse, and finally releases the mouse button at the input port of the target node. During the dragging process, the server will draw a temporary connection line in real time, following the source port to the current position of the mouse, providing intuitive visual feedback.

[0126] Temporary connection lines are usually in the form of polyline, which can be drawn using SVG path elements. When the mouse hovers over a potential target port, the server highlights the port to indicate that a connection can be made at this port.

[0127] When the user releases the mouse button on a valid target port, the server creates a formal connection object containing the source node ID, source port ID, target node ID, target port ID, and other information, and can also contain additional attributes such as connection type, label, style, etc. Then, the server draws a formal connection line on the canvas to represent the data or control flow relationship between the two nodes. The drawing of the connection line usually uses SVG path elements, and the shape of the path can be an orthogonal polyline or a custom path. For an orthogonal polyline, the path is composed of multiple horizontal and vertical line segments, ensuring that the line segments only have 90-degree turns, and the optimal path can be calculated using or other path finding algorithms.

[0128] The style of the connection line can be customized according to the data type, connection state, or user configuration, such as using different colored lines for different types of data flow, using animation effects for active connections, etc. After the connection is created, the server adds the connection object to the data model of the canvas, updates the connection state of the related nodes, and triggers the connection creation event to notify other modules of the change in connection relationship.

[0129] After completing the connection of the event nodes, the server needs to determine the execution order of the entire event flow based on these connection relationships and make the corresponding configuration.

[0130] Specifically, first, the server will perform a topological analysis on all nodes and connections on the canvas, building a directed graph data structure, where nodes represent event nodes and edges represent the connection relationship between nodes. The first step of topological analysis is to identify the entry node of the flow, that is, the node without input connection, which is usually a trigger type event node such as button click, form submission, timer, etc. Starting from each entry node, the server will use a depth-first search algorithm to traverse the entire graph to determine the access order of the nodes. During the traversal process, the server will detect whether there is a loop (circular dependency), and if there is, it will be marked as a potential problem, as circular dependencies can cause infinite loops or deadlocks. For conditional branch nodes (such as if-else, switch-case, etc.), the server will analyze all possible branch paths and assign priorities or execution conditions to each branch. For parallel execution nodes (such as parallel tasks, concurrent requests, etc.), the server will mark that the child tasks can be executed in parallel and may configure synchronization points to wait for all parallel tasks to complete before continuing the subsequent flow. Finally, the server will generate a complete event flow configuration, usually in JSON or XML format, containing node definitions, connection relationships, execution conditions, data mappings, error handling, etc. This configuration file will serve as input for the flow engine to guide the actual execution of the flow.

[0131] The present embodiment greatly reduces the technical threshold of flow design through the drag-and-drop component conversion node mechanism, allowing business personnel to build complex event processing logic without writing code. The node connection mechanism uses intuitive drag-and-drop interaction and intelligent type compatibility checking to make the logical relationship of the flow clear and visible. In addition to ensuring the correctness of the flow, it also improves the execution efficiency of the flow. The entire server visualizes complex event processing logic, making it easier for team members to understand and collaborate on business processes, significantly improving development efficiency and process quality.

[0132] In one embodiment of the present embodiment, the event nodes include trigger event nodes, logic processing nodes, and response event nodes, and the attributes of each event node are configured to determine the node attributes of each event node, including the following steps:

[0133] S410, for the trigger event node, configure its node attributes as trigger condition, trigger source and / or trigger parameter;

[0134] S420, for the logic processing node, configure its node attributes as processing logic, conditional branch and / or data conversion rule;

[0135] S430, for the response event node, configure its node attributes as response action, target object and / or response parameter.

[0136] Figure 5 An event node attribute configuration flowchart provided by an embodiment of the application is shown, as shown Figure 5 For a trigger event node, configure its node attributes as trigger conditions, trigger sources, and / or trigger parameters. The trigger event node is the starting point of the event flow, responsible for listening and capturing specific events, and starting the flow execution when the event occurs. Configuring the attributes of the trigger event node is a key step to ensure that the flow can correctly respond to expected events.

[0137] First, the trigger condition attribute defines the specific conditions or scenarios under which the event is triggered. The trigger condition can be an event type selection, such as "click", "submit", etc. Second, the trigger source attribute specifies the source object or system of the event. For DOM events, the trigger source can be a selector or element reference of a page element. For custom events, the trigger source can be an event bus name, channel ID, or message queue identifier. For system events, the trigger source can be an operating system, browser, server, or specific API endpoint. For database events, the trigger source can be database connection information, table name, and operation type (such as insert, update, delete) being listened to. Finally, the trigger parameter attribute defines the data extracted from the trigger event, which will be passed as input to the subsequent nodes of the flow. Parameter configuration usually includes parameter name, data type, default value, and extraction path. The parameter name is an identifier used to reference the parameter in the flow, the data type specifies the value type of the parameter, such as string, number, boolean, etc. The default value defines the alternative value used when the event does not provide the corresponding data. The extraction path specifies how to obtain the parameter value from the event object.

[0138] For a logic processing node, configure its node attributes as processing logic, conditional branches, and / or data conversion rules. The logic processing node is responsible for executing various business logic, data processing, and decision operations. Configuring the attributes of the logic processing node is a key step to ensure that the flow can correctly execute business rules and data conversion.

[0139] Firstly, the processing logic property defines the specific operation or algorithm that the node performs. The processing logic can be a predefined function or operation such as mathematical calculation (sum, average, max / min, etc.), string operation (concatenate, split, replace, etc.), array operation (map, filter, sort, etc.), or object operation (merge, extract, transform, etc.). It can also be a custom JavaScript code snippet that allows users to implement more complex logic. Secondly, the conditional branch property defines the branching logic based on specific conditions. The conditional branch usually includes one or more conditional expressions and the corresponding branch paths for each condition. Conditional expressions can be constructed using comparison operators (such as equal, greater than, less than, contains, etc.), logical operators (and, or, not), and various function combinations. For example, "if(order.total > 1000 && user.vipLevel >= 2)" represents a condition when the order total is greater than 1000 and the user's VIP level is not less than 2. Each condition corresponds to an output port or branch path, specifying the next step of the flow when the condition is met.

[0140] The data conversion rule property defines how to convert input data into the desired output format. Data conversion can include field mapping, type conversion, formatting, aggregation, and structure reorganization. Field mapping specifies which fields in the input data map to which fields in the output data, which can be one-to-one, many-to-one, or one-to-many mapping. Type conversion defines how to convert one data type to another, such as string to number, date format conversion, etc. Formatting rules specify how to format data, such as the number of decimal places, date display format, case of strings, etc. Aggregation rules define how to combine multiple data into one, such as calculating the sum, average, max / min, etc. Structure reorganization rules specify how to change the structure of data, such as converting flat data to nested structure, array to object, etc. The configuration interface of data conversion rules usually provides a visual mapping designer, allowing users to define conversion rules through wiring, dragging, or form filling, while providing data preview functions to show the comparison before and after conversion. Through these configurations, logic processing nodes can perform complex business logic, conditional judgment, and data conversion, providing powerful processing capabilities and flexibility for event flow.

[0141] For response event nodes, configure their node properties as response actions, target objects, and / or response parameters. Response event nodes are the end or output point of the event flow, responsible for performing specific response operations such as updating UI, sending notifications, calling APIs, or triggering other system behaviors. Configuring the properties of the response event node is a key step to ensure that the flow can produce the expected effect and correct response.

[0142] The response action attribute defines the specific operation type performed by the node. The response action can be a UI interaction type operation, such as displaying / hiding elements, updating content, switching styles, popping up dialog boxes, navigating to new pages, etc. It can also be a data operation type action, such as creating records, updating data, deleting information, submitting forms, etc.

[0143] The target object attribute specifies the specific object or target on which the response action acts. For UI operations, the target object is usually a DOM element, which can be specified by a CSS selector or an element reference. For data operations, the target object can be a data model, a database table, an API endpoint, or a storage location.

[0144] The response parameter attribute defines the specific parameters and data required when executing the response action. Parameter configuration usually includes parameter name, data type, parameter value or value source. The parameter name is a parameter identifier defined in the action API, and the required parameter names can be automatically listed according to the selected response action type. The data type specifies the value type of the parameter, such as string, number, boolean, object, array, etc. The parameter value can be a static value (a constant directly input), a dynamic value (obtained from flow data) or an expression (obtained by calculation). For dynamic values, the path or expression of the data source needs to be specified, such as "${order.customerName}" which means the value is obtained from the customerName attribute of the order object.

[0145] The configuration of the trigger event node realizes accurate capture and parameter extraction of various event sources, providing a clear starting point and initial data for flow execution. The configuration of the logic processing node provides rich data processing capabilities and decision logic, enabling non-technical personnel to implement complex business rules and data operations without writing code through the combination of processing logic, conditional branching and data conversion rules. The configuration of the response event node ensures that the flow execution result can be transformed into specific system behavior or user visible effect, through the precise definition of response action, target object and response parameter, realizing seamless integration with external systems and user interfaces, not only reducing the development threshold, enabling business personnel to directly participate in flow design, but also improving the maintainability and reusability of the flow, providing an efficient low-code development solution for enterprise-level applications. Through the visual configuration interface and intuitive attribute setting, complex programming concepts are successfully converted into easy-to-understand and operate configuration items, realizing the deep integration of technology and business.

[0146] In one embodiment of the present embodiment, the connection relationship of different event nodes is determined based on the node attributes of each event node, including the following steps:

[0147] S510, identify the starting node and target node corresponding to the connection instruction;

[0148] S520, acquire the node type and its node attributes of the start node and the target node;

[0149] S530, determine whether the output type of the start node and the input type of the target node are compatible according to the preset connection rule;

[0150] S540, determine whether the dependency relationship or the constraint condition defined in the node attributes is satisfied between the start node and the target node;

[0151] S550, if the types are compatible and the dependency or the constraint condition is satisfied, determine that the connection relationship exists between the start node and the target node.

[0152] The connection instruction is usually derived from the interactive operation of the user in the visual editor, such as dragging a connection line, clicking a connection button, or using a shortcut key, etc. When the user initiates a connection operation, the server first needs to determine the start node of the connection, which can be the position of the mouse click of the user, the currently selected node, or a specific node output port. For drag-type connection, the server tracks the starting position of the mouse or touch event and determines the node and its output port corresponding to the position through spatial coordinate calculation. For example, when the user starts to drag from a certain output port of node A, the server records the identifier of this port as the starting point of the connection. For click-type connection, the server records the node or port clicked by the user for the first time as the starting point, and then waits for the user to click the second node or port to determine the target point. When the user completes the connection operation (such as releasing the mouse button or clicking the target node), the server determines the target point of the connection, which is usually the node below the mouse release position or a specific node input port. The server determines the target node and its input port through spatial collision detection or nearest distance calculation. In another embodiment, the server can automatically attract to the nearest valid input port to improve the accuracy of user operation. In addition to direct user interaction, the connection instruction can also be derived from programmed operation, such as through API call, importing existing process definition, or executing automatic layout algorithm, etc. In these cases, the connection instruction is usually provided in the form of data structure, which explicitly specifies the start node ID and the target node ID. The server finally converts the start node and the target node corresponding to the connection instruction into a standardized internal representation, which usually includes the start node ID, the target node ID, etc.

[0153] The node types of the start node and the target node and their node attributes can be obtained from the server by retrieving complete node metadata. First, the server looks up the corresponding node object from the process definition store according to the node ID identified in the previous step. The node object is usually stored in an in-memory graph data structure or a state management server. For each node, the server needs to obtain its basic type information, i.e., whether the node belongs to a trigger event node, a logic processing node, or a response event node. The node type determines the role and behavior characteristics of the node in the process and is an important basis for judging the legality of the connection. For example, a trigger event node can usually only serve as the starting node of the connection, but not as the target node; a response event node can usually only serve as the target node of the connection, but not as the starting node. In addition to the basic type, the server also needs to obtain the detailed sub-type or functional type of the node. For example, a trigger event node can be divided into different sub-types such as button click trigger, form submission trigger, and timing trigger; a logic processing node can be divided into different functional types such as conditional judgment, data conversion, and API call. These sub-type information helps to further judge the connection compatibility between nodes.

[0154] Next, the server needs to obtain the complete attribute configuration of the node. For a trigger event node, it needs to obtain its trigger conditions, trigger sources, and trigger parameters, etc.; for a logic processing node, it needs to obtain its processing logic, conditional branches, and data conversion rules, etc.; for a response event node, it needs to obtain its response actions, target objects, and response parameters, etc. These attributes not only define the behavior of the node itself, but also imply the constraints of the connection with other nodes.

[0155] Especially important is that the server needs to obtain the input and output definitions of the node. The input definition describes the data type, format, and structure that the node expects to receive, which may include required fields, optional fields, field types, and value ranges, etc. The output definition describes the data type, format, and structure produced by the node, which also includes field lists, type information, and data examples, etc. Input and output definitions are usually represented in JSON Schema, TypeScript type definition, or custom type description language.

[0156] According to the preset connection rule, it is judged whether the output type of the starting node is compatible with the input type of the target node. Specifically, the type compatibility check ensures that the data can be correctly understood and processed when flowing between nodes, avoiding runtime errors. First, the server needs to load the preset connection rule, which defines the allowed connection mode between different types of nodes and the compatibility judgment standard of data types. The connection rule contains two parts: node type compatibility matrix and data type compatibility rule. The node type compatibility matrix defines whether the connection between different types of nodes is allowed. For example, the rule stipulates that the trigger event node can be connected to the logic processing node or the response event node, the logic processing node can be connected to other logic processing nodes or response event nodes, and the response event node cannot usually be the starting point of the connection. The server first checks whether the basic types of the starting node and the target node meet the rules in the matrix. If the node types themselves are not compatible (such as trying to connect from the response event node to the trigger event node), the server will directly determine that the connection is not compatible, and there is no need for subsequent data type checking. Next, the server needs to check the compatibility of data types. Specifically, the output type definition of the starting node and the input type definition of the target node can be compared to determine whether the data can flow correctly. Type conversion allows implicit or explicit type conversion under certain rules, such as number to string, string to date, etc. The sub-type relationship judgment is based on the inheritance or extension relationship of types. If the output type is a sub-type of the input type, it is determined to be compatible. The structure compatibility check is more complex for the fields and nested structures of complex data structures (such as objects or arrays), to determine whether the output structure contains all the necessary fields required by the input and the correct field types. The result of the type compatibility check is a boolean value, indicating whether the output type of the starting node is compatible with the input type of the target node. If compatible, the process will continue to the next step of dependency relationship checking; if not compatible, the server will refuse to establish the connection, and may provide detailed incompatible reason explanation to the user, helping the user to understand and solve the type mismatch problem.

[0157] Determining whether the starting node and the target node meet the dependency relationship or constraint condition defined in the node attribute is a deep-level check for connection verification, ensuring that the connection between nodes is not only compatible in type, but also meets the business logic and functional requirements. Dependency relationships and constraint conditions reflect the functional characteristics and usage restrictions of specific nodes.

[0158] In practice, the server first needs to check the dependency relationships explicitly defined in the node properties. Dependency relationships describe the preconditions or contextual environment required for a node to function properly, which can include necessary upstream node types, specific data preprocessing or state requirements, etc. For example, a data aggregation node can depend on upstream nodes providing grouping fields; a conditional branching node can depend on upstream nodes providing specific data fields required for the judgment condition. The server needs to analyze the dependency definitions of the target node and check whether the starting node can meet these dependency requirements. Second, the server needs to check the constraints defined in the node properties. Constraints limit the connection mode, number, or combination pattern of nodes, ensuring the rationality and executability of the process structure. Common constraints include: input / output port number limits, such as some nodes may stipulate that they can accept at most one input connection or generate at most two output connections; connection level limits, such as prohibiting forming a loop connection or limiting the maximum nesting depth; node combination pattern limits, such as certain nodes must be arranged in a specific order or certain nodes cannot be directly connected. The server needs to judge whether the new connection will violate any constraint rules based on these constraints, combined with the overall structure of the current process and the existing connection situation.

[0159] In actual implementation, the dependency relationship and constraint condition check can use a rule engine, a constraint solver, or custom verification logic. The checking process needs to consider the global state of the entire flowchart, not just the local relationship between two connected nodes. For example, checking whether a loop connection is formed requires traversing the entire graph structure; checking the integrity of data flow may require analyzing all possible paths from the trigger node to the response node. The result of dependency and constraint checking is also a Boolean value, indicating whether the starting node and the target node meet all necessary dependency relationships and constraints.

[0160] If the types are compatible and the dependency or constraint conditions are met, it is determined that there is a connection relationship between the starting node and the target node, that is, only when the output type of the starting node is compatible with the input type of the target node and all necessary dependency relationships and constraint conditions are met, the server will enter the connection creation phase. If any verification fails, the server will refuse to establish the connection and may provide detailed error information and correction suggestions to the user. When all verifications pass, the server begins to create actual connection objects or records. The connection is usually represented as a data structure containing the starting node ID, starting port ID, target node ID, and target port ID. In a graphical process editor, the connection also corresponds to a visual connection element with specific styles, paths, and interactive behaviors. The server adds the newly created connection to the connection list or edge set of the process definition, updating the overall structure of the process.

[0161] By accurately identifying the starting node and target node corresponding to the connection instruction, the server can accurately capture the user's connection intention. Secondly, by obtaining the type and attribute information of the node, the server establishes the data basis for connection verification. Then, the server judges the type compatibility between nodes based on the preset connection rules, ensuring that data can be correctly transferred. Next, the server checks the dependency relationship and constraint conditions between nodes to ensure that the connection meets the business logic and functional requirements. Finally, in the case of all verifications passing, the server establishes and records the connection relationship between nodes, completing the construction of the process structure. This multi-level connection verification mechanism not only prevents incorrect connections during design, but also improves the executability and stability of the process. Through visual connection operations and immediate verification feedback, the server greatly reduces the difficulty and threshold of process design, enabling non-technical personnel to create complex and correct business processes. At the same time, strict type checking and constraint verification also provide reliable protection for subsequent process execution, reducing runtime errors and exceptions, effectively solving the correctness and reliability problems of process design in low-code platforms.

[0162] In one embodiment of the present embodiment, based on the event node and event flow connection, event flow configuration data is generated, including the following steps:

[0163] S610, traverse all event nodes on the event arrangement canvas, and obtain the node identifier and node attribute of each event node;

[0164] S620, traverse all event flow connections on the event arrangement canvas, and determine the starting node identifier and target node identifier of each connection according to the graphical representation of the event flow connection;

[0165] S630, determine the connection condition of the event flow connection according to the node attribute of the connection starting node;

[0166] S640, generate JSON format configuration data containing event flow structure and execution logic according to the node attribute of the event node and the execution order of the event flow connection.

[0167] Among them, generating JSON format configuration data containing event flow structure and execution logic according to the node attribute of the event node and the execution order of the event flow connection includes:

[0168] S1, create a top-level JSON object to represent the entire event flow;

[0169] S2, create a node list JSON array in the top-level JSON object to store information of all event nodes;

[0170] S3, encapsulate the node identifier, node type and node attributes of each event node into an independent node JSON object, and add it to the node list JSON array;

[0171] S4, create a connection list JSON array in the top-level JSON object to store the information of all event flow connections;

[0172] S5, encapsulate the starting node identifier, target node identifier and connection condition of each event flow connection into an independent connection JSON object, and add it to the connection list JSON array.

[0173] In this embodiment, the traversal process can use depth-first search (DFS) or breadth-first search (BFS) algorithm to obtain all node elements from the data model or DOM structure of the canvas. In actual implementation, the node list can be obtained directly through the internal data structure of the canvas (such as node set, graph data structure), or the DOM elements of all nodes can be obtained through DOM selector. For each identified node, first get its unique node identifier, which is usually a UUID or an incremental ID, used to uniquely identify the node in the entire flow. The node identifier is stored in the data-id attribute of the node, the id field of the node object or the index of the canvas data model. Next, get the complete attribute set of the node, which defines the behavior and characteristics of the node. Node attributes usually include: node type, node name, node description, node position, etc. These attributes are stored in the data attribute of the node, the attribute field of the node object or the associated configuration object. After traversal, the identifiers and attributes of all nodes will be collected into a unified data structure (such as array or map), providing basic data for subsequent connection analysis and configuration generation.

[0174] Traverse all event flow connections on the event orchestration canvas, and determine the starting node identifier and target node identifier of each connection according to the graphical representation of the event flow connection. After completing the node information collection, the connection relationship between nodes needs to be identified, which defines the execution path and data flow direction of the event flow. The traversal method of connection is similar to that of node, which can directly obtain all connections through the internal data structure of the canvas (such as edge set, connection list), or can obtain the DOM elements of all connections through DOM selector. For the visual editor, the connection is usually represented by line, arrow or curve graphical elements, connecting the output port and input port of two nodes. In the traversal process, first identify the graphical representation of each connection, which can be SVG path, Canvas drawn line or special DOM element.

[0175] From the graphical representation, it is necessary to extract the geometric information of the connection, such as the starting point coordinates, the ending point coordinates, the control points, etc. Based on the geometric information of the connection, the starting node and the target node associated with the connection are determined. This can be achieved by finding the node output port closest to the starting point coordinates and the node input port closest to the ending point coordinates. In one embodiment, the connection directly stores references or identifiers of the starting node and the target node, without the need for inference through geometric calculations. Once the starting node and the target node of the connection are determined, their node identifiers are extracted. The node identifiers are used to represent the connection relationship between the nodes in the configuration data.

[0176] The connection conditions for event flow connections are determined based on the node properties of the connection's starting node. Connection conditions determine when and how process execution transitions from one node to another and are key factors in controlling process branching and data flow. For each identified connection, the properties of its starting node are analyzed, particularly those related to output behavior and conditional judgments, to determine the conditions that apply to the connection. First, the starting node type must be examined. Different node types may have different connection condition logic. For example, an event-triggered node may trigger different output paths for different event types. For event-triggered nodes, connection conditions can be specific to the event type or event parameter conditions. For example, a form submission event may trigger different processing flows based on different form field values. In addition to node type, specific node configurations and properties must also be considered. For example, nodes define conditional mappings for output ports, explicitly specifying the triggering conditions for each output port; configure data transformation rules, defining how output data is processed and delivered; and set priorities or weights on nodes, affecting the execution order when multiple conditions are met simultaneously.

[0177] In this embodiment, JSON format configuration data including the event process structure and execution logic may be generated according to the node attributes of the event node and the execution order of the event process connection.

[0178] Specifically, first create a top-level JSON object as a container for the entire event process configuration. The top-level object typically contains basic process information, such as metadata such as the process ID, name, description, version number, creation time, and last modification time, as well as two main components: a node list and a connection list. Within the top-level JSON object, create a node list JSON array to store detailed information for all event nodes. For each event node, create a node JSON object containing basic properties such as the node's identifier, type, name, and position. Add all node JSON objects to the node list array, maintaining the original order of the nodes or sorting them by specific rules (such as type, position, or dependency).

[0179] Similarly, within the top-level JSON object, create a connections list JSON array to store the details of all event flow connections. For each event flow connection identified in the previous step, create a connection JSON object containing the basic properties of the connection such as the starting node identifier, target node identifier, connection type, and the connection conditions determined in the previous step. The final generated JSON configuration data is a structured textual representation that fully describes the structure and execution logic of the event flow, which can be parsed and executed, or serialized for storage or transmission through an API.

[0180] The top-level JSON object is a JavaScript object containing multiple key-value pairs, serving as the root container for the entire configuration. All process-related information will be organized within this object. First, an empty JavaScript object needs to be initialized, which can be created using the object literal syntax. This object serves as the root node of the JSON configuration, and all other configuration information will be added as its properties or nested structures. Next, basic metadata properties need to be added to the top-level object, which provide basic information and context for the process. Metadata properties include: id (a unique identifier for the process, usually a UUID or custom ID), name (the name of the process for display and identification), description (a description of the process providing more detailed explanation), version (the version number of the process for version control), etc.

[0181] Create a nodes list JSON array within the top-level JSON object to store information for all event nodes, providing a unified storage structure for all nodes. The nodes list contains detailed information and configurations for all nodes in the process. First, add a property named "nodes" to the top-level JSON object with an empty array [] as its value. This array will be used to store JSON object representations of all nodes. The creation of the nodes list array usually uses simple array literal syntax or the Array constructor function.

[0182] The node identifier, node type, and node properties of each event node are encapsulated into an independent node JSON object and added to the node list JSON array. This converts the information of event nodes into a standardized JSON structure and integrates it into the process configuration. For each event node, a new JSON object needs to be created, which will fully represent all the characteristics and configurations of the node. First, an empty JavaScript object is created as the JSON representation of the node. This can be achieved through object literal syntax ({} ) or the Object constructor function. Next, the node object is added with id (the unique identifier of the node), type (the type of the node), and node properties, which can be the name of the node, the position and size information of the node. After the node object is created, the push method of the array is used to add the node object to the node list array. Repeat this process to create a JSON object for each identified node and add it to the node list until all nodes have been processed. In this way, the information of all nodes is converted into a unified JSON structure and integrated into the node list of the process configuration, providing a foundation for subsequent connection definition and process execution.

[0183] A connection list JSON array is created within the top-level JSON object to store the information of all event process connections, providing a unified storage structure for all connections in the process. The connection list describes the relationship between nodes and the data flow direction. First, add a property with an empty array as its value in the top-level JSON object to store the JSON object representation of all connections. Similar to the node list, the creation of the connection list usually uses array literal syntax or the Array constructor function.

[0184] The starting node identifier, target node identifier, and connection condition of each event process connection are encapsulated into an independent connection JSON object and added to the connection list JSON array. For each event process connection, a new JSON object needs to be created, which will fully represent all the characteristics and conditions of the connection. First, an empty JavaScript object is created as the JSON representation of the connection. This can be achieved through object literal syntax or the Object constructor function. Next, the connection object is added with basic properties that define the core relationship of the connection. The most basic properties include: the unique identifier of the connection, the identifier of the starting node, and the identifier of the target node. These basic properties clearly define the two ends of the connection and establish the relationship between nodes.

[0185] The present embodiment converts the visual arrangement result into JSON configuration data containing complete topology structure and execution logic by traversing the event nodes and connection relationships, and establishes a unified machine-readable process description specification. The JSON format configuration data not only retains business semantics (such as node attributes), but also clearly defines technical implementation details (such as connection conditions), effectively solving the distortion problem of natural language requirements to code conversion; the generated JSON configuration data as an intermediate layer representation independent of specific implementation can be directly used to generate native JavaScript code, or can be used as a process template for persistent storage, realizing the decoupling of business logic definition and runtime execution, so that process modification does not require re-coding, and only updating the configuration data can trigger automatic code refactoring; through the dynamic association of connection conditions and node attributes, the configuration data can express non-linear execution paths. Compared with the traditional hard coding method, this declarative process description makes the adjustment of complex business rules can be completed through visual operation, significantly reducing the development and testing cost of logic changes, and finally realizing high-fidelity conversion from visual arrangement to executable code, so that non-technical personnel can also define complex business logic through intuitive operation, while ensuring the reliability and maintainability of the generated code, and improving the overall development efficiency.

[0186] In one of the embodiments of the present embodiment, converting the event flow configuration data into native JavaScript code includes the following steps:

[0187] S710, parse the event flow configuration data to extract the node list and the connection list;

[0188] S720, according to each node JSON object in the node list, convert its node type and node attribute into corresponding JavaScript function body logic;

[0189] S730, according to each connection JSON object in the connection list, determine the starting node, the target node and the connection condition, and generate event listening / callback functions for controlling function call order and data transmission based on the starting node, the target node and the connection condition;

[0190] S740, based on the generated JavaScript function body logic and event listening / callback functions, assemble to obtain native JavaScript code.

[0191] Parse the event flow configuration data to extract the list of nodes and connections from the configuration data. The event flow configuration data is usually stored in JSON format, which contains all the necessary information to describe the entire event flow. First, parse the configuration data from a string to a JavaScript object using the JSON.parse() method, or use the object directly if the configuration data is already in object form. Then, extract the list of nodes (nodes) and the list of connections (connections) from the parsed object. The list of nodes contains all the node information in the flow, and each node is a JSON object containing the node ID, node type (such as start node, condition node, action node, end node, etc.), and node-specific properties (such as condition expression, execution action, etc.). The list of connections contains the connection relationships between all nodes in the flow, and each connection object contains the starting node ID, target node ID, and possible connection conditions.

[0192] According to each node JSON object in the list of nodes, convert its node type and node properties to the corresponding JavaScript function body logic. Specifically, first, traverse each node object in the list of nodes, and determine the JavaScript function type of the node based on the node type attribute. For different types of nodes, the conversion logic is different: the start node is usually converted to the entry function of the flow, containing initialization logic and a call to the next node; the condition node is converted to a function containing a conditional judgment statement, which determines which branch of the next node to call based on the condition expression result; the action node is converted to a function that performs specific operations, such as data processing, API calls, etc.; the end node is converted to the end function of the flow, which may contain cleaning up resources or returning the result logic.

[0193] During the conversion process, the properties of the nodes need to be converted to the corresponding JavaScript code. For example, the condition expression of the condition node needs to be converted to the if-else statement of JavaScript. In addition, a unique function name needs to be generated for each node, which can usually use the combination of node ID or node type plus ID as the function name. Finally, each node will be converted to a complete JavaScript function definition, including the function name, parameter list, and function body.

[0194] According to each connection JSON object in the connection list, determine the starting node, target node and connection condition, and generate event listener / callback functions for controlling function call order and data transfer based on this information. First, traverse each connection object in the connection list to extract the starting node ID, target node ID and connection condition. Then, according to the type of the starting node and the connection condition, generate the corresponding event listener or callback function code. For connections between ordinary nodes, direct function call code can be generated, i.e. call the target node function at the end of the starting node function; for connections of conditional nodes, conditional branch code needs to be generated according to the connection condition, and the corresponding target node function is called when the condition is met; for nodes involving events (such as user interaction nodes), event listener code needs to be generated to call the target node function when the event is triggered.

[0195] In this embodiment, the callback function is used to: manage the asynchronous execution flow between JavaScript functions; determine whether to execute the subsequent JavaScript function according to the connection condition; pass the execution result of the previous JavaScript function as a parameter to the next JavaScript function; capture and handle exceptions that may occur during the execution of the JavaScript function according to the error handling logic defined in the event flow configuration data; trigger system events or user interface updates associated with a specific execution state.

[0196] Finally, based on the generated JavaScript function body logic and event listener / callback functions, native JavaScript code is assembled.

[0197] Among them, based on JavaScript functions and event listeners, native JavaScript code is generated, including:

[0198] S10, create a JavaScript closure or module to encapsulate the logic of the entire event flow and avoid global namespace pollution;

[0199] S20, define all JavaScript functions converted from event nodes inside the closure or module;

[0200] S30, set up event listeners to bind user interface interactions or other trigger sources to the corresponding starting JavaScript function;

[0201] S40, implement callback function logic to arrange the call relationship, condition judgment and data flow between JavaScript functions according to the connection list information;

[0202] S50, integrate the JavaScript code containing all function definitions, event listener settings, and callback logic into one or more.js files.

[0203] In JavaScript development, global variables and functions can easily cause naming conflicts, especially in large applications or multi-team collaboration. To avoid this problem, use closure or modularization to encapsulate event flow logic. Closure refers to a combination of a function and its accessible external scope variables, which can limit variables and functions to local scope and prevent pollution of the global environment. Closure or modular encapsulation makes event flow logic more independent, reduces the risk of accidental modification, and facilitates code organization and debugging.

[0204] Event nodes may represent different business logic during the visual arrangement phase, such as data validation, API calls, or UI updates. In the code generation phase, each node is mapped to an independent JavaScript function. The definition of these functions follows the property configuration of the event node, such as parameters, return values, and dependencies. The input of the function may come from user interaction or the output of the previous node, while the output may be passed to the next node or directly update the UI. Modular function definition makes business logic clear and traceable, facilitating subsequent maintenance and expansion.

[0205] Event listeners monitor user actions (such as clicks, inputs, scrolling, etc.) or system events (such as network request completion, timer triggering, etc.), and execute the corresponding JavaScript functions when the event occurs. The setting of the event listener needs to consider the event type, event target (such as a specific DOM element), and whether to use event delegation to optimize performance. For example, if multiple similar elements need the same event handling, you can set a listener on the parent element and use event bubbling to reduce memory usage. Reasonable configuration of event listeners ensures that user interactions can accurately trigger the expected business logic while avoiding unnecessary performance loss.

[0206] Callback functions are used to define the execution order and data transfer rules between different JavaScript functions, arranging the call relationship, conditional judgment, and data flow between JavaScript functions according to the connection list information. Callback logic can be implemented through chain calls or use conditional judgment to handle branch processes. Data flow can be achieved through function parameters and return values, for example, the output of the previous function as the input of the next function. Reasonable arrangement of callback logic enables the event flow to execute as expected in visual arrangement, avoiding logic confusion or data loss.

[0207] The final JavaScript code needs to be organized according to the modular principle, such as splitting related functions into multiple.js files to improve maintainability. For example, event listeners can be centralized in an event-handlers.js file, business logic functions in logic.js, and data manipulation functions in data.js. Files can be loaded on demand through tags.

[0208] The native JavaScript code generated by the embodiment does not need to rely on additional runtime libraries and can be directly executed in a browser or Node.js environment, with high performance and compatibility. In addition, since the code is generated according to uniform conversion rules, it has good consistency and maintainability, reducing errors that may be introduced by manual coding. This technical solution is particularly suitable for scenarios that need to frequently adjust business processes, allowing non-technical personnel to define processes through visual tools and then automatically generate corresponding code implementations, thereby effectively separating business and technology and achieving automatic conversion from visual process design to executable code, greatly improving development efficiency and code consistency.

[0209] In one embodiment of the present embodiment, a rendering engine is called to render the page style and page data of the visual development interface according to the native JavaScript code, including the following steps:

[0210] S810, initializing the running environment of the rendering engine;

[0211] S820, injecting the native JavaScript code into the DOM structure of the visual development interface;

[0212] S830, parsing the page component layout and style configuration information of the visual development interface;

[0213] S840, applying CSS rules according to the page component layout and style configuration information to render the static page style of the visual development interface;

[0214] S850, executing the initialization part of the native JavaScript code and establishing the binding relationship between the page components of the visual development interface and the data source, which is determined by the native JavaScript code according to the execution order of the event flow;

[0215] S860, filling the content of the page components according to the binding relationship and the data source, and completing the rendering of the page data.

[0216] Initializing the runtime environment of the rendering engine can be achieved by creating and configuring various resources and environmental parameters required by the rendering engine. First, a dedicated rendering context needs to be created in the browser or application, which can create a Canvas element or a WebGL context for subsequent graphics rendering operations. At the same time of creating the rendering context, appropriate viewport size, resolution and scaling ratio need to be set to ensure consistent display results on different devices. Next, the core components of the rendering engine need to be initialized, including scene graph manager, layout engine, style processor and event dispatch system, etc. In addition, necessary resource files such as fonts, icon libraries and basic style sheets need to be loaded for subsequent rendering process. After resource loading is completed, performance parameters of the rendering engine need to be configured, such as frame rate limit, rendering priority strategy and memory management strategy, to optimize rendering performance and resource utilization. Finally, global event listeners need to be registered to capture user interaction events and system state changes to provide support for subsequent event handling.

[0217] Injecting native JavaScript code into the DOM structure of the visual development interface first needs to determine the location and method of code injection, usually there are three main methods: inline script, external script file and dynamic script creation. For inline script method, directly wrap the JavaScript code in ` <script>`标签中，并插入到HTML文档的适当位置，如`<head>`或`<body>`的末尾。这种方式适合较短的代码片段，且能够确保代码在DOM解析到该位置时立即执行。

[0218] 对于外部脚本文件方式，首先将JavaScript代码保存为独立的.js文件，然后通过标签引用该文件。

[0219] 对于动态脚本创建方式，使用DOM API动态创建`<script>`元素，设置其内容或src属性，然后将其附加到文档中。在注入过程中，可以使用立即执行函数表达式(IIFE)或模块模式来创建私有作用域，隔离变量和函数。

[0220] 解析可视化开发界面的页面组件布局和样式配置信息，可以决定页面的结构和外观。首先，需要从配置数据中提取页面组件的布局信息，这些信息通常以JSON或XML格式存储，描述了组件的类型、层级关系、位置和尺寸等属性。解析过程中，需要将这些描述性数据转换为内存中的组件树结构，每个节点代表一个UI组件，节点之间的父子关系反映了组件的嵌套层级。例如，一个表单组件可能包含多个输入框、按钮等子组件，形成一个组件树。接下来，解析每个组件的样式配置信息，包括颜色、字体、边框、阴影、动画效果等视觉属性。这些样式信息可能来自多个来源，如内联样式、主题配置、全局样式表等，需要按照一定的优先级规则进行合并和覆盖。在解析过程中，还需要处理样式中的变量、函数和计算表达式，如CSS变量、calc()函数等，将它们解析为具体的样式值。此外，对于响应式布局，需要解析媒体查询条件和断点设置，以便在不同屏幕尺寸下应用相应的样式规则。最后，将解析结果存储在内存中的布局树和样式表中，以便于为后续的渲染步骤提供信息。

[0221] 根据页面组件布局和样式配置信息，应用CSS规则，渲染可视化开发界面的静态页面样式，从而构建用户界面视觉呈现。

[0222] 具体来说，首先，需要将样式信息转换为标准的CSS规则集。可以将组件的样式属性映射到对应的CSS属性。在生成CSS规则的同时，还需要为每个组件分配唯一的CSS选择器，通常可以基于组件的ID或类型生成，确保样式能够精确地应用到目标组件上。接下来，将生成的CSS规则注入到文档中，可以通过创建`<style>`元素、添加内联样式或修改现有样式表等方式实现。在应用样式时，需要考虑CSS的层叠和优先级规则，确保样式按照预期的优先级应用。在样式应用完成后，浏览器的渲染引擎会根据CSS规则计算每个元素的最终样式，构建渲染树，并执行布局计算和绘制操作，最终在屏幕上呈现出静态的页面样式。

[0223] 执行原生JavaScript代码中的初始化部分，并建立可视化开发界面的页面组件与数据源的绑定关系。首先，需要执行JavaScript代码中的初始化函数，这通常包括创建应用程序的状态管理器、初始化全局变量、注册事件处理函数等操作。在执行初始化代码时，需要确保DOM已经完全加载，可以通过将脚本放在文档末尾来实现。

[0224] 接下来，根据JavaScript代码中定义的数据模型和事件流程，确定各个页面组件的数据源。数据源可能来自多种渠道，如API请求结果、本地存储数据、用户输入或计算生成的值等。对于每个页面组件，需要明确其依赖的数据字段和更新触发条件。然后，建立组件与数据源之间的绑定关系，可以采用观察者模式或发布-订阅模式实现。具体而言，可以为每个数据字段创建一个可观察对象，当数据发生变化时，通知所有依赖该数据的组件进行更新。在建立绑定关系时，还需要考虑数据的转换和格式化需求，如日期格式化、数值单位转换、文本截断等，确保数据以适当的形式呈现在组件中。此外，对于双向绑定的组件，如输入框、选择器等，还需要设置从组件到数据源的反向更新机制，当用户交互导致组件状态变化时，自动更新对应的数据字段。最后，初始化事件流程控制器，根据事件流程配置，确定各个事件的触发条件和处理逻辑，为后续的用户交互做好准备。

[0225] 最后，根据绑定关系和数据源，填充页面组件的内容，完成页面数据的渲染。首先，需要获取初始数据，可以包括发送API请求、读取本地存储或计算生成初始值等操作。对于异步数据源，如API请求，需要使用Promise或async / await机制处理异步操作，确保数据加载完成后再进行渲染。

[0226] 在获取到数据后，根据前一步骤建立的绑定关系，将数据填充到对应的页面组件中。对于不同类型的组件，填充方式各不相同：文本组件需要设置其textContent或innerHTML属性；图片组件需要设置其src属性；表单组件需要设置其value属性；列表组件需要根据数据数组动态生成子项等。在填充数据时，还需要应用必要的数据转换和格式化操作，确保数据以用户友好的形式呈现。例如，将时间戳转换为可读的日期字符串，将数值添加适当的单位后缀，将长文本截断并添加省略号等。对于条件性显示的组件，需要根据数据条件决定其可见性或禁用状态。此外，还需要处理数据为空或加载失败的情况，显示适当的占位符或错误提示。在完成初始数据渲染后，建立数据变化的监听机制，当数据源发生变化时，自动更新相关组件的内容。可以通过观察者模式或发布-订阅模式实现。最后，触发布局重新计算和重绘操作，确保页面正确显示更新后的内容。通过这一步骤，静态的页面组件被赋予了动态的数据内容，实现了完整的可视化开发界面渲染。

[0227] 本实施方式通过初始化渲染环境、注入JavaScript代码、解析组件布局、应用CSS规则、建立数据绑定和填充页面数据，能够将抽象的代码逻辑转化为直观的可视化界面。渲染结果既保留了原生JavaScript代码的高性能和灵活性，又提供了丰富的视觉效果和交互体验。用户可以在可视化开发界面中直接操作组件、查看数据变化和触发事件流程，无需理解底层代码实现。这一技术方案特别适用于低代码 / 无代码开发平台，使非技术人员也能参与应用开发，同时为专业开发者提供了可视化调试和原型验证的工具，大幅提高了开发效率和协作能力，实现了技术与业务的无缝衔接。

[0228] 在本实施例的其中一种实施方式中，响应于用户在可视化开发界面的交互操作，触发对应的原生JavaScript代码，以执行对应的事件流程，包括如下步骤：

[0229] S910、响应于用户在可视化开发界面的交互操作，根据交互操作，确定事件源和事件类型，并根据事件源和事件类型匹配原生JavaScript代码中绑定的触发事件节点的JavaScript函数；

[0230] S920、执行与触发事件节点对应的JavaScript函数；

[0231] S930、依次调用与触发事件节点相连的逻辑处理节点的JavaScript函数，生成执行结果；

[0232] S940、根据执行结果以及事件流程连接的连接条件，确定一个或多个响应事件节点的执行路径，并按执行路径执行相应的响应事件节点的JavaScript函数。

[0233] 响应于用户在可视化开发界面的交互操作，根据交互操作，确定事件源和事件类型，并根据事件源和事件类型匹配原生JavaScript代码中绑定的触发事件节点的JavaScript函数。当用户在可视化界面上进行操作时，如点击按钮、输入文本、拖拽元素或滚动页面等，浏览器会生成相应的DOM事件。这些事件包含两个关键信息：事件源和事件类型。事件源指的是用户交互操作所作用的具体DOM元素，如特定的按钮、输入框或列表项等；事件类型则描述了交互的性质，如点击、输入等。为了确定事件源，可以从事件对象中获取target或currentTarget属性，这些属性指向触发事件的DOM元素。

[0234] 确定事件类型则直接从事件对象的type属性获取。在获取到事件源和事件类型后，在事件映射表中查找匹配的触发事件节点。这个映射表是在页面初始化时建立的，它将DOM元素的唯一标识(如ID、自定义属性或DOM路径)和事件类型的组合映射到对应的JavaScript函数。例如，ID为"submit-button”的按钮的"click”事件可能映射到名为"handleSubmit”的函数。如果找到匹配的映射关系，则获取对应的JavaScript函数引用，使得可视化开发界面的交互元素与后台逻辑代码解耦，便于独立开发和维护，同时保证了用户交互能够准确触发相应的业务逻辑处理。

[0235] 执行与触发事件节点对应的JavaScript函数，可以将用户的交互操作转化为具体的程序行为。首先，创建函数的执行上下文和确定指向。在事件处理函数中，通常指向事件源元素。对于事件处理函数，参数是事件对象，包含了事件的详细信息，如事件类型、事件源、时间戳、鼠标坐标、按键代码等。除了事件对象外，还需要传入其他上下文数据，如组件状态、全局配置或用户信息等。参数准备完毕后，调用JavaScript函数，开始执行函数体内的代码。在执行过程中，函数访问DOM元素、读取或修改应用状态、发送网络请求、执行计算或触发动画等。

[0236] 依次调用与触发事件节点相连的逻辑处理节点的JavaScript函数，生成执行结果。事件流程可以被建模为一个有向图，其中节点代表不同的处理函数，边表示执行顺序和数据流向。触发事件节点执行完成后，=根据预定义的流程图，确定下一步要执行的逻辑处理节点。逻辑处理节点是专门负责业务逻辑处理的函数单元，如数据验证、格式转换、计算统计、条件判断或业务规则应用等。可以按照流程图中定义的顺序，依次调用这些逻辑处理节点的JavaScript函数。在调用每个函数前，需要准备该函数所需的输入参数。这些参数可能来自多个来源：前一个节点的输出结果、全局状态存储、外部数据源或固定配置等。参数准备完毕后，执行当前逻辑处理节点的函数，并等待其完成。具体的，对于同步函数，可以直接获取返回值；对于异步函数，可以等待解析或回调函数执行完成。通过上述链式调用的方式，复杂的业务逻辑被分解为一系列独立的、可复用的处理单元，提高了代码的模块化程度和可维护性，同时也使得业务流程更加清晰和可视化。

[0237] 根据执行结果以及事件流程连接的连接条件，确定一个或多个响应事件节点的执行路径，并按执行路径执行相应的响应事件节点的JavaScript函数。具体的，首先，评估逻辑处理节点的执行结果，执行结果可以是布尔值、数值、字符串、对象或数组等不同类型的数据。同时，检索事件流程图中定义的连接条件，连接条件描述了不同节点之间的转换规则。连接条件可以是简单的相等比较、范围检查、正则表达式匹配，也可以是复杂的逻辑表达式或函数计算。

[0238] 将执行结果代入这些条件表达式，计算出条件的真假值，从而确定下一步的执行路径。在某些情况下，一个节点可能连接到多个后续节点，形成分支或并行执行路径。对于分支路径，可以根据条件选择一条路径执行；对于并行路径，可以同时执行多个响应事件节点。

[0239] 确定了执行路径后，可以按顺序执行响应事件节点的JavaScript函数。响应事件节点通常负责界面更新、状态变更通知或触发外部系统交互等操作，如更新DOM元素内容、修改样式属性、显示或隐藏组件、触发动画效果、发送通知消息或调用第三方服务等。在所有响应事件节点执行完成后，需要清理临时资源、更新全局状态并准备处理下一次用户交互。

[0240] 本实施方式通过确定事件源和类型并匹配触发函数、执行触发事件节点函数、调用逻辑处理节点函数生成结果、根据结果确定执行路径并执行响应事件节点函数，构建了一个灵活而强大的事件处理框架。这种基于事件流程图的设计使复杂业务逻辑可视化，便于非技术人员理解和配置，同时保留了原生JavaScript的全部能力。该方案可以精确捕获用户意图，执行相应的业务逻辑，并根据处理结果动态决定界面响应方式，实现了高度个性化和上下文相关的用户体验。这一技术方案有效提高了开发效率，降低了维护成本。

[0241] 本申请实施例还提供一种服务器，包括：

[0242] 存储器，被配置成存储指令；以及

[0243] 处理器，被配置成从存储器调用指令以及在执行指令时能够实现上述的基于原生JS的低代码开发平台事件编排方法。

[0244] 本领域内的技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质（包括但不限于磁盘存储器、CD-ROM、光学存储器等）上实施的计算机程序产品的形式。

[0245] 本申请是参照根据本申请实施例的方法、设备（系统）、计算机程序产品的流程图和 / 或方框图来描述的。应理解可由计算机程序指令实现流程图和 / 或方框图中的每一流程和 / 或方框以及流程图和 / 或方框图中的流程和 / 或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能的装置。

[0246] 这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能。

[0247] 这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和 / 或方框图一个方框或多个方框中指定的功能的步骤。

[0248] 在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入 / 输出接口、网络接口和内存。

[0249] 存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和 / 或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

[0250] 计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存 (PRAM)、静态随机存取存储器 (SRAM)、动态随机存取存储器 (DRAM)、其他类型的随机存取存储器 (RAM)、只读存储器 (ROM)、电可擦除可编程只读存储器 (EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘 (DVD) 或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体 (transitory media)，如调制的数据信号和载波。

[0251] 还需要说明的是，术语"包括”、"包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句"包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

[0252] 以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。< / script>

Claims

1. A low-code development platform event orchestration method based on native JS, characterized in that: Applied to a server, the server is deployed with a low-code development platform, which includes a visual development interface, a visualization framework, a rendering engine, and an event orchestration module. The method includes: In response to an event orchestration request sent by a user through a visual development interface, calling a visualization framework and presenting an event orchestration canvas in the visual development interface; Configure event nodes and event process connections in the event orchestration canvas; Generate event process configuration data based on event nodes and event process connections; Parse the event process configuration data and extract the node list and connection list; According to each node JSON object in the node list, its node type and node attributes are converted into corresponding JavaScript function body logic; According to each connection JSON object in the connection list, the starting node, target node and connection conditions are determined, and based on the starting node, target node and connection conditions, an event listening / callback function is generated to control the function call sequence and data transfer; Based on the generated JavaScript function body logic and event listening / callback functions, assemble the native JavaScript code; Call the rendering engine to render the page style and page data of the visual development interface according to the native JavaScript code; In response to user interactions in the visual development interface, the corresponding native JavaScript code is triggered to execute the corresponding event flow; Among them, based on the generated JavaScript function body logic and event monitoring / callback functions, the native JavaScript code is assembled, including: Create a JavaScript closure or module to encapsulate the logic of the entire event flow to avoid global namespace pollution; Inside the closure or module, define all JavaScript functions converted from event nodes; Set up event listeners to bind user interface interactions or other trigger sources to the corresponding starting JavaScript functions; Implement callback function logic and arrange the calling relationship, condition judgment and data flow between JavaScript functions according to the connection list information; Combine JavaScript code containing all function definitions, event listening settings, and callback logic into one or more .js files.

2. The method according to claim 1, characterized in that Before calling the visualization framework, include: Verify user access rights; If the access permission is verified, the event component library is loaded, wherein the event component library includes a plurality of event components; Read metadata information of each event component from the event component library; According to the metadata information, the event components in the event component library are rendered and displayed in the preset component panel area of ​​the visual development interface.

3. The method according to claim 2, characterized in that Configure event nodes and event process connections in the event orchestration canvas, including: In response to the event component drag command, the event component is converted into a corresponding event node on the event arrangement canvas; In response to a user's configuration request for a specific event node, a property configuration panel pops up; Receive node attribute information input by the user through the attribute configuration panel, and configure the attributes of each event node to determine the node attributes of each event node; In response to a user's connection instruction for different event nodes, and based on the node attributes of each event node, determining the connection relationship between different event nodes, and drawing connection lines on the event arrangement canvas according to the connection relationship; Determine the execution order of the event flow based on the connection relationship, and configure the event flow connections based on the execution order of the event flow.

4. The method according to claim 3, characterized in that Event nodes include trigger event nodes, logic processing nodes, and response event nodes. Attribute configuration is performed on each event node to determine the node attributes of each event node, including: For a trigger event node, configure its node attributes as trigger conditions, trigger sources, and / or trigger parameters; For logic processing nodes, configure their node attributes as processing logic, conditional branches and / or data conversion rules; For a response event node, configure its node properties as the response action, target object, and / or response parameters.

5. The method according to claim 3, characterized in that Based on the node attributes of each event node, the connection relationship between different event nodes is determined, including: Identifying a start node and a target node corresponding to a connection instruction; Get the node type and node attributes of the start node and target node; According to the preset connection rules, determine whether the output type of the starting node is compatible with the input type of the target node; Determine whether the dependency or constraint conditions defined in the node attributes are satisfied between the starting node and the target node; If the types are compatible and the dependency or constraint conditions are met, it is determined that there is a connection relationship between the start node and the target node.

6. The method according to claim 3, characterized in that Generate event process configuration data based on event nodes and event process connections, including: Traverse all event nodes on the event orchestration canvas and obtain the node identifier and node attributes of each event node; Traverse all event flow connections on the event orchestration canvas, and determine the start node identifier and target node identifier of each connection based on the graphical representation of the event flow connections; Determine the connection conditions of the event flow connection based on the node attributes of the connection start node; Generates JSON format configuration data containing the event flow structure and execution logic based on the node attributes of the event node and the execution order of the event flow connection.

7. The method according to claim 1, characterized in that Call the rendering engine to render the page style and page data of the visual development interface according to the native JavaScript code, including: Initialize the rendering engine's operating environment; Inject native JavaScript code into the DOM structure of the visual development interface; Parse the page component layout and style configuration information of the visual development interface; Apply CSS rules based on page component layout and style configuration information to render the static page style of the visual development interface; Execute the initialization part in the native JavaScript code and establish the binding relationship between the page components of the visual development interface and the data source. The data source is determined by the native JavaScript code according to the execution order of the event flow; According to the binding relationship and data source, fill the content of the page component to complete the rendering of the page data.

8. The method according to claim 4, characterized in that In response to user interactions in the visual development interface, the corresponding native JavaScript code is triggered to execute the corresponding event flow, including: In response to user interactions in the visual development interface, the event source and event type are determined based on the interaction, and the JavaScript function that triggers the event node bound in the native JavaScript code is matched based on the event source and event type; Execute the JavaScript function corresponding to the trigger event node; Sequentially call the JavaScript functions of the logic processing nodes connected to the trigger event node to generate execution results; According to the execution result and the connection condition of the event flow connection, the execution path of one or more response event nodes is determined, and the JavaScript function of the corresponding response event node is executed according to the execution path.

9. A server, characterized in that: include: a memory configured to store instructions; as well as A processor is configured to call the instructions from the memory and to implement the event orchestration method of a low-code development platform based on native JS according to any one of claims 1 to 8 when executing the instructions.

Images