Low-code development platform event orchestration method and equipment based on native JS (JavaScript)

Abstract

The invention discloses a low-code development platform event arrangement method and device based on native JS, and relates to the technical field of visual programming, and the method comprises the steps: responding 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 process connections in the event arrangement canvas; generating event flow configuration data based on the event node and the event flow connection; converting the event flow configuration data into a native JavaScript code, calling a rendering engine, and rendering a page style and page data of the visual development interface according to the native JavaScript code; and in response to an interactive operation of a user on the visual development interface, triggering the corresponding native JavaScript code to execute a corresponding event process. The development efficiency can be effectively improved, and the development period is shortened.

Description

Technical Field

[0001] The embodiments of the present application relate to the field of visual programming technology, and in particular to an event orchestration method and device for a low-code development platform based on native JS. Background Art

[0002] With the rapid development of information technology and the deepening digital transformation of enterprises, software application systems have become an indispensable core tool supporting business operations across all industries. Software systems permeate every aspect of production, management, sales, and service. As the primary window for human-computer interaction, the user interface (UI)'s user-friendly design, comprehensive functionality, and timely response directly impact user experience and work efficiency. Modern software applications, especially web applications, often require complex interaction logic and business processes. Every user action on the interface, such as clicking a button, filling out a form, dragging an element, and so on (collectively referred to as an "event"), can trigger a series of backend data processing, interface status updates, or linkages with other systems. Efficiently and accurately binding and orchestrating these events with the corresponding business logic is a critical step in software development.

[0003] In current software development practices, front-end development plays a crucial role, responsible for implementing the interfaces and logic with which users directly interact. In the traditional software development process, particularly regarding interface interaction and business logic implementation, a typical project model involves the business department or client proposing a series of requirements regarding business processes, data collection, and interface presentation. These requirements are often communicated to the technical development team through documents, prototypes, or verbal communication. After receiving these requirements, the technical team must carry out a series of steps, including requirements analysis, system design, coding implementation, and testing and verification. During this process, cognitive and communication gaps often exist between the demand side and the technical side. Business personnel often lack understanding of code-level implementation details, while technical personnel may struggle to fully and accurately grasp the nuances and potential constraints of the business processes. This information asymmetry and misunderstanding can easily lead to features being developed that don't meet actual business requirements, resulting in logical inconsistencies, process interruptions, and hidden bugs. The conversion of requirements from natural language or flowcharts to code carries a high risk of information loss and distortion, which in turn prolongs the development cycle.

[0004] Therefore, there is an urgent need for a new technical solution that can improve development efficiency and shorten the development cycle. Summary of the Invention

[0005] The embodiments of the present application provide a method and device for event orchestration of a low-code development platform based on native JS, which are used to improve development efficiency and shorten development cycle.

[0006] To achieve the above objectives, the embodiments of the present application adopt the following technical solutions: In a first aspect, a method for event orchestration of a low-code development platform based on native JS is provided, which is applied to a server. The server is deployed with a low-code development platform, which includes a visual development interface, a visual 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; Convert the event flow configuration data into native JavaScript code, and 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 the user's interactive operation in the visual development interface, the corresponding native JavaScript code is triggered to execute the corresponding event process.

[0007] In a possible implementation of the first aspect, before calling the visualization framework, the following steps are included: 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.

[0008] In another possible implementation of the first aspect, configuring event nodes and event process connections in the event choreography canvas includes: 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.

[0009] In another possible implementation of the first aspect, the event node includes a triggering event node, a logic processing node, and a response event node. Attribute configuration is performed on each event node to determine 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.

[0010] In another possible implementation of the first aspect, determining a connection relationship between different event nodes based on a node attribute of each event node includes: 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 satisfied, it is determined that there is a connection relationship between the start node and the target node.

[0011] In another possible implementation of the first aspect, generating event process configuration data based on event nodes and event process connections includes: 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.

[0012] In another possible implementation of the first aspect, converting the event process configuration data into native JavaScript code includes: 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, native JavaScript code is assembled.

[0013] In another possible implementation of the first aspect, calling a rendering engine to render a page style and page data of a visual development interface according to native JavaScript code includes: 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.

[0014] In another possible implementation of the first aspect, in response to a user's interactive operation on a visual development interface, triggering corresponding native JavaScript code to execute a corresponding event flow includes: 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.

[0015] In a second aspect, the present application provides a server, comprising: a memory configured to store instructions; and The processor is configured to call the instructions from the memory and to implement the above-mentioned native JS-based low-code development platform event orchestration method when executing the instructions.

[0016] Through the above technical solution, a low-code development platform event orchestration method based on native JS is provided. Through the visual event orchestration 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 needs and technical implementation, reduces the loss and misunderstanding in the process of information transmission, and enables business personnel to participate more directly in the application development process. In addition, since standard native JavaScript code is generated rather than proprietary code that relies on a specific framework or runtime, the developed application has better portability and maintainability. In actual application, this method can effectively shorten the development cycle. At the same time, since the dependence on professional developers is reduced, enterprises can more flexibly allocate technical resources, further improve development efficiency and reduce development costs.

[0017] Other features and advantages of the embodiments of the present application will be described in detail in the subsequent detailed description. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 A flowchart of an event orchestration method for a low-code development platform based on native JS provided in an embodiment of the present application; Figure 2 A schematic diagram of the structure of a server provided in an embodiment of the present application; Figure 3 A schematic diagram of a visual development interface provided in an embodiment of the present application; Figure 4 A schematic diagram of an event arrangement canvas operation process provided in an embodiment of the present application; Figure 5 A schematic diagram of an event node attribute configuration process provided in an embodiment of the present application; Figure 6 A schematic diagram of an event process execution flow during runtime provided in an embodiment of the present application. DETAILED DESCRIPTION

[0019] To make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. It should be understood that the specific implementation methods 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 ordinary technicians in this field without making creative work are within the scope of protection of this application.

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

[0021] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present application, the descriptions of "first", "second", etc. are only for descriptive purposes and cannot be understood as indicating or suggesting their relative importance or implicitly indicating the number of the indicated technical features. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of such features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the fact that they can be implemented by ordinary technicians in this field. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by this application.

[0022] Figure 1 The following schematically shows a flow chart of a method for arranging events on a low-code development platform based on native JS according to an embodiment of the present application. Figure 1 As shown, an embodiment of the present application provides an event orchestration method for a low-code development platform based on native JS, which is applied to a server. The server is deployed with a low-code development platform. The low-code development platform includes a visual development interface, a visual framework, a rendering engine and an event orchestration module. The method may include the following steps.

[0023] S110 , 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; S120. Configure event nodes and event process connections in the event orchestration canvas; S130, generating event process configuration data based on the event node and event process connection; S140: Convert the event process configuration data into native JavaScript code, and call a rendering engine to render the page style and page data of the visual development interface according to the native JavaScript code; S150 . In response to the user's interactive operation on the visual development interface, trigger the corresponding native JavaScript code to execute the corresponding event process.

[0024] Figure 3 A schematic diagram of a visual development interface provided by an embodiment of the present application is shown. In a specific implementation, when a user Figure 3 When a button is clicked or a menu item is selected in the visual development interface shown, the server captures this user interaction event and identifies it as an event orchestration request. This request is transmitted to the server-side event orchestration module via an HTTP request or a WebSocket connection. Upon receiving the request, the event orchestration module first verifies the user's operating permissions to ensure that the user is authorized to perform event orchestration. After the permissions are verified, the event orchestration module calls the visualization framework's API 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 interactive capabilities such as a grid background, zoom control, and drag-and-drop functionality. At the same time, the visualization framework also initializes the state management server of the event orchestration canvas to track the position, connection relationships, and attribute information of each element on the canvas.

[0025] After canvas initialization is complete, the visualization framework renders the event orchestration canvas in the main workspace of the visual development interface and loads the available event component library into the sidebar of the interface, including trigger event components (such as button clicks, form submissions, page loads, etc.), logic processing components (such as conditional judgments, loops, data conversions, etc.), and response event components (such as page jumps, data submissions, UI updates, etc.). Through these components, users can drag and drop draggable components from the left or right sidebar of the workspace to the event orchestration canvas. In addition, the visualization framework also initializes the canvas toolbar. In this embodiment, it is located on the upper side of the page and provides operation buttons such as Save to enhance the user's editing experience.

[0026] Figure 4 FIG. 1 shows a schematic diagram of an event arrangement canvas operation process provided by an embodiment of the present application, such as Figure 4As shown in the figure, configuring event nodes and event flow connections in the event orchestration canvas includes the following steps: (a) Drag an event component (such as "Button Click") from the component library onto the canvas to create an event node. (b) The canvas must already have at least two nodes (for example, a trigger node and a response node). (c) Drag a connection line from the output anchor point of the starting node to the input anchor point of the target node to create an event flow connection.

[0027] Once the event orchestration canvas appears, users can drag and drop event components from the component library and place them at the appropriate location on the canvas. Each time an event component is dropped onto the canvas, the visualization framework converts it into a corresponding event node and assigns it a unique node identifier. Event nodes are represented on the canvas by visual shapes (such as rectangles, circles, or custom icons) and display basic node information, such as node type and name. Users can double-click a node or right-click and select "Configure" to open the node's property configuration panel. The property configuration panel dynamically generates different configuration options based on the node type. For example, for trigger event nodes, you can configure the trigger condition (such as "click," "hover," or "input"), the trigger source (such as a selector for a specific DOM element), and the trigger parameters. For logic processing nodes, you can configure the processing logic (such as conditional expressions and loop conditions), conditional branching, and data transformation rules. For response event nodes, you can configure the response action (such as "show," "hide," or "update"), the target object, and the response parameters. After configuring node properties, the visualization framework updates the node's visual representation in real time to reflect the configuration changes. After configuring the event nodes, define the connection relationship between the nodes, that is, the event flow connection. In one embodiment, the event flow connection is automatically generated, and the event flow connection can be determined based on the association relationship between the event nodes. In another embodiment, the user can create a connection line by clicking the output anchor point of the starting node and then 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 of the connection. For example, it ensures that the trigger event node can only be connected to the logic processing node or the response event node, but not to another trigger event node. For logic processing nodes with conditional branches, different conditional expressions can be configured for each branch, and different branch paths can be represented by connecting lines with different colors or labels. In addition, the path and shape of the connecting line can be adjusted to optimize the visual representation of the event flow.

[0028] Event flow configuration data is generated based on event nodes and event flow connections. Once event node configuration and event flow connections are complete, 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, obtaining basic information for each node, including the node identifier (typically a unique string in UUID format), node type (trigger event, logic processing, or response event), node location coordinates (used for positioning on the canvas), and detailed node property configuration. For trigger event nodes, property configuration includes the event type, event source selector (such as "#submitButton," ".form-input," etc.), and event parameters; for logic processing nodes, property configuration includes the processing function definition, input parameter mapping, and output parameter definition; and for response event nodes, property configuration includes the response action type, target element selector, and response parameters.

[0029] Next, the visualization framework traverses all connections on the canvas, obtaining each connection's start and destination node identifiers, connection type (such as "normal flow," "conditional branch," or "error handling"), and connection condition. For conditional branch connections, the connection condition is typically a JavaScript expression or function that is used to evaluate at runtime whether execution should continue along that path.

[0030] The visualization framework then organizes the collected node and connection information into a structured JSON object, which typically contains two main parts: a nodes array (containing detailed information about all nodes) and a connections array (containing detailed information about all connections). In addition, the JSON object may also contain a metadata section that records information such as the name of the event process, creation time, last modification time, and version number. Finally, the visualization framework verifies the generated JSON object to ensure that its structure is complete and the data type is correct, and checks for potential problems such as isolated nodes (i.e., nodes without any connections) or circular dependencies (node connection patterns that may lead to infinite loops). After verification, the event process configuration data is temporarily stored in the client memory, awaiting further processing.

[0031] 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.

[0032] 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.

[0033] Once code generation is complete, the rendering engine is invoked to inject the generated JavaScript code into the DOM structure of the visual development interface. The rendering engine first parses the page's component layout and style configuration information, applying CSS rules to render the static page style. The injected JavaScript code is then executed, binding the page components to the data source and populating the page content based on the initial data. The rendering process utilizes virtual DOM technology, first constructing a DOM tree in memory and then comparing it with the actual DOM. Only the changed parts are updated, improving rendering efficiency.

[0034] like Figure 6 The figure shows how user interaction triggers the execution of an event flow. Specifically, in response to user interactions on the visual development interface, the corresponding native JavaScript code is triggered to execute the corresponding event flow. When users interact with the rendered visual development interface (such as clicking a button, entering text, selecting an option, etc.), these actions trigger DOM events. The browser's event server captures these DOM events and searches for matching event listeners based on the event type and event target element. These event listeners are part of the native JavaScript code generated and injected into the page in the previous step.

[0035] When a matching event listener is triggered, the initialization logic within the event handler is first executed, such as preventing default behavior, stopping event propagation, and obtaining event-related data. The event handler then determines the JavaScript function corresponding to the triggering event node based on the event flow configuration and executes that function. The JavaScript function of the triggering event node typically collects data generated by user interactions, such as form input values, selection status, and click locations, and encapsulates this data into an event context object. Next, based on the connections defined in the event flow, the server sequentially calls the JavaScript functions of the logic processing nodes connected to the triggering event node. The logic processing node functions receive the event context object as input and perform operations such as data validation, conversion, and calculations, updating the event context object based on the results. For logic processing nodes containing conditional branches, their JavaScript functions evaluate the conditional expression and select different execution paths based on the expression's result. Finally, based on the execution path, the server calls the JavaScript function of the corresponding response event node.

[0036] Functions in response nodes are responsible for executing specific actions, such as updating UI elements, sending API requests, and triggering animations. These actions are directly reflected in the user interface, providing users with immediate feedback. Throughout the entire event flow, the server maintains a unified event context object, which is used to pass data between different nodes.

[0037] In this embodiment, the following steps may also be included: Provides an API maintenance interface for configuring the data interaction interface with the external system; receives API parameters and authentication information configured by the user through the API maintenance interface; generates API interface configuration and stores the API interface configuration in the database; during the execution of the event process, calls the API interface as needed to realize data exchange with the external system.

[0038] During the execution of the event process, the API interface is called as needed to realize data exchange with the external system, including: during the execution of the logical processing node, identifying the operations that need to call the external API; 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 the external system and receiving the response data from the external system; parsing and converting the response data for the subsequent execution of the event process.

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

[0040] In one implementation of this embodiment, before calling the visualization framework, the following steps are included: S210, verifying the user's access rights; S220: If the access permission is verified, load an event component library, where the event component library includes multiple event components. S230, reading metadata information of each event component from the event component library; S240: Render and display the event component in the event component library in the preset component panel area of the visual development interface according to the metadata information.

[0041] Before invoking the visualization framework, user access rights must be strictly verified to ensure that only authorized users can use the low-code development platform's event orchestration capabilities. When a user attempts to access the low-code development platform, the server automatically triggers a permission verification process. This process first checks the user's login status and verifies the user's identity by verifying the validity of the user session or token.

[0042] For logged-in users, the server retrieves their role information and permission configuration from the user management database. User roles are typically categorized into multiple levels, such as server administrator, development administrator, business developer, and read-only user, each corresponding to a different set of operational permissions. The server compares the user's current role with the minimum required permission level for event orchestration to determine whether the user has the necessary permissions to access the functionality. In addition to role-level permission verification, the server also checks the user's access rights to specific projects or applications. Furthermore, the server performs operation-level permission checks, distinguishing between read and edit permissions for event orchestration. Some users may only be allowed to view existing event flow configurations, but not create or modify them. During permission verification, the server records detailed information about the verification request, including user ID, IP address, request time, requested resource, and verification results, creating a comprehensive audit log to facilitate subsequent security audits and issue tracking. If permission verification fails, the server returns an appropriate error code and message and redirects the user to the login page or insufficient permissions page. The server also logs failed access attempts. Multiple failed access requests within a short period of time may trigger a temporary ban to prevent brute force attacks and malicious attacks.

[0043] Once the user's access rights are successfully verified, the server immediately starts loading the event component library. The event component library is one of the core resources of the low-code development platform and contains various predefined components that users can use in the event orchestration canvas.

[0044] The loading process begins by sending a component library request to the server. This request typically includes parameters such as the user ID, project ID, and platform version number. The server uses these parameters to determine the set of components to return. Upon receiving the request, the server queries the component repository for a list of components applicable to the current user and project. The component repository typically 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). Query results are filtered based on the user's permission level to ensure that users only access components they are authorized to use.

[0045] To optimize loading performance, the server will adopt an incremental loading strategy, first loading basic components and commonly used components, and then asynchronously loading other components in the background. Component loading uses the HTTP / 2 protocol or WebSocket connection, supports multiplexing and server push, and reduces network latency and resource consumption. For components that have already been loaded, the server will use the browser cache mechanism to determine whether they need to be reloaded by comparing component version numbers to avoid repeated transmission of the same resources. The loaded event component library usually includes three categories of components: trigger event components (such as button clicks, form submissions, page loads, timers, etc.), logic processing components (such as conditional judgment, loop traversal, data conversion, API calls, etc.) and response event components (such as page jumps, pop-up displays, data updates, animation effects, etc.).

[0046] After the component is loaded, the server creates a component index in the client's memory for quick search and access to component definitions. At the same time, the server triggers a component loading completion event to notify related modules that they can begin using the component library resources.

[0047] Once the event component library is loaded, the server needs to read metadata for each event component. Metadata is structured data that describes the component's characteristics, behavior, and usage. The metadata reading process first traverses the loaded component library and performs metadata parsing on each component. Component metadata is typically stored in JSON format and contains basic component properties and configuration information. For each component, the server reads its unique identifier, which uniquely identifies it across the platform; the component type, such as triggering an event, logic processing, or responding to an event; the component name and description, which are displayed to users in the interface; the component icon, typically in SVG format or an image URL, for visual display in the component panel; component categories, such as basic components, form components, and data components, for organization and grouping; and version information, which is used for component updates and compatibility management. After metadata reading is complete, the server caches this information in client memory, establishes a component index and category mapping, and provides data support for subsequent component rendering and usage.

[0048] After completing the reading and processing of the event component metadata, the server will render and display each event component in the event component library in the preset component panel area of the visual development interface based on this metadata information.

[0049] The rendering process first determines the layout structure of the component panel, which is usually in the form of a category accordion panel or tab, and displays the components in groups according to their properties. For each category, the server creates a corresponding container element and sets the appropriate title, icon, and expand / collapse controller. Within the category container, the server traverses 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 a short description. Its style and size are uniformly set according to the platform's design specifications. The server sets the component icon according to the icon attribute in the component metadata. If it is in SVG format, it is directly embedded in the DOM; if it is an image URL, an img element is created and the src attribute is set. The component name and description are obtained from the name and description fields of the metadata respectively.

[0050] To enhance the user experience, the server adds rich interactive effects to each component element, such as hover highlighting, click feedback, and drag previews. When the user hovers over a component, the server displays a more detailed description and usage tips. Clicking a component displays detailed configuration options or usage examples. When the user begins dragging a component, the server creates a visual replica that follows the mouse and displays a drop indicator in the droppable area. To support dragging components, the server registers a drag event listener for each component element, implementing the HTML5 drag and drop API or custom drag and drop logic. When a drag begins, the server records the identifier and type of the dragged component. When the drag ends and the component is released within the valid area, the server creates a corresponding event node on the event orchestration canvas. Furthermore, the server implements search and filtering functionality within the component panel, allowing users to quickly find the desired component by searching for keywords or filtering by properties. The search function matches fields such as the component's name, description, and tags, and updates the displayed results in real time. To accommodate different screen sizes and user preferences, component panels typically support operations such as width adjustment, switching display modes (such as list view / grid view), and switching between fixed and floating states. When there are a large number of components, the server implements virtual scrolling technology to render only component elements within the visible area, reducing the number of DOM nodes and improving rendering performance and responsiveness.

[0051] This implementation method ensures secure access to platform resources and prevents unauthorized use and data leakage risks through a user permission verification mechanism. The intelligent loading strategy of the event component library significantly improves the startup speed and response performance of the platform, ensuring the rapid availability of basic functions even under poor network conditions. The structured processing and cache optimization of component metadata enable the server to dynamically adjust interface behavior and function display according to component characteristics and user permissions. In the visual interface, the classified display and interactive optimization of the preset component panels greatly improve the user's operating efficiency and experience, allowing users with different technical backgrounds to intuitively understand component functions and quickly find the required tools, so that the entire low-code development platform can help developers quickly build complex business applications in a more secure, efficient and user-friendly way, effectively improving development efficiency.

[0052] In one implementation of this embodiment, configuring event nodes and event process connections in the event orchestration canvas includes the following steps: S310 , in response to an event component dragging instruction, converting the event component into a corresponding event node on the event arrangement canvas; S320: In response to the user's configuration request for a specific event node, a property configuration panel pops up; S330, 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 attributes of each event node; 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 between the different event nodes, and drawing connection lines on the event arrangement canvas according to the connection relationship; S350: 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.

[0053] for Figure 3 In the visual development interface shown, when the user selects an event component from the component panel and starts dragging, the server will immediately capture the drag instruction and start the component-to-node conversion process. The drag operation is implemented by listening to the mousedown, mousemove, and mouseup events on the component element, or by using HTML5's 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. This element is usually a translucent copy of the original component and contains 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 to prepare for subsequent node creation.

[0054] During a drag and drop, the server calculates the coordinates of the mouse position relative to the event orchestration canvas in real time and checks whether the current position is within a valid drop zone. When the mouse enters the canvas, the server highlights the droppable area and may display grid alignment guides or a snap effect to help the user precisely position the item. When the user releases the mouse button on the canvas (a mouseup or drop event triggers), the server checks the validity of the release position. If the position is valid, the component is converted to an event node. The conversion process first creates a new event node object based on the component's metadata. This object contains information such as the node type, identifier, name, icon, input and output parameter definitions, and default configuration. The server then assigns a globally unique node ID to the node, typically using a UUID (universally unique identifier) or an incrementing numeric ID prefixed with a prefix. Next, the server renders the corresponding visual element on the canvas based on the node object's information.

[0055] The visual representation of a node is typically a rectangular container that contains elements such as a node icon, name, type identifier, and status indicator. The node's position is set to the coordinate location where the user releases the mouse. The server applies different visual styles to different node types, such as a green border for event-triggering nodes, a blue border for logic-processing nodes, and an orange border for event-response nodes, so that users can intuitively distinguish between different node types. In addition, the server creates connection points (ports) on the node for subsequent connections to other nodes. Input connection points are typically located on the left or top of the node, while output connection points are typically located on the right or bottom of the node. The number and location of connection points depend on the node type and the defined input and output parameters. Once a node is created, the server adds the node object to the canvas's data model, updates the canvas state, and triggers an event notification indicating the successful node creation so that other modules can respond to this change.

[0056] In response to a user's configuration request for a specific event node, a property configuration panel pops up. When a user needs to configure a specific event node placed on the event orchestration canvas, they typically initiate a configuration request by clicking the node or using the configure button on the node. Upon receiving this request, the server immediately initiates the process of creating and displaying the property configuration panel.

[0057] A configuration request can be triggered by single-clicking a node, double-clicking a node, selecting "Configure" from the right-click menu, or clicking a dedicated configuration icon on a node. For any of these triggering methods, the server first identifies the specific node selected by the user and obtains the node's unique identifier and current status information.

[0058] Before the configuration panel appears, all supported configurable properties for that type of node can be read from the node's metadata definition, including information such as the property name, data type, default value, value range, and whether it is required. The current configuration value for the node is also read to display the current configuration status in the panel. The property configuration panel is typically displayed as a modal dialog box above the canvas with a translucent overlay to focus the user's attention.

[0059] The creation of a panel uses DOM manipulation or the component rendering mechanism of the front-end framework to insert the panel element into the document and set the appropriate style and position. 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 based on the configurable properties of the node. Different types of properties correspond to different controls: text types use input boxes; numeric types use number input boxes; Boolean types use checkboxes or switches; enumeration types use drop-down selection boxes or radio button groups; date and time types use date pickers; color types use color pickers; complex object types may use nested forms or JSON editors; array types use list controls that can add / delete items, etc.

[0060] After the panel is displayed, the server will bind event listeners to each form control to verify the validity of user input in real time and provide immediate feedback, such as displaying error prompts, input suggestions, or configuration previews.

[0061] Once the property configuration panel is displayed, users can enter or modify node properties using various form controls. The server captures these input operations in real time, processes them, and performs validation. User input is captured by monitoring various form control events, such as the input and change events for input boxes, the select event for select boxes, and the click event for checkboxes. When users enter or modify values in form controls, the server immediately performs front-end validation to check that the input conforms to the expected format and constraints. Validation rules are derived from node metadata and may include: required field checks, ensuring that all required properties have values; data type checks, ensuring that the input value type matches the property definition; format validation, using regular expressions or specific algorithms to validate input formats such as email addresses, URLs, and phone numbers; range checks, ensuring that numeric inputs are between a specified minimum and maximum value; length constraints, ensuring that text inputs do not exceed a maximum length; uniqueness checks, ensuring that certain property values, such as node IDs or variable names, are unique across the entire process; and dependency validation, checking that interdependent properties, such as the conditional expression and branch path of a conditional branch, are consistent.

[0062] If the validation finds an error, the server will immediately display an error prompt, usually by displaying a red error message next to the corresponding control, or by turning the control border red. In this embodiment, the server can also provide a real-time preview function so that users can intuitively see the effects of the configuration changes. For example, for style-related properties, the appearance of the preview area can be updated in real time; for data conversion rules, the results of the sample data after conversion can be displayed; for conditional expressions, the results of the expression can be evaluated based on the current context data. When the user clicks the "OK" button, the server will perform a final validation to ensure that all necessary properties are correctly configured. If the validation passes, the server will collect the values of all form controls and build a complete node attribute object. The node attribute object is a collection of key-value pairs. The server will apply this attribute object to the corresponding event node to update the node's internal state and appearance.

[0063] When users need to establish a connection between different event nodes, they can use a drag-and-drop operation to connect the output port of one node to the input port of another node. After the server captures this connection instruction, it will start the node connection creation and verification process. The connection instruction is usually triggered using the drag-and-drop interaction mode: the user first clicks the output port of the source node, then drags the mouse, and finally releases the mouse button on 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 mouse position, providing intuitive visual feedback.

[0064] Temporary connection lines are usually in the form of polylines and can be drawn using SVG path elements. When the mouse hovers over a potential target port, the server will highlight the port to indicate that a connection can be made there.

[0065] When the user releases the mouse button on a valid target port, the server creates a formal connection object, which contains information such as the source node ID, source port ID, target node ID, target port ID, and may also contain additional properties such as the connection type, label, and style. The server then draws a formal connection line on the canvas to represent the data or control flow relationship between the two nodes. Connection lines are usually drawn using SVG path elements, and the shape of the path can be an orthogonal polyline or a custom path. For an orthogonal polyline, the path consists of multiple horizontal and vertical line segments. To ensure that the line segments only have 90-degree turns, you can use or other path finding algorithms to calculate the best path.

[0066] The style of connection lines can be customized based on data type, connection status, or user configuration, such as using different colored lines for different types of data flows and animation effects for active connections. Once a connection is created, the server adds the connection object to the canvas's data model, updates the connection status of the relevant nodes, and triggers a connection creation event to notify other modules of the connection change.

[0067] After completing the connection of event nodes, the server needs to determine the execution order of the entire event process based on these connection relationships and perform corresponding configurations.

[0068] Specifically, the server first performs a topological analysis of all nodes and connections on the canvas, constructing a directed graph data structure where nodes represent event nodes and edges represent connections between nodes. The first step in topological analysis is to identify entry points into the process—nodes without input connections. These are typically trigger-type event nodes, such as button clicks, form submissions, or timers. Starting from each entry point, the server uses a depth-first search algorithm to traverse the entire graph and determine the order in which nodes should be visited. During the traversal, the server detects loops (circular dependencies) and flags them as potential issues, as they can lead to infinite loops or deadlocks. For conditional branch nodes (such as if-else and switch-case), the server analyzes all possible branch paths and assigns a priority or execution condition to each branch. For parallel execution nodes (such as parallel tasks and concurrent requests), the server marks their subtasks as eligible for parallel execution and may configure synchronization points to wait for all parallel tasks to complete before continuing the process. Finally, the server generates a complete event flow configuration, typically stored in JSON or XML format, containing node definitions, connection relationships, execution conditions, data mapping, error handling, and other information. This configuration file will serve as input to the process engine and guide the actual execution of the process.

[0069] This implementation significantly reduces the technical threshold for process design through a drag-and-drop component-to-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 relationships of the process clearly visible. Furthermore, this not only ensures the correctness of the process but also improves its execution efficiency. The entire server visualizes complex event processing logic, making it easier for team members to understand and collaborate on business process development, significantly improving development efficiency and process quality.

[0070] In one implementation of this embodiment, the event node includes a triggering event node, a logic processing node, and a response event node. Attribute configuration is performed on each event node to determine the node attributes of each event node, including the following steps: S410: For a trigger event node, configure its node attributes as a trigger condition, a trigger source, and / or a trigger parameter; S420: For a logic processing node, configure its node attributes as processing logic, conditional branching, and / or data conversion rules; S430: For the response event node, configure its node attributes as a response action, a target object, and / or a response parameter.

[0071] Figure 5 A schematic diagram of an event node attribute configuration process provided by an embodiment of the present application is shown. Figure 5 As shown, for the Trigger Event node, configure its properties as the trigger condition, trigger source, and / or trigger parameters. The Trigger Event node is the starting point of the event process, responsible for listening for and capturing specific events and initiating process execution when these events occur. Configuring the properties of the Trigger Event node is a key step in ensuring that the process responds correctly to the expected events.

[0072] First, the trigger condition property defines the specific conditions or scenarios under which the event is triggered. The trigger condition can be an event type selection, such as "click" or "submit." Second, the trigger source property specifies the object or system from which the event originates. For DOM events, the trigger source can be a page element selector or element reference. 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 the operating system, browser, server, or specific API endpoint. For database events, the trigger source can be database connection information, table name, and the monitored operation type (such as insert, update, and delete). Finally, the trigger parameter property defines the data extracted from the trigger event, which will be passed as input to subsequent nodes in the process. Parameter configuration typically includes the parameter name, data type, default value, and extraction path. The parameter name is the identifier used to reference the parameter in the process, and the data type specifies the parameter's value type, such as string, number, or Boolean. The default value defines a fallback value to use if the event does not provide the corresponding data. The extraction path specifies how to retrieve the parameter value from the event object.

[0073] For logic processing nodes, configure their properties to include processing logic, conditional branching, and / or data transformation rules. Logic processing nodes are responsible for executing various business logic, data processing, and decision-making operations. Configuring the properties of logic processing nodes is a key step in ensuring that the process correctly executes business rules and data transformations.

[0074] First, the processing logic property defines the specific operation or algorithm performed by the node. This processing logic can be predefined functions or operations, such as mathematical calculations (sum, average, maximum / minimum, etc.), string operations (concatenation, splitting, replacement, etc.), array operations (mapping, filtering, sorting, etc.), or object operations (merging, extraction, transformation, etc.). It can also be custom JavaScript code snippets, allowing users to implement more complex logic. Second, the conditional branch property defines process branching logic based on specific conditions. A conditional branch typically consists of one or more conditional expressions and a branch path corresponding to each condition. Conditional expressions can be constructed using a combination of comparison operators (such as equal to, greater than, less than, and contains), logical operators (AND, OR, NOT), and various functions. For example, "if(order.total > 1000 && user.vipLevel >= 2)" indicates that the process will execute only when the order total is greater than 1000 and the user's VIP level is at least 2. Each condition corresponds to an output port or branch path, which specifies the next step in the process when the condition is met.

[0075] Data transformation rule properties define how input data is transformed into the desired output format. Data transformation can include operations such as field mapping, type conversion, formatting, aggregation, and restructuring. Field mapping specifies which fields in the input data are mapped to which fields in the output data. This can be a one-to-one, many-to-one, or one-to-many mapping. Type conversion defines how to convert one data type to another, such as converting a string to a number or a date format. Formatting rules specify how to format data, such as the number of decimal places for numbers, the display format of dates, and the case of strings. Aggregation rules define how to combine multiple data items into a single item, such as calculating sums, averages, and maximum / minimum values. Restructuring rules specify how to alter the structure of data, such as converting flat data into nested structures or arrays into objects. The configuration interface for data transformation rules typically provides a visual mapping designer, allowing users to define transformation rules by connecting lines, dragging and dropping, or filling out forms. A data preview function is also provided, showing a comparison of the data before and after the transformation. Through these configurations, logical processing nodes can execute complex business logic, conditional judgments, and data transformations, providing powerful processing capabilities and flexibility to event processes.

[0076] For response event nodes, configure their properties to include the response action, target object, and / or response parameters. A response event node is the endpoint or output point of an event process and is responsible for performing specific response actions, such as updating the UI, sending notifications, calling APIs, or triggering other system behaviors. Configuring the properties of a response event node is a critical step in ensuring the process produces the expected results and responds correctly.

[0077] The action attribute defines the specific type of operation performed by the node. Actions can be UI interactions, such as showing / hiding elements, updating content, switching styles, popping up dialog boxes, navigating to new pages, etc. They can also be data manipulation actions, such as creating records, updating data, deleting information, and submitting forms.

[0078] The target object property specifies the specific object or target to which the action is applied. For UI actions, the target object is typically a DOM element, specified by a CSS selector or element reference. For data actions, the target object can be a data model, database table, API endpoint, or storage location.

[0079] The response parameter properties define the specific parameters and data required to execute the response action. Parameter configuration typically includes the parameter name, data type, and parameter value or value source. The parameter name is the parameter identifier defined in the action API, and the required parameter names can be automatically listed based on the selected response action type. The data type specifies the value type of the parameter, such as string, number, Boolean value, object, array, etc. The parameter value can be a static value (a constant entered directly), a dynamic value (obtained from process data), or an expression (derived through calculation). For dynamic values, you need to specify the path or expression of the data source, such as "${order.customerName}" to obtain the value from the customerName attribute of the order object.

[0080] The configuration of the trigger event node enables the precise capture and parameter extraction of multiple event sources, providing a clear starting point and initial data for process execution. The configuration of the logic processing node provides rich data processing capabilities and decision-making logic. Through the combination of processing logic, conditional branches, and data conversion rules, non-technical personnel can also implement complex business rules and data operations without writing code. The configuration of the response event node ensures that the results of the process execution can be converted into specific system behaviors or user-visible effects. Through the precise definition of response actions, target objects, and response parameters, seamless integration with external systems and user interfaces is achieved. This not only lowers the development threshold and enables business personnel to directly participate in process design, but also improves the maintainability and reusability of the process, providing an efficient low-code development solution for enterprise-level applications. Through a visual configuration interface and intuitive property settings, complex programming concepts are successfully transformed into configuration items that are easy to understand and operate, achieving a deep integration of technology and business.

[0081] In one implementation of this embodiment, determining the connection relationship between different event nodes based on the node attribute of each event node includes the following steps: S510, identifying the starting node and target node corresponding to the connection instruction; S520, obtaining the node types and node attributes of the start node and the target node; S530: Determine whether the output type of the start node is compatible with the input type of the target node according to a preset connection rule; S540, determining whether the start node and the target node satisfy the dependency relationship or constraint condition defined in the node attributes; S550: If the types are compatible and the dependency or constraint conditions are satisfied, determine that there is a connection relationship between the start node and the target node.

[0082] Connection instructions typically originate from user interactions within a visual editor, such as dragging a line, clicking a connect button, or using shortcut keys. When a user initiates a connection, the server first determines the starting node for the connection. This can be the location of the user's mouse click, the currently selected node, or a specific node output port. For drag-and-drop connections, the server tracks the starting location of the mouse or touch event and determines the node and output port corresponding to that location through spatial coordinate calculations. For example, when a user begins dragging from an output port of node A, the server records the identifier of that port as the starting point for the connection. For click-and-click connections, the server records the node or port the user first clicks as the starting point and then waits for the user to click a second node or port to determine the target point. When the user completes the connection (e.g., releasing the mouse button or clicking a target node), the server determines the target point for the connection, typically the node below the mouse release location or a specific node input port. The server determines the target node and input port through spatial collision detection or closest distance calculation. In another embodiment, the server can automatically snap to the nearest valid input port to improve the accuracy of user operations. In addition to direct user interaction, connection instructions may also originate from programmatic operations, such as through API calls, importing existing process definitions, or executing automatic layout algorithms. In these cases, connection instructions are typically provided as data structures that explicitly specify the start and target node IDs. The server ultimately converts the start and target nodes corresponding to the connection instructions into a standardized internal representation, typically containing the start and target node IDs.

[0083] The server retrieves complete node metadata for the start and target nodes, including their node types and properties. First, the server retrieves the corresponding node object from the process definition store based on the node ID identified in the previous step. Node objects are typically stored in an in-memory graph data structure or a state management server. For each node, the server obtains its basic type information, specifically whether it is a triggering event node, a logic processing node, or a response event node. The node type determines the node's role and behavioral characteristics within the process and is crucial for determining connection validity. For example, a triggering event node can typically only serve as the start node, not the target node; a response event node can typically only serve as the target node, not the start node. In addition to the basic type, the server also needs to obtain the node's detailed subtype or function type. For example, a triggering event node may be subdivided into different subtypes, such as button click trigger, form submission trigger, and timer trigger; while a logic processing node may be subdivided into different function types, such as conditional evaluation, data conversion, and API call. This subtype information helps further determine the compatibility of connections between nodes.

[0084] Next, the server needs to obtain the complete configuration properties of the node. For trigger event nodes, it needs to obtain properties such as the trigger condition, trigger source, and trigger parameters; for logic processing nodes, it needs to obtain properties such as the processing logic, conditional branches, and data conversion rules; for response event nodes, it needs to obtain properties such as the response action, target object, and response parameters. These properties not only define the node's own behavior but also imply the constraints on the node's connections with other nodes.

[0085] It's particularly important that the server obtain the node's input and output definitions. Input definitions describe the data type, format, and structure that the node expects to receive, potentially including required and optional fields, field types, and value ranges. Output definitions describe the data type, format, and structure that the node produces, potentially including a list of fields, type information, and data examples. Input and output definitions are typically expressed in JSON Schema, TypeScript type definitions, or a custom type description language.

[0086] Based on the preset connection rules, the server determines whether the output type of the starting node is compatible with the input type of the target node. Specifically, type compatibility checking ensures that data is correctly understood and processed when flowing between nodes, avoiding runtime errors. First, the server loads the preset connection rules. These rules define the permitted connection modes and data type compatibility criteria between nodes of different types. These rules consist of a node type compatibility matrix and data type compatibility rules. The node type compatibility matrix defines whether connections between nodes of different types are permitted. For example, the rules stipulate that trigger event nodes can connect to logic processing nodes or response event nodes, and logic processing nodes can connect to other logic processing nodes or response event nodes. However, response event nodes generally cannot serve as the starting point for connections. The server first checks whether the base types of the starting and target nodes meet the rules in this matrix. If the node types themselves are incompatible (for example, when attempting to connect from a response event node to a trigger event node), the server will directly determine that the connection is incompatible, without further data type checking. Next, the server checks data type compatibility. Specifically, it compares the output type definition of the starting node with the input type definition of the target node to determine whether data can flow correctly. Type conversion allows implicit or explicit type conversion under specific rules, such as number to string, string to date, etc. Subtype relationship judgment is based on the inheritance or extension relationship of the type. If the output type is a subtype of the input type, it is judged to be compatible. Structural compatibility checks the fields and nested structures of more complex data structures (such as objects or arrays) to determine whether the output structure contains all the necessary fields and correct field types required by the input. 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 dependency check; if incompatible, the server will refuse to establish a connection and may provide the user with a detailed explanation of the reasons for the incompatibility to help users understand and resolve type mismatch issues.

[0087] Determining whether the dependencies or constraints defined in the node properties between the source and target nodes are met is a deeper level of connection validation, ensuring that the connection between the nodes is not only compatible in type but also meets business logic and functional requirements. Dependencies and constraints reflect the functional characteristics and usage restrictions of a specific node.

[0088] During implementation, the server first checks the dependencies explicitly defined in the node properties. Dependencies describe the prerequisites or context required for a node to function properly. These may include required upstream node types, specific data preprocessing, or state requirements. For example, a data aggregation node may rely on upstream nodes providing grouping fields; a conditional branch node may rely on upstream nodes providing specific data fields for its judgment condition. The server analyzes the target node's dependencies and checks whether the starting node satisfies these requirements. Next, the server checks the constraints defined in the node properties. Constraints restrict the connection method, number, or combination of nodes to ensure the rationality and executable nature of the process structure. Common constraints include: input / output port limits, such as some nodes requiring a maximum of one input connection or two output connections; connection level limits, such as prohibiting loops or limiting the maximum nesting depth; and node combination limits, such as requiring certain nodes to be arranged in a specific order or requiring that certain nodes cannot be directly connected. Based on these constraints, the server considers the overall structure of the current process and existing connections to determine whether the new connection will violate any constraints.

[0089] In actual implementations, dependency and constraint checking may employ a rules engine, constraint solver, or custom validation 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 for loops requires traversing the entire graph structure; checking the integrity of the data flow may require analyzing all possible paths from the triggering node to the response node. The result of dependency and constraint checking is also a Boolean value, indicating whether all necessary dependencies and constraints are satisfied between the starting and target nodes.

[0090] If the types are compatible and the dependencies or constraints are met, a connection relationship is determined between the starting node and the target node. That is, the server will only enter the connection creation phase when the output type of the starting node is compatible with the input type of the target node and all necessary dependencies and constraints are met. If any verification fails, the server will refuse to establish the connection and may provide the user with detailed error information and correction suggestions. When all verifications pass, the server begins to create the actual connection object or record. A connection is usually represented as a data structure containing the starting node ID, starting port ID, target node ID, and target port ID. In the graphical process editor, the connection also corresponds to a visual connection element with a specific style, path, and interaction behavior. 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.

[0091] By accurately identifying the starting and target nodes corresponding to connection instructions, the server can precisely capture the user's connection intent. Secondly, by obtaining node types and attribute information, the server establishes a data foundation for connection verification. Then, based on pre-set connection rules, the server determines type compatibility between nodes to ensure correct data flow. Next, the server checks inter-node dependencies and constraints to ensure that the connection complies with business logic and functional requirements. Finally, if all verifications pass, the server establishes and records the inter-node connection relationships, completing the process structure. This multi-level connection verification mechanism not only prevents incorrect connections during design but also improves process execution feasibility and stability. Through visual connection operations and instant verification feedback, the server significantly reduces the difficulty and barrier to entry for process design, enabling even non-technical personnel to create complex and correct business processes. Furthermore, strict type checking and constraint validation provide reliable assurance for subsequent process execution, reducing runtime errors and exceptions, effectively addressing the issue of correctness and reliability in process design within low-code platforms.

[0092] In one implementation of this embodiment, generating event process configuration data based on event nodes and event process connections includes the following steps: S610: traverse all event nodes on the event arrangement canvas and obtain a node identifier and node attributes of each event node; S620: traverse all event flow connections on the event orchestration canvas, and determine the start node identifier and the target node identifier of each connection based on the graphical representation of the event flow connections; S630, determining a connection condition for the event flow connection based on the node attribute of the connection start node; S640: Generate JSON format configuration data including event process structure and execution logic according to the node attributes of the event node and the execution order of the event process connection.

[0093] Among them, according to the node attributes of the event node and the execution order of the event process connection, JSON format configuration data containing the event process structure and execution logic is generated, including: S1. Create a top-level JSON object to represent the entire event flow. S2. Create a node list JSON array in the top-level JSON object to store information about all event nodes; 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; S4. Create a connection list JSON array in the top-level JSON object to store information about all event process connections; S5. Encapsulate the start 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.

[0094] In this embodiment, the traversal process can employ a depth-first search (DFS) or breadth-first search (BFS) algorithm to retrieve all node elements from the canvas's data model or DOM structure. In actual implementation, the node list can be directly retrieved through the canvas's internal data structures (e.g., node collections or graph data structures), or the DOM elements of all nodes can be retrieved using a DOM selector. For each identified node, its unique node identifier must first be obtained. This identifier is typically a UUID or auto-incrementing ID, which uniquely identifies the node throughout the entire process. The node identifier is stored in the node's data-id attribute, the node object's id field, or an index in the canvas's data model. Next, the node's complete set of properties is retrieved, defining its behavior and characteristics. Node properties typically include node type, name, description, and location. These properties are stored in the node's data attribute, the node object's attribute fields, or the associated configuration object. After the traversal is complete, all node identifiers and properties are collected into a unified data structure (e.g., an array or map), providing foundational data for subsequent connection analysis and configuration generation.

[0095] 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. After completing the node information collection, it is necessary to identify the connection relationship between the nodes. These connections define the execution path and data flow of the event flow. The method of traversing connections is similar to traversing nodes. All connections can be directly obtained through the internal data structure of the canvas (such as edge sets, connection lists), or all connected DOM elements can be obtained through DOM selectors. For visual editors, connections are usually represented by graphic elements such as lines, arrows, or curves, connecting the output ports and input ports of two nodes. During the traversal process, it is first necessary to identify the graphical representation of each connection, which can be an SVG path, a line drawn by Canvas, or a special DOM element.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] 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).

[0100] Similarly, within the top-level JSON object, create a connection list JSON array to store detailed information about all event flow connections. For each event flow connection identified in the previous step, create a connection JSON object containing basic properties such as the connection's source node identifier, target node identifier, connection type, and the connection conditions determined in the previous step. The resulting JSON configuration data is a structured text representation that fully describes the structure and execution logic of the event flow. It can be parsed and executed, serialized for storage, or transmitted via an API.

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

[0102] Create a node list JSON array within the top-level JSON object to store information about all event nodes, providing a unified storage structure for all nodes. The node list contains detailed information and configuration for all nodes in the process. First, add a property called "nodes" to the top-level JSON object, with a value of an empty array ([]). This array will be used to store the JSON object representations of all nodes. The node list array is typically created using simple array literal syntax or the Array constructor.

[0103] Encapsulating each event node's node identifier, node type, and node properties into a separate node JSON object and adding it to the node list JSON array converts event node information into a standardized JSON structure and integrates it into the process configuration. For each event node, a new JSON object is created that fully represents all of the node's characteristics and configuration. First, create an empty JavaScript object as the JSON representation of the node. This can be done using object literal syntax ({}) or the Object constructor. Next, add the node object to the id (unique identifier of the node), type (node type), and node properties such as the node's name, position, and dimensions. Once the node object is created, use the array's push method to add it to the node list array. Repeat this process, creating a JSON object for each identified node and adding it to the node list until all nodes have been processed. In this way, all node information 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.

[0104] Create a connection list JSON array within the top-level JSON object to store information about all event flow connections, providing a unified storage structure for all connections within the process. The connection list describes the relationships between nodes and the flow of data. First, add a property to the top-level JSON object with an empty array as its value to store the JSON object representation of all connections. Similar to the node list, the connection list is typically created using array literal syntax or the Array constructor.

[0105] Encapsulate the start node identifier, target node identifier, and connection conditions for each event flow connection into a separate connection JSON object and add it to the connection list JSON array. For each event flow connection, a new JSON object needs to be created that fully represents all the characteristics and conditions of the connection. First, create an empty JavaScript object as the JSON representation of the connection. This can be done using object literal syntax or the Object constructor. Next, add basic properties to the connection object that define the core relationship of the connection. The most basic properties include: a unique identifier for the connection, an identifier for the start node, and an identifier for the target node. These basic properties clearly define the two ends of the connection and establish the relationship between the nodes.

[0106] This implementation traverses event nodes and connection relationships, converting visual orchestration results into JSON configuration data containing the complete topology and execution logic, establishing a unified, machine-readable process description specification. This JSON-formatted configuration data preserves both business semantics (such as node attributes) and technical implementation details (such as connection conditions), effectively addressing the distortion problem associated with translating natural language requirements into code. The generated JSON configuration data, as an implementation-independent intermediate representation, can be used directly to generate native JavaScript code or stored persistently as a process template. This decouples business logic definition from runtime execution, enabling automated code refactoring by simply updating the configuration data without recoding. By dynamically associating connection conditions with node attributes, the configuration data can express nonlinear execution paths. Compared to traditional hard-coded approaches, this declarative process description allows complex business rules to be adjusted visually, significantly reducing the development and testing costs of logic changes. Ultimately, this achieves high-fidelity conversion from visual orchestration to executable code, enabling even non-technical personnel to intuitively define complex business logic while ensuring the reliability and maintainability of the generated code, improving overall development efficiency.

[0107] In one implementation of this embodiment, converting the event flow configuration data into native JavaScript code includes the following steps: S710, parsing event process configuration data, extracting node lists and connection lists; S720. According to each node JSON object in the node list, convert its node type and node attributes into corresponding JavaScript function body logic; S730. Determine the starting node, target node, and connection condition for each connection JSON object in the connection list, and generate an event monitoring / callback function for controlling the function call sequence and data transfer based on the starting node, target node, and connection condition; S740: Assemble and obtain native JavaScript code based on the generated JavaScript function body logic and event monitoring / callback function.

[0108] Parse the event flow configuration data to extract the node list and connection list from the configuration data. Event flow configuration data is typically stored in JSON format, which contains all the necessary information to describe the entire event flow. First, use the JSON.parse() method to parse the string-based configuration data into a JavaScript object. If the configuration data is already in object form, it can be used directly. Then, extract the node list (nodes) and connection list (connections) from the parsed object. The node list contains information about all nodes in the flow. Each node is a JSON object containing a node ID, node type (such as start node, condition node, action node, end node, etc.), and node-specific properties (such as conditional expression, execution action, etc.). The connection list contains the connection relationships between all nodes in the flow. Each connection object contains the start node ID, target node ID, and possible connection conditions.

[0109] According to each node JSON object in the node list, its node type and node attributes are converted into the corresponding JavaScript function body logic. Specifically, it is necessary to first traverse each node object in the node list and determine the JavaScript function type to be converted for the node based on the node's type attribute. The conversion logic varies for different types of nodes: the start node is usually converted into the entry function of the process, which contains initialization logic and a call to the next node; the conditional node is converted into a function containing a conditional judgment statement, which determines which branch's next node to call based on the result of the conditional expression; the action node is converted into a function that performs specific operations, such as data processing, API calls, etc.; the end node is converted into the end function of the process, which may contain logic for cleaning up resources or returning results.

[0110] During the conversion process, node attributes are converted into corresponding JavaScript code. For example, the conditional expression of a conditional node is converted into a JavaScript if-else statement. Furthermore, a unique function name is generated for each node. This is typically done using the node ID or a combination of the node type and ID. Ultimately, each node is converted into a complete JavaScript function definition, including the function name, parameter list, and function body.

[0111] According to each connection JSON object in the connection list, the starting node, target node and connection conditions are determined, and based on this information, an event listener / callback function is generated to control the function call order and data transfer. First, each connection object in the connection list is traversed to extract the starting node ID, target node ID and connection conditions. Then, according to the type of the starting node and the connection conditions, the corresponding event listener or callback function code is generated. For connections between ordinary nodes, direct function call code can be generated, that is, the target node function is called at the end of the starting node function; for connections between conditional nodes, conditional branch code needs to be generated according to the connection conditions, and the corresponding target node function is called when the conditions are 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.

[0112] In this embodiment, the callback function is used to: manage the asynchronous execution process between JavaScript functions; determine whether to execute subsequent JavaScript functions based on the connection conditions; 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 JavaScript functions according to the error handling logic defined in the event process configuration data; trigger system events or user interface updates associated with specific execution states.

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

[0114] Among them, based on JavaScript functions and event monitoring, native JavaScript code is generated, including: S10. Create a JavaScript closure or module to encapsulate the logic of the entire event process to avoid global namespace pollution; S20. Define all JavaScript functions converted from event nodes within the closure or module; S30, setting an event listener to bind the user interface interaction or other trigger source to the corresponding starting JavaScript function; S40, implement callback function logic, and arrange the calling relationship, condition judgment and data flow between JavaScript functions according to the connection list information; S50. Integrate the JavaScript code including all function definitions, event monitoring settings, and callback logic into one or more .js files.

[0115] In JavaScript development, global variables and functions can easily cause naming conflicts, especially in large-scale applications or when working with multiple teams. To avoid this problem, closures or modularization are used to encapsulate event flow logic. A closure is a combination of a function and the variables it can access from the outer scope. It confines variables and functions to a local scope, preventing contamination of the global environment. Closures or modular encapsulation make event flow logic more isolated, reducing the risk of accidental modifications and facilitating code organization and debugging.

[0116] During the visual orchestration phase, event nodes may represent different business logic, such as data validation, API calls, or UI updates. During the code generation phase, each node is mapped to a separate JavaScript function. These functions are defined based on the event node's configuration attributes, such as parameters, return values, and dependencies. Function inputs may come from user interactions or the output of the previous node, while outputs may be passed to the next node or directly update the UI. Modular function definitions make business logic clear and traceable, facilitating subsequent maintenance and expansion.

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

[0118] Callback functions define the execution order and data transfer rules between different JavaScript functions. They orchestrate the calling relationships, conditional checks, and data flow between JavaScript functions based on the connection list. Callback logic can be implemented through chained calls or by using conditional checks to handle branching processes. Data flow can be achieved through function parameters and return values, for example, using the output of one function as the input of the next. Appropriate arrangement of callback logic ensures that the event flow executes as expected in the visual arrangement, avoiding logical confusion or data loss.

[0119] The final JavaScript code should be organized according to modular principles. For example, related functionality should be split across multiple .js files to improve maintainability. For example, event listeners can be centralized in the event-handlers.js file, business logic functions in logic.js, and data manipulation functions in data.js. Files can be loaded on demand using tags.

[0120] The native JavaScript code generated by this implementation does not need to rely on additional runtime libraries and can be executed directly in a browser or Node.js environment, with high performance and compatibility. In addition, because the code is generated according to unified 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 where business processes need to be adjusted frequently, allowing non-technical personnel to define processes through visual tools and then automatically generate corresponding code implementations, thereby achieving effective separation of business and technology, and realizing automatic conversion from visual process design to executable code, greatly improving development efficiency and code consistency.

[0121] In one implementation of this embodiment, calling a rendering engine to render the page style and page data of the visual development interface according to native JavaScript code includes the following steps: S810, initializing the operating environment of the rendering engine; S820, injecting native JavaScript code into the DOM structure of the visual development interface; S830, parsing page component layout and style configuration information of the visual development interface; S840. Apply CSS rules based on the page component layout and style configuration information to render the static page style of the visual development interface. S850: Execute the initialization part in the native JavaScript code and establish a binding relationship between the page component 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 process; S860. Fill the content of the page component according to the binding relationship and the data source, and complete the rendering of the page data.

[0122] Initializing the rendering engine's runtime environment involves creating and configuring the various resources and environment parameters required by the rendering engine. First, a dedicated rendering context must be created within the browser or application. This can be a Canvas element or a WebGL context, for subsequent graphics rendering operations. When creating the rendering context, the appropriate viewport size, resolution, and scale must be set to ensure consistent rendering results across devices. Next, the rendering engine's core components, including the scene graph manager, layout engine, style processor, and event dispatch system, are initialized. Furthermore, necessary resource files, such as fonts, icon libraries, and base stylesheets, must be loaded for use in the subsequent rendering process. After resource loading is complete, the rendering engine's performance parameters, such as frame rate limits, rendering priority policies, and memory management strategies, are configured to optimize rendering performance and resource utilization. Finally, global event listeners are registered to capture user interaction events and system state changes, providing support for subsequent event processing.

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

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

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

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

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

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

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

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

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

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

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

[0134] 在本实施例的其中一种实施方式中，响应于用户在可视化开发界面的交互操作，触发对应的原生JavaScript代码，以执行对应的事件流程，包括如下步骤：S910、响应于用户在可视化开发界面的交互操作，根据交互操作，确定事件源和事件类型，并根据事件源和事件类型匹配原生JavaScript代码中绑定的触发事件节点的JavaScript函数；S920、执行与触发事件节点对应的JavaScript函数；S930、依次调用与触发事件节点相连的逻辑处理节点的JavaScript函数，生成执行结果；S940、根据执行结果以及事件流程连接的连接条件，确定一个或多个响应事件节点的执行路径，并按执行路径执行相应的响应事件节点的JavaScript函数。

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

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

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

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

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

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

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

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

[0143] 本申请实施例还提供一种服务器，包括：存储器，被配置成存储指令；以及处理器，被配置成从存储器调用指令以及在执行指令时能够实现上述的基于原生JS的低代码开发平台事件编排方法。

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

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

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

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

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

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

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

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

[0152] 以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。< / 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; Convert the event flow configuration data into native JavaScript code, and 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 the user's interactive operation in the visual development interface, the corresponding native JavaScript code is triggered to execute the corresponding event process.

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 satisfied, 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 Converts event flow configuration data into native JavaScript code, including: 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, native JavaScript code is assembled.

8. 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.

9. The method according to claim 4, characterized in that In response to user interactions on 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.

10. 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 9 when executing the instructions.

Images