Event-driven visualization component linkage method and system

Abstract

Event-driven visual component linkage method and system. It relates to the technical field of low-code development and software architecture, and specifically relates to an event-driven visual component linkage method and system. The present application proposes an event-driven and responsive data linkage communication method for a visual building platform, which is decoupled and programmable. The method builds a decoupled and programmable communication and data flow management system by introducing configurable event-action binding rules, a central event distributor and a global responsive data storage. The interaction between components is abstracted as a standardized process of "event publishing → rule matching → action execution → data updating → view response", realizing the visual configuration and automatic execution of business logic. The present application solves the problems of tight coupling of component communication, complex state management and dynamic programmable interaction logic in visual building, significantly improving the maintainability, scalability and user experience of the platform.

Description

Technical Field

[0001] This invention relates to the field of low-code development and software architecture technology, specifically to an event-driven visual component linkage method and system. Background Technology

[0002] In the ecological and environmental verification and supervision platform (a low-code and visual application building platform), event-driven and responsive data linkage communication technology is the core of realizing multi-source environmental collaborative supervision tasks. Such systems typically support regulatory personnel in combining business units such as pollution source monitoring, air quality forecasting, patch monitoring, patch status flow, and satellite remote sensing data reception through component-based encapsulation and visual drag-and-drop methods, and configuring the interaction logic between them to build a complete process for environmental situation assessment, verification task planning, and enforcement instruction generation.

[0003] In engineering practice, mainstream solutions often rely on parent-child component communication built into the front-end framework, global state management libraries (such as Vuex and Redux), or general event buses. Developers explicitly define event listeners and callback functions at the code level to achieve the transmission of environmental monitoring data and state synchronization between components. While ensuring the feasibility of the function, they strive to maintain the consistency and maintainability of the logic.

[0004] When using event-driven and responsive data linkage communication technologies to address cross-component collaboration and data linkage issues in environmental regulatory scenarios (e.g., after obtaining the emissions of a company exceeding the standard through a dropdown component, the statistical component in the large-screen statistics interface synchronizes the data update), two common problems exist: On the one hand, most platforms still hard-code interaction logic within components or scattered scripts, tightly coupling event responses with specific environmental regulatory actions. This results in the inability to intuitively configure, orchestrate, and reuse interaction logic during the visual editing phase when adjusting the verification interaction process (e.g., only fixed table components can be rendered and updated when performing list queries, while clicking on the table to query details or perform other operations will be fixed during the development phase). Any modification to the regulatory process requires intervention in the underlying code, making it difficult for environmental engineers to directly participate in system construction, significantly reducing the platform's "configurability" and "flexibility." Consequently, the platform lacks flexibility and maintainability when dealing with complex environmental application scenarios (such as resource scheduling in multi-pollution source collaborative treatment, cross-administrative region joint law enforcement, or differentiated event response configuration based on enterprise type and emission level).

[0005] On the other hand, when implementing cross-component environmental data flow and state synchronization (e.g., automatically obtaining the current page number and query conditions after deleting a monitoring record in a data table, and re-requesting the interface to refresh the table data), developers have to manually write lengthy asynchronous processing chains and meticulously manage the dependencies of each component on shared pagination states and query conditions to achieve complex data flow (such as pagination parameter concatenation, query condition persistence, and interface call exception handling). This approach is not only prone to errors and difficult to debug, but also makes it difficult to form a global and visual insight into the data flow of the entire monitoring system. A prominent engineering contradiction arises between the "visual configuration requirements" of the interaction logic and the "complexity of the underlying code implementation," resulting in difficulty in globally controlling the environmental monitoring data flow. When multiple components share common data such as pagination, sorting, and filtering conditions, the lack of global data flow management can easily lead to problems such as inconsistent interface states and abnormal data refreshes. Summary of the Invention

[0006] To address the shortcomings of existing event-driven and responsive data linkage communication technologies in current ecological and environmental verification and supervision platforms, such as insufficient flexibility in visualization configuration due to hard-coded coupling of interaction logic, and inconsistent states and poor maintainability due to a lack of global management of complex cross-component data flow, this invention proposes an event-driven visualization component linkage method and system. It presents a decoupled and programmable event-driven and responsive data linkage communication mechanism for visualization platform construction.

[0007] The method includes the following steps: S101. In the visual building platform, set the configurable events and data binding rules supported by each source component, and generate the source component event structure E101 and the component-level event control parameter set K101. The source component represents the rules for component rendering and configuration; The components include: basic components, multimedia components, form components, data display components, container components, and image components; S102. Based on E101 and K101, complete the rule configuration, obtain the configuration record set R101, store it in the component instance set C104, and create a global variable pool G101 based on E101; S103. Generate an action mapping table based on R101 and G101; When the central event dispatcher detects that any component has triggered an event, the central event dispatcher queries the action mapping table based on the component that triggered the event and generates an event dispatch set E103. S104. Execute the corresponding action according to E103, obtain the action execution result set A104 and store it in the component instance set C104 to obtain the updated C104, and update G101 according to A104; S105. Based on the updated G101, responsively update the visualization components in the visualization platform, complete the interface update, and generate view update record V105.

[0008] Furthermore, the source component event structure E101 includes: variable rules, trigger event types, targetable objects, and executable target action types; Variable rules specify the number of variables that each component can bind to, the meaning of the variables, and restrictions on the variable value types; Trigger event type indicates the type of interactive events that can trigger the component; The target object can be targeted, representing the target component that the triggered component can pass on to; The executable target action type indicates the specific response action type that can be executed on the target object after the component is triggered; The component-level event control parameter set K101 includes: event triggering condition templates, action parameter specifications, and variable referencing rules.

[0009] Furthermore, the rule configuration process is as follows: create a binding rule, select the target component and action based on E101, and then configure the action parameters according to K101; Binding rules: Each component can create several binding rules.

[0010] Furthermore, the configuration record set R101 includes: component type identifier, trigger event types supported by the component, target action type, and action configuration items containing templated parameters; The templated parameters are stored in the action configuration item as variable placeholders.

[0011] Furthermore, the process of creating the global variable pool G101 is as follows: based on the variable rules in E101, a variable binding region is generated. Within the variable binding region, custom variables and their values ​​are set for any component to obtain a dependency graph. Furthermore, the action mapping table includes: several variables, several components bound to each variable, and configuration records corresponding to each component; Furthermore, the specific steps for performing the corresponding action based on E103 are as follows: according to E103, the action is scheduled, the execution context is prepared, the variable placeholder is dynamically resolved, the component data is updated, and the result is fed back. The process of updating G101 according to A104 is as follows: based on the action execution result, push the triggered component corresponding to the action execution result in reverse, and then update the value of the variable corresponding to the triggered component in G101 according to the action execution result.

[0012] Furthermore, the responsive update of the visualization components in the visualization platform based on the updated G101 specifically involves synchronizing the visualized values ​​of the corresponding variables in the visualization components with the values ​​of the corresponding variables in the updated G101.

[0013] An event-driven visual component linkage system is provided to implement the above method. The system includes: a component metadata manager, a visual binding configurator, an event router, an action execution engine, and a responsive data linkage unit. The component metadata manager is used to set the configurable events and data binding rules supported by each source component in the visual building platform, and to generate the source component event structure E101 and the component-level event control parameter set K101. The visual binding configurator completes rule configuration based on E101 and K101, obtains a configuration record set R101, stores it in the component instance set C104, and creates a global variable pool G101 based on E101; The event router generates an action mapping table based on R101 and G101; When the central event dispatcher detects a trigger event in any component, it queries the action mapping table based on the component that triggered the event and generates the event dispatch set E103. The action execution engine executes the corresponding action according to E103, obtains the action execution result set A104 and stores it in the component instance set C104, obtains the updated C104, and updates G101 according to A104; The responsive data linkage unit updates the visualization components in the visualization platform in a responsive manner based on the updated G101, completes the interface update, and generates view update record V105.

[0014] The beneficial effects of the method described in this invention are as follows: (1) In response to the problem that “interaction logic is hard-coded and solidified in the components in the ecological environment verification and supervision platform, which requires intervention in the underlying code to adjust the verification process”, this invention constructs a standardized, declarative event-driven and responsive data linkage communication mechanism for the visualization platform. This mechanism decouples the interaction logic between business modules such as pollution source monitoring, air quality forecasting, patch monitoring, patch status flow, and satellite remote sensing data reception, which are flexibly assembled from basic components, from the hard-coded logic and unifies them into a configurable and scalable event-action rule system. Regulatory personnel can intuitively configure complex business processes during the visual editing stage, such as "when a patch is marked as suspected illegal in the patch monitoring module (composed of basic components such as tables and buttons), the satellite remote sensing data receiving module (composed of map display components) is automatically triggered to acquire high-resolution images, the patch status flow module (composed of status flow components) is linked to update the verification status, and the enforcement instruction generation module (composed of form components) is driven to pre-fill enterprise information." This process can be adapted to differentiated regulatory scenarios such as multi-pollution source collaborative disposal and cross-administrative region joint enforcement without modifying the code, significantly improving the configurability and flexibility of environmental regulatory processes and enabling environmental engineers to directly participate in system construction.

[0015] (2) To address the problem that "cross-component environment data flow requires manually writing lengthy asynchronous processing chains, making it difficult to manage public data such as pagination, sorting, and filtering conditions globally," this invention, without changing the existing component rendering system and layout architecture, abstracts the event response logic scattered in each component into a unified event-action binding rule, and centrally manages shared states such as pollution source emission data, air quality index, patch verification status, and satellite remote sensing image metadata through global reactive data storage. When regulatory personnel delete a monitoring record in the data table, the system automatically obtains the current page number and query conditions and re-requests the interface to refresh the table. At the same time, it updates the related components such as emission statistics and distribution of enterprises exceeding standards on the large screen statistics interface, eliminating the need to manually manage complex logic such as pagination parameter splicing, query condition persistence, and interface call exception handling. By leveraging a multi-level indexed event-action mapping table and dependency tracking mechanism, this invention can complete rule matching and view updates in milliseconds, ensuring consistent interface state and synchronized data refresh when multiple components share pagination, sorting, and filtering conditions. This solves problems such as difficulty in globally controlling environmental monitoring data flow, inconsistent interface state, and abnormal data refresh, greatly reducing the maintenance cost of multi-component joint debugging and cross-terminal behavior consistency.

[0016] (3) In response to the need for "differentiated event response configuration based on enterprise type and emission level in complex environmental application scenarios," this invention enables regulatory personnel to flexibly configure differentiated event response strategies based on enterprise type (key pollutant discharge unit / general pollutant discharge unit) and emission level (exceeding standards / meeting standards / early warning) in a visual interface by supporting dynamically registered component event meta-models, variable references and expression configurations, type-safe data flows, and conditional action chains. For example, an event of exceeding emission standards for key pollutant discharge units triggers immediate alarms and law enforcement linkage, while similar events for general pollutant discharge units are only recorded and archived. This achieves a comprehensive improvement in the interactive flexibility, system scalability, and collaborative efficiency of the visual platform in ecological and environmental verification and supervision scenarios, ensuring the development experience and operational reliability in complex environmental data linkage scenarios. Attached Figure Description

[0017] Figure 1 This is a schematic diagram of the method flow described in this invention; Figure 2 This is a schematic diagram of the system structure described in this invention; Figure 3 This is a schematic diagram of the event-driven and responsive data linkage processing flow described in this invention. Detailed Implementation

[0018] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] Example 1 This embodiment provides a method for linking event-driven visual components.

[0020] like Figure 3 As shown, this embodiment provides an event-driven and responsive data linkage communication method for visual building platforms. It is suitable for building low-code and no-code visual dashboards and business applications. It supports users without coding experience to achieve loosely coupled, orchestratable communication and data synchronization between components through visual configuration, adapting to complex linkage scenarios with a large number of configurable and interactive components. In existing technical solutions, the communication logic between components is often hard-coded within the source component. This not only leads to opaque communication links and difficulty in managing cross-component data dependencies, but also presents problems such as users lacking coding skills being unable to adjust linkage logic in visual building scenarios, a lack of unified orchestration and scheduling for asynchronous operation chains, and low reusability due to the lack of standardized intermediaries for data flow. These issues make it difficult to meet the flexible configuration requirements of visual building platforms.

[0021] The technical problem to be solved in this embodiment is: to establish a standardized communication method based on the "event-action" binding model, to realize flexible mapping of component events to single or compound action links through visual configuration, to integrate multi-scope centralized variable management, to realize responsive data flow between components, sharing and traceability across action links, and to support conditional execution of actions, serial or parallel orchestration, and to adapt to the actual business needs of visual construction.

[0022] This embodiment constructs a linkage method that deeply integrates declarative event binding configuration with centralized action execution scheduling. The core revolves around "component event triggering - configurable routing - standardized action execution - reactive data flow" to achieve full-process visual control. This method allows source components to declare their triggerable event types and responsive action types during the development phase. The platform (visual building platform) provides users with a graphical configuration interface, supporting the binding of specific component events to one or more predefined actions (including basic and composite actions) of target components, and allowing configuration of action execution conditions, execution order, and parameter mapping. At runtime, component triggers are uniformly captured (listened) by a central event dispatcher. The central event dispatcher filters valid linkage rules based on pre-configured binding relationships, schedules the corresponding action processors for execution, stores the execution results in the component instance C104, and updates the global variable pool G101 to achieve data sharing. Finally, through a reactive variable update mechanism, the visual values ​​of corresponding variables in the visual component are driven to update synchronously with the updated values ​​of corresponding variables in G101, achieving completely decoupled visual linkage between components.

[0023] Based on the above design, such as Figure 1 As shown, this embodiment constructs a complete process of an event-driven and responsive data linkage communication mechanism for a visualization building platform, consisting of steps S101 to S105.

[0024] S101. In the visual building platform, set the configurable events and data binding rules supported by each source component, and generate the source component event structure E101 and the component-level event control parameter set K101. This step constructs the source component event handling architecture declaration, used during the source component development phase. It standardizes the definition of source component communication capabilities, forming platform-recognizable and parsable communication metadata, providing a foundation for subsequent visual configuration. Each source component defines how it is rendered and the configuration rules. Each source component must declare standardized communication capability fields in its configuration description file. All fields follow the platform's unified syntax specifications to ensure the visual configurator can automatically parse and load them. Specifically, these include: variable rules, trigger event type (eventsType), target object (eventTargetKey), and executable target action type (actionType). Variable rules specify the number of variables that each component can bind to, the meaning of the variables, and restrictions on the variable value types; The event type (eventsType) is used to represent the category of interactive events that can trigger a component. Specifically, it lists all interactive event type identifiers that can be triggered when each component runs. The identifiers must be semantically unique globally on the platform, such as click, change, rowClick, paginationChange, search, reset, etc. At the same time, a simple semantic description and trigger scenario description are configured for each event.

[0025] The targetable object (eventTargetKey) is used to represent the target component or data entity that can be passed by the triggered source component. Specifically, a targetable component type identifier is added to each type of source component in the source component event structure E101. This is used to intelligently filter the list of optional target components during visual configuration, avoid invalid selections, and optimize the user configuration experience. For example, the source component triggered by the rowClick event of the table component can be a configurable detail component and a form component.

[0026] The executable target action type (actionType) indicates the specific response operation type that can be performed on the target object after the component is triggered. Specifically, it lists all action types that can be performed when each target object (component) is used as an event linkage target. These are divided into basic actions and composite actions. Basic actions include callapi (calling an interface), updateData (updating component data), setVariable (assigning a value to a variable), showDialog (displaying a pop-up window), etc. Composite actions are combinations and encapsulations of basic actions, such as showDialogWithCallapi (calling an interface and displaying the result in a pop-up window) and jumpNewPageWithParams (jumping to a page with parameters), etc., which are suitable for high-frequency business linkage scenarios.

[0027] The source component event structure E101 consists of the triggering event type (eventsType), the target object (eventTargetKey), and the executable target action type (actionType); The component-level event control parameter set K101 includes: event triggering condition templates, action parameter specifications, and variable referencing rules; The event trigger condition template (event trigger condition parameters) is used to define the threshold and scene constraints for event triggering; Action parameter specifications (action execution priority parameters) are used to specify the execution order when multiple actions are executed concurrently; The target object matching rule parameter is used to standardize the association logic between the source component and the target object. The target set defined by the source component contains the unique type identifier of the component. When configuring the panel, the target set of the current component is read and matched with the type identifier in the existing component instance set to obtain the unique identifier ID code that can represent the current component.

[0028] The event conflict resolution strategy parameter is used to handle conflict resolution strategies when multiple events are triggered from the same source component. It adopts sorting of bound event records and realizes the serial execution of events through asynchronous processing, that is, the next action can only be executed after one task is completed.

[0029] The variable reference rules consist of the target object matching rule parameters and the event conflict resolution strategy parameters.

[0030] The components include: basic components, multimedia components, form components, data display components, container components, and image components; Basic components: text, title, image, button, divider, link, label, progress bar, avatar, icon, etc.

[0031] Multimedia components: audio players, video players, background sound components, etc.

[0032] Form components: input boxes, selection boxes, color pickers, number input boxes, date pickers, switches, radio buttons, checkboxes, sliders, ratings, etc.

[0033] Data display components: tables, detail components, etc.

[0034] Container components: layout containers, cards, panels, etc.

[0035] Image components: Includes built-in navigation images and module background templates, etc.

[0036] The output of this step is a standardized communication capability description file for each component. This file will be collected, registered and managed uniformly by the metadata manager of the platform source components and synchronized to the visual configurator in real time.

[0037] The component-level event control parameter set K101 includes: event triggering condition templates, action parameter specifications, and variable referencing rules; S102. Based on E101 and K101, complete the rule configuration, obtain the configuration record set R101, store it in the component instance set C104, and create a global variable pool G101 based on E101; This step involves building a visual event and action binding configuration and defining and binding variables. This is implemented in the editor of the visual building platform, providing a purely graphical configuration interface for no-code and low-code users. The configuration rules for linking component events to target component actions can be completed without writing code. The configuration results will be attached to the component instance collection C104 in the form of structured data, and the global variable pool G101 will be created or updated. It supports editing, deletion and reuse at any time.

[0038] The rule configuration process is as follows: create a binding rule, select the target component and action based on E101, and then configure the action parameters according to K101. All configuration steps provide real-time verification, saving, and preview capabilities. The specific implementation process is as follows: Create binding rules: Generate a component event configuration panel based on the source component event structure E101. In the "Event Binding" area of ​​the panel, the user selects the event type that the current component needs to be configured and clicks "Add Binding" to generate an empty linkage rule record. Each record corresponds to a basic linkage relationship of "component-target-action". It also supports adding several binding rules for each component to realize the linkage of multiple components triggered by one event. In this embodiment, each component supports adding 0 to 20 binding rules. Target component selection based on E101: In the binding rule record, the user selects the linked target component from the component list of the current page or module, and the platform will filter the optional list according to the eventTargetKey that the triggered component can target; Action selection based on E101: After selecting a target component, the platform automatically loads the target action type (actionType) declared by that target component, and the user selects the specific action type to be executed from it; Next, configure the action parameters according to K101: Based on the selected action type, the platform will dynamically render the corresponding parameter configuration form. The form fields are automatically generated by the action parameter specifications matched in the component-level event control parameter set K101. For example, for variable assignment actions, two methods are supported: static configuration and dynamic variable reference: Static configuration: Directly input constant values ​​to modify the data of a variable in the global variable pool G101 to a fixed value; Dynamic variable referencing: Utilizing the platform's unified ${variableName} interpolation syntax, it references existing variables in the global variable pool G101 for calculations and updates the target variable with the result. Taking the `callapi` (interface call) action as an example, it allows configuration of the interface address, request method, request headers, request body (supporting JSON or form formats), data mapping rules, timeout, retry strategy, failure handling, etc. It also allows setting whether to execute in preview mode, whether to update the target component data, and whether to trigger a sub-request upon success.

[0039] Action execution rule configuration: When a single event is bound to multiple actions, they are executed sequentially according to the order of the actions. The next action is executed only after the previous action has been completed (successfully or unsuccessfully).

[0040] The output of this step is a set of configuration records R101 (bindings) attached to the trigger component's data model. This set is stored in structured JSON format and fully defines all the linkage logic after the event is triggered, including the trigger event, target component, action type, action parameters, execution conditions, execution order, etc. It also supports the export and import of configurations, enabling the reuse of linkage rules.

[0041] The configuration record set R101 includes: component type identifier, trigger event types supported by the component, target action type, and action configuration items containing templated parameters; The templated parameters are stored in the action configuration item as variable placeholders.

[0042] Global Variable Pool G101: Provides centralized variable storage, parsing, assignment and reactive update capabilities, maintains the dependency graph of "variable-dependent components / actions", is the core intermediary for data flow between components, and supports multi-scope variable management and variable persistence configuration.

[0043] The process of creating the global variable pool G101 is as follows: setting custom variables and their values; binding components to the variables to obtain a dependency graph. The specific implementation process is as follows: Variable Definition and Binding: A variable binding area (component event configuration panel) is dynamically generated based on variable rules in E101. Users can define corresponding variable names and set default values ​​for each key data field of a component (such as input values, selected records, pagination parameters, etc.). Variable names are identified by strings and will serve as the unique key for that field in the global variable pool G101. The platform automatically validates the variable value type (such as String, Number, Boolean, Object, Array) based on the component's modelOption.modelType definition. After definition, the variable is bound to the current component, forming a dependency graph. The corresponding data fields are synchronized to the global variable pool G101 for reference by other components or event actions. The data generated in this stage will be recorded in the component instance collection C104, serving as the data source for subsequent event binding and action configuration.

[0044] Each variable can be bound to several components.

[0045] S103. Generate an action mapping table based on R101 and G101; When the central event dispatcher detects that any component has triggered an event, the central event dispatcher queries the action mapping table based on the component that triggered the event and generates an event dispatch set E103. The action mapping table includes: several variables, several components bound to each variable, and configuration records corresponding to each component; The central event dispatcher is a global event management mechanism used to achieve decoupled communication between different component instances. Based on the publish-subscribe pattern, it allows one component to trigger an event (emit), while other components listen for the event (on / off), thereby completing cross-component data transfer or logical calls without needing to directly reference each other.

[0046] When a component is triggered by an event, the central event dispatcher queries the action mapping table (i.e., the binding relationship between components and actions) based on the triggered component, generating an action execution list, namely the event dispatch set E103. This set is typically an array, where each element corresponds to an action configuration to be executed (such as calling an API, updating data, displaying a pop-up, etc.), containing information such as action type, target component ID, and required parameters. The central event dispatcher iterates through this set and executes these actions sequentially, thereby achieving cross-component logical responses. During this step, the event triggering component, executed while the visualization application is running, acts as the "routing hub" for event linkage. It is responsible for the unified capture of events, validity verification, and filtering of valid binding rules, providing precise rule basis for subsequent action execution. The specific implementation process is as follows: Event encapsulation: When a user interacts with a component (such as clicking a query button or clicking a table row), the event handling logic encapsulated inside the component is triggered. The component emits a standardized event object through a unified method of the central event dispatcher (such as events.emit). This object contains required fields: event type, unique ID of the triggering component, unique ID of the current page or module, and raw event data (such as table row data or form input data). Optional fields include: event priority, trigger timestamp, etc. Unified event capture: The central event dispatcher listens to standardized event objects emitted by all components in real time, receives and temporarily stores the events in a unified manner, and supports configuring debouncing or throttling strategies for high-frequency triggered events (such as input box change events) to avoid performance issues caused by high-frequency event triggering. The parameters for debouncing or throttling can be set uniformly in the platform's global configuration. Binding rule filtering and validation: During platform runtime, the central event dispatcher filters matching binding rules from the bindings configuration array of the triggered component based on the unique ID of the triggering component and the event type in the standardized event object. Then, the selected rules are validated for validity, including whether the target component exists (has not been deleted), whether the action parameters are complete, and whether the variable references are valid. Invalid binding rules are filtered out, and only valid rules are retained. Rule distribution: The central event dispatcher distributes the verified and valid binding rules to the platform action execution engine according to the event priority and the execution order configured in the rule, and waits for the action to be executed.

[0047] S104. Execute the corresponding action according to E103, obtain the action execution result set A104 and store it in the component instance set C104, and update G101 according to A104; The process of updating G101 according to A104 is as follows: based on the action execution result, push the triggered component corresponding to the action execution result in reverse, and then update the value of the variable corresponding to the triggered component in G101 according to the action execution result.

[0048] This step is the core execution engine (i.e., the action execution engine) for event linkage. It is responsible for scheduling actions, parsing parameters, standardizing execution, and providing result feedback based on the event distribution set E103, while also enabling responsive data flow. This step receives valid binding rules (i.e., E103) distributed from the central event dispatcher, configures and drives underlying capabilities according to the rules, and transforms the linkage rules defined by the user in the configuration interface into actual interactive behaviors. The specific implementation process is as follows: Action scheduling: Tasks are created sequentially according to the configuration order in E103, and a task queue for action execution is generated.

[0049] Execution context preparation: Before each action task is executed, an independent execution context is created, which contains: the original data of the triggered component, the global variables of the current page or module, and the instance information of the target component; Dynamically resolve variable placeholders: Dynamically resolve all ${variableName} variable placeholders in the action configuration, retrieve the latest value of the variable from the global variable pool G101, instantiate the action parameter configuration template into a specific parameter that can be executed directly, and terminate the execution of the action if the variable reference is invalid and log the error information.

[0050] Standardized action execution: Based on the action type, the corresponding standardized action handler is invoked (e.g., handleCallApi handles the callapi action, handleSetVariable handles the setVariable action). The execution logic of different action types follows the platform's unified standard. Core action execution details: Call API (callapi): Initiates a network request based on the instantiated parameters, supporting common request methods such as GET, POST, PUT, and DELETE, and supports custom configuration of request headers; for the returned response data, it supports extracting specified data using JSONPath syntax, and can also configure custom data processing scripts to transform the response data; it also supports main-sub-interface linkage, meaning that after the main interface call is successful, the sub-interface call is automatically triggered based on the data returned by the main interface. Variable assignment (setVariable): Based on the configured variable name and assignment method (static constant or function expression), the value is assigned to the corresponding variable in the global variable pool G101. If it is a function expression, the expression will be executed in the safe sandbox environment. Other variables can be referenced in the expression through ${variable}. The execution result will be automatically written back to the variable pool (global variable pool G101).

[0051] Update component data (updateData): The instantiated payload data is sent to the target component via the central event dispatcher. After receiving the data, the target component triggers its own view update and state recalculation, achieving component data synchronization. Composite actions (e.g., showDialogWithCallapi): Execute basic actions according to a preset logical order. First, the API is called. If the API call succeeds, the returned data is passed to the popup component, and then the popup is displayed. If the API call fails, the configured failure handling strategy is triggered (e.g., displaying an error popup). The execution of composite actions is atomic, ensuring the logical integrity of the action combination. Other basic actions: showDialog (show popup), hideDialog (hide popup), jumpNewPage (page jump), etc., call the corresponding platform-level APIs, execute corresponding UI operations or routing operations, and pass in event data and parsed parameters to achieve parameterized interaction.

[0052] Results Feedback and Data Update: Action execution results are fed back. After each action is completed, the execution result is recorded to form the action execution result set A104. Updates to variables will be directly written to G101. S105. Based on the updated G101, responsively update the visualization components in the visualization platform, complete the interface update, and generate view update record V105.

[0053] The specific steps of updating the visualization components in the visualization platform in a responsive manner according to the updated G101 are as follows: synchronizing the visualized values ​​of the corresponding variables in the visualization components with the values ​​of the corresponding variables in the updated G101.

[0054] This step implements data write-back and reactive updates: For data update actions (such as `callapi` and `setVariable`), the execution results are written back to the platform's global variable pool G101 according to the configuration. When the variable value in G101 changes, the platform's built-in dependency graph is immediately triggered: the dependency graph is based on the observer pattern and maintains the mapping relationship between each variable and its dependencies (including visual components, action parameter placeholders, etc.). Once a variable is updated, G101 will actively notify all components registered as dependencies of that variable and action parameters to be executed. The relevant components automatically pull the latest data from G101 and re-render the view, thus completing the interface update; at the same time, subsequent actions will re-parse the variable placeholders before execution to ensure that the latest variable value is used, forming a reactive data flow. This process generates view update record V105 (for performance tracing and debugging).

[0055] New event triggering: During the execution of an action, if a new interactive behavior is generated (such as triggering the "data loading complete" event after a successful API call), the target component will emit a new standardized event object, re-enter the event routing process of S103, form a chain linkage, and realize complex business logic orchestration.

[0056] Example 2 This embodiment further defines Embodiment 1. This embodiment provides an event-driven visual component linkage system, which is used to implement the method described in Embodiment 1, such as... Figure 2 As shown, the linkage system mainly consists of five core modules, which cooperate with each other to achieve full-process control from component metadata management to action execution. The system includes: a component metadata manager, a visual binding configurator, an event router, an action execution engine, and a responsive data linkage unit; Component Metadata Manager: Responsible for the unified collection, registration, management and synchronization of component event and action capability declarations in step S101, providing real-time component communication capability data for the visual binding configurator; Visual binding configurator: Corresponding to step S102, it provides users with a graphical event-action binding configuration interface in the platform editor, enabling them to edit, save, verify, and export configuration rules. The core logic is encapsulated in the visual configuration-related components. Event Router: Responsible for steps S103, implementing unified capture, validity verification, binding rule filtering and distribution of runtime events, and is the "routing hub" of event linkage; Action Execution Engine: Responsible for step S104, it is the core of action execution, containing standardized processors for all action types, and implementing action scheduling, parameter parsing, execution and result feedback. The core logic is encapsulated in core files related to action processing. Responsive Data Linkage Unit: Responsible for step S105. Based on the updated G101, it responsively updates the visualization components in the visualization platform, completes the interface update, and generates view update record V105.

[0057] This embodiment takes a typical "query-table-details" business linkage scenario in a visual building platform as an example to explain in detail the complete workflow of the communication mechanism of the present invention. The business requirements of this scenario are: users enter keywords to query data through the query component, and the table component displays the query results; when users click on a row in the table, a pop-up window displays the details of the data in that row, and the details data is obtained by calling the interface.

[0058] In this embodiment, the specific execution process of the component metadata declaration unit includes three sub-steps: defining the standardized communication capability declaration of the component, registering and synchronizing the component metadata, and generating the component event handling architecture and control parameter set. Through this process, the standardized declaration of configurable events, target objects, and action types for each component is completed, providing unified event binding metadata support for the configuration area of ​​the visualization platform.

[0059] In the definition of standardized communication capabilities for components, the system defines standardized communication capability declarations for each type of component based on the core functionality of the component and the interaction specifications of the visualization platform. This clarifies the configurable events, executable actions, and targetable objects supported by the component, forming a structured set of core fields. The configuration and logic of each component's core fields are explained below: formQuery (query component): Focuses on data query and condition control functions. It declares the trigger event type (eventsType) as ["search", "reset"], corresponding to the two core interaction scenarios of query triggering and condition resetting, respectively; the executable action type (actionType) is ["callapi", "updateData", "setVariable"], where "callapi" is used to call the backend interface to obtain data, "updateData" is used to update the data source of the associated component, and "setVariable" is used to set a global variable to store query conditions; the target object (eventTargetKey) is ["table", "chart"], that is, the event of this component can be associated with and drive the interaction response of table and chart components. The table component is designed around data display and row-level interaction. It declares event types (eventsType) as ["rowClick", "paginationChange", "sortChange"], corresponding to row clicks, pagination switching, and sort changes, respectively. The executable action types (actionType) are ["callapi", "showDialogWithCallapi", "jumpNewPageWithParams"], where "callapi" triggers related data requests, "showDialogWithCallapi" opens a details popup and synchronously calls the API to load data, and "jumpNewPageWithParams" carries row data parameters to a new page. The target object (eventTargetKey) is ["detailDialog", "formEdit"], supporting the display and data linkage of details popups and edit form components. detailDialog (details pop-up component): Designed for pop-up lifecycle control, it declares the trigger event type (eventsType) as ["close", "confirm"], corresponding to the pop-up closing and confirmation submission operations respectively; the executable action type (actionType) is ["updateData", "hideDialog"], where "updateData" is used to submit the modified data in the pop-up and update the associated components, and "hideDialog" is used to simply close the pop-up; the target object (eventTargetKey) is [], meaning that this component's event has no external target object and only affects its own state and associated data updates. The aforementioned core fields must comply with the platform's unified metadata specifications, and the field values ​​must be consistent with the platform's action dictionary and component identifier dictionary to ensure compatibility and standardization of cross-component interactions, providing a basis for subsequent event binding and action execution.

[0060] After the standardized communication capability declaration files for each component are defined, they are submitted by the developers to the component metadata manager. This manager, acting as a unified metadata control node, first performs a validity check on the declaration files. This check includes verifying field completeness, field value standardization, logical matching of actions and events, and the validity of target object identifiers, preventing invalid or incompatible metadata from entering the system. Once the verification is successful, the component metadata manager uniformly enters the declaration information of each component into the metadata repository, establishing a one-to-one correspondence between component types and communication capability declarations, and generating a globally unique component metadata index for easy subsequent querying and retrieval. Simultaneously, the manager synchronizes the complete set of component metadata to the component property configuration panel according to a preset synchronization strategy. During the synchronization process, the integrity and timeliness of the metadata must be ensured, and the synchronization results are fed back to the metadata repository in real time for version registration, forming a traceable metadata version record that supports subsequent metadata updates and rollback operations.

[0061] After receiving the synchronized set of component metadata, the component property configuration panel constructs the source component event handling architecture based on the built-in event handling logic of each component. This architecture extracts core metadata such as the event types that can be bound, the target objects that can be targeted, and the types of target actions that can be executed for each component, forming a structured metadata directory that provides clear event binding options for users in the configuration area. Meanwhile, the component property configuration panel generates a set of component-level event control parameters based on the above metadata. This set includes event triggering condition parameters, action execution priority parameters, target object matching rule parameters, and event conflict resolution strategy parameters.

[0062] Among them, the event triggering condition parameter (event triggering condition template) is used to define the threshold and scenario constraints for event triggering; the action execution priority parameter (action parameter specification) is used to clarify the execution order when multiple actions are executed concurrently; the target object matching rule parameter is used to standardize the association logic between components and target objects; and the event conflict resolution strategy parameter is used to handle conflicts when multiple events of the same component are triggered. The target object matching rule parameter and the event conflict resolution strategy parameter together constitute the variable reference rule.

[0063] The generated component event handling architecture and component-level event control parameter set are written into the source component event structure E101 and the component-level event control parameter set K101, respectively. E101 focuses on recording the relationships between bindable events, target objects, and action types at the component level; K101 focuses on centrally managing component-level event control parameters, providing unified parameter support for event binding configuration, action execution scheduling, and conflict handling. Together, they constitute the basic framework for component event interaction. Subsequent event binding operations in the configuration area and inter-component interaction are all based on this framework, eliminating the need to repeatedly parse component communication capability declarations and improving the efficiency and standardization of system interaction configuration.

[0064] The visual binding configurator is used to transform the component linkage rules configured by the user through the graphical interface into standardized event-action binding relationships based on E101 (component event structure) and K101 (event control parameter set), combined with the edit view configuration set and user interaction operation set. It simultaneously completes parameter verification, global variable mapping and binding record persistence, and finally updates the configuration record set R101, providing a unified configuration basis for subsequent multi-terminal event triggering and action execution.

[0065] In this embodiment, the implementation process of the visual binding configurator includes sub-steps such as binding configuration initialization and optional loading, event-action binding rule configuration and parameter verification, binding relationship persistence and global variable linkage configuration.

[0066] The visual binding configurator first reads the core data from E101 and K101. E101 provides the event types that each component can be bound to, the list of target components, and the supported action types. K101 provides event trigger condition templates, action parameter specifications, and variable referencing rules. Based on this data, the platform editor initializes the event-action binding configuration interface, displaying configurable components categorized by component type and listing the supported eventType options for each component, allowing users to select the events to be configured. When a user selects a target component (such as the query component formQuery or the table component table) and selects a specific event (such as search or rowClick), the system matches the eventTargetKey list corresponding to that event from E101, filters out the target components already loaded in the current editing view (such as the search event for table corresponding to formQuery, and the rowClick event for detailDialog corresponding to table), and loads the actionType option supported by the event and the corresponding action parameter template. The parameter template includes required fields (such as interface URL and request method), optional fields (such as pop-up size and failure strategy), and variable reference format hints, providing guidance for the user's graphical configuration.

[0067] In the event-action binding rule configuration and parameter validation, users can complete the rule configuration through graphical operations such as drag-and-drop selection, drop-down checkboxes, and text input. No code needs to be written throughout the process, and the system performs parameter validity validation in real time to ensure that the configuration logic is effective. In the search event configuration of the formQuery component, the user first adds a binding rule, selecting the table component from the target component list and the callapi action from the action type list. Then, in the parameter configuration panel, the user fills in the interface URL as / api / query / data according to the template, selects POST as the request method from the dropdown, references the global variable ${searchKeyword} bound to the query component input box in the request parameter field using the variable selector, specifies the extraction path as data.list (used to populate the table data list) in the response data configuration field, and selects "display error message, retry 1 time" as the failure handling method from the preset strategy. Finally, the user enters the syntax rule ${searchKeyword} != '' in the execution condition configuration area, setting the action to be triggered only when the query keyword is not empty. The system verifies in real time: whether the variable ${searchKeyword} has been registered in the global variable pool, whether the interface URL format is valid, and whether the execution condition syntax is correct. Only after passing the verification can the configuration item be saved. In the `rowClick` event configuration of the `table` component, the user adds a binding rule, selects the `detailDialog` component as the target component, and chooses the composite action `showDialogWithCallapi` as the action type. During parameter configuration, the interface URL is set to ` / api / query / detail`, the request method is set to GET, and the ID variable `${selectedRow.id}` of the selected row in the table is used as the request parameter via a variable referencing mechanism. The pop-up title is set to "Data Details", the pop-up width is set to 800px, and the failure handling strategy is set to "Display error message, do not retry". The system synchronously verifies whether `${selectedRow.id}` is a row-level variable supported by the table component and whether the composite action parameters are complete (no missing or required fields). If any parameters are invalid (e.g., variables do not exist), the user is prompted to correct them in real time.

[0068] After the above processing is completed and all event-action binding rules are configured and verified, the system transforms the configuration content into a standardized binding relationship model. This model includes core fields such as triggering component identifier, triggering event type, target component identifier, action type, action parameter set, execution conditions, and failure handling strategy. Subsequently, the system checks in R101 whether a historical binding record for this triggering component-event combination exists: if it exists, the action parameters, execution conditions, and other fields are updated, and the historical configuration version is retained for rollback; if it does not exist, a new binding record is added, associated with the component identifier, written into the component rendering structure (associated with C104), and the complete binding rules, thus achieving the persistence of the binding relationship. Simultaneously, the system automatically completes the global variable linkage configuration: establishing a real-time synchronous association between the query component's input box and the searchKeyword in the global variable pool, updating the value of searchKeyword synchronously when the input box content changes, ensuring the timeliness of request parameter references; binding the selected row data of the table component to the global variable selectedRow, synchronizing the content of selectedRow (including id and other row data fields) in real time when the row selection state changes (such as switching the selected row or deselecting), providing data support for the parameter references of the rowClick event. The synchronization rules are configured according to the variable update strategy in K101, setting a synchronization delay threshold (default 0ms, real-time synchronization) to avoid interface lag caused by frequent updates. After this step is completed, the newly added or updated configuration records and layout records in R101 are associated to form a complete link of data: "component location - event triggering - action execution". Each bound record contains a unique identifier field used to associate the event metadata of E101 and the control parameters of K101. The global variable pool registers the variable source (corresponding component and field) of searchKeyword and selectedRow, as well as update rules, to provide a basis for parameter parsing during event triggering. The subsequent step S103 (runtime event triggering) can directly deduce the event triggering logic of each terminal based on the configuration records and global variables of R101; step S104 (action scheduling execution) can compare the terminal event execution results with the configuration rules of R101, eliminating the need to repeatedly parse the graphical configuration operation and improving the efficiency of multi-stage collaboration.

[0069] In this embodiment, the event router is used to capture user interaction operations and generate standardized event objects based on E101 (source component event structure), R101 (configuration record set), K101 (component-level event control parameter set) and G101 (global variable pool). After legality pre-check and rule matching, it outputs the event distribution set E103, which provides accurate triggering basis and execution context support for S104 action scheduling, ensuring that the event triggering logic is consistent with the edit state configuration rules.

[0070] In this embodiment, the process of the event router executing specific event capture and generating event distribution set E103 includes three sub-steps: user interaction event capture and standardization, event legality pre-check and binding rule matching, and event object distribution and execution context preparation.

[0071] In user interaction event capture and standardization, the system monitors user interaction behavior of each component in real time during the visualization application's runtime phase. Based on the component event metadata registered in E101, it filters invalid interactions (such as events without configured binding rules or operations performed when the component is disabled). When a user performs an interaction, the system accurately captures the operation type and associated component information: for example, when a user enters "Beijing" in the input box of the formQuery component and clicks the "Query" button, the formQuery component triggers a preset search event; when a user clicks a row in the table component, the table component triggers a rowClick event. For captured interactive behaviors, the system generates standardized event objects in a unified format according to the event standardization rules defined in K101. The core fields of the object include: triggering component identifier (such as a unique ID for formQuery / table), event type (search / rowClick), trigger timestamp, and operation context data (form input data for formQuery / selected row data for table). Simultaneously, the system automatically synchronizes associated global variables: the content of the formQuery input box is updated in real-time to the searchKeyword variable in G101, and the selected row data of the table is synchronized to the selectedRow variable in G101. The synchronization logic follows the variable update strategy of K101 to ensure precise alignment between variable values ​​and event triggering timing.

[0072] In the event validity pre-check and binding rule matching, the system passes the standardized event object to the central event dispatcher (event bus) to trigger a query from R101 for the binding rule set corresponding to the component-event combination, using the component identifier and event type as a joint index. Simultaneously, based on the validity verification rules of K101, a three-layer pre-check is performed: first, a target component existence check confirms that the target component (table / detailDialog) specified in the binding rule has been loaded and is available; second, a variable reference validity check verifies that the global variables (${searchKeyword} / ${selectedRow.id}) associated with the event object are registered in G101 and their value types match; third, an execution condition check verifies whether the execution condition ${searchKeyword} != '' is satisfied for the formQuery search event. If not, the subsequent process is terminated and a prompt is provided according to the K101 rules. After the pre-screening is passed, the central event dispatcher filters out perfectly matching rules from the action mapping table: the search event matches the callapi action rule, and the rowClick event matches the showDialogWithCallapi composite action rule. During the filtering process, the system synchronously reads the action execution priority parameters in K101. If multiple rules conflict, they are sorted according to priority. In this embodiment, there is no scenario with multiple rule conflicts, so a unique matching rule is directly output.

[0073] In the event object distribution and execution context preparation, the system associates the matched binding rules with standardized event objects to construct an event distribution set E103. E103 is indexed by component ID and registers the triggering component identifier, event type, matching rule ID, target component identifier, action type, and associated global variable reference information. Subsequently, the system distributes the event information in E103 to the action execution engine and initializes an independent execution context for each event. The context includes: complete parameters of the binding rule in R101 (interface URL, request method, failure strategy, etc.), real-time values ​​of associated variables in G101, and action execution constraint parameters in K101 (such as retry count, timeout threshold), providing complete input for the action scheduling execution in S104. The action execution engine is used to execute action scheduling, interface interaction and component linkage according to the binding rules based on E103 (event distribution set), R101, K101 and the current component instance set (execution state), and generate action execution result set A104 and component state update record U104 to ensure that the visual linkage logic is accurately implemented and the execution process is traceable and verifiable. In this embodiment, the specific implementation process of the action execution engine includes five core steps: action scheduling, execution context preparation, dynamic resolution of variable placeholders, updating component data, and result feedback and responsive data flow.

[0074] In action scheduling, the system performs hierarchical scheduling based on action type. Ordinary actions (such as `callapi`) directly call the corresponding standardized handler, while composite actions (such as `showDialogWithCallapi`) are executed step-by-step according to a preset process. For the `callapi` action of the `search` event: the engine calls the `handleCallApi` handler, initiates a request to the ` / api / query / data` interface, and performs exception handling according to the failure policy configured in R101 (displaying an error message and retrying once). If the request times out or the response is incorrect, a retry mechanism is triggered, and an error message is displayed after a failed retry. For the `showDialogWithCallapi` composite action of the `rowClick` event: the engine first calls the interface handler to initiate a request to ` / api / query / detail`. If the request succeeds, the pop-up display action is executed; if the request fails, it is handled according to the configuration (displaying an error message and not retrying), without triggering a pop-up. During scheduling, the system records the execution status (waiting for response / execution successful / execution failed), time consumption, response data, and other information in real time, providing a basis for subsequent result feedback.

[0075] During execution context preparation, the action execution engine receives event information dispatched by E103 and initializes the action execution task based on the execution context. The context contains the raw data that triggered the event (such as form input values, selected row data), a snapshot of the global variable pool G101 of the current page or module, instance information of the target component, etc. This context provides a complete runtime environment for subsequent parameter parsing and action execution.

[0076] In the dynamic variable placeholder parsing stage, the action execution engine dynamically parses all ${variableName} variable placeholders in the action configuration according to the variable parsing rules in the component-level event control parameter set K101. It retrieves the latest value of the variable from the global variable pool G101 and instantiates the parameter configuration template into directly executable parameters. For the `callapi` action of the `search` event: it parses ${searchKeyword} to the user-inputted "Beijing" and fills it into the request parameter `keyword`. Combined with the interface URL ( / api / query / data) and request method (POST) configured in R101, it generates a complete set of interface request parameters. For the `showDialogWithCallapi` action of the `rowClick` event: it parses ${selectedRow.id} to the actual ID of the selected row in the table (e.g., "1001") and fills it into the GET request parameters. It also synchronously reads the pop-up title ("Data Details"), width (800px), and other configuration parameters to construct composite action execution parameters. After the parameters are parsed, the system performs the final legality check according to the K101 verification rules (which include variable reference rules) to confirm that the interface parameter format is valid, the variable substitution is unambiguous, and the composite action parameters are complete. If the verification passes, the system enters the action scheduling stage; if the verification fails, the system terminates execution according to the preset strategy and records the error information to A104.

[0077] After the interface interaction is completed, the system drives component linkage based on the execution result: When the `callapi` action is executed successfully, `data.list` is extracted from the response data and sent to the target component `table` via the global event bus. After receiving the data, the `table` component automatically refreshes its view to display the query results, and simultaneously records the component status update (data refresh time, data volume) in U104. When the `showDialogWithCallapi` action is executed successfully, the detailed data returned by the interface is passed to the `detailDialog` component, triggering a pop-up window to be displayed and populated with data. The pop-up window status (show / hide, associated data ID) is recorded in U104. All component status updates follow the component interaction specifications of E101 and do not modify the core configuration of layout and binding rules in R101, ensuring that the linkage logic is consistent with the edit state configuration.

[0078] Finally, in the result feedback and responsive data flow stage, the engine writes the execution result of each action (including success / failure status, time consumption, response data, error information, etc.) into the action execution result set A104. A104 is indexed by the component ID and forms a one-to-one correspondence with E103, ensuring the traceability of the execution process. If the action execution fails, the system feeds back to the user according to the failure strategy configured in R101 (such as displaying an error message), and records the error code, error information, and handling method in A104 to provide a basis for subsequent troubleshooting. It also records the component status update record U104. Data involved in the execution result (such as fields returned by the interface) will be ultimately written back to G101 through the responsive data linkage unit, triggering the component view update of dependent variables, forming the view update record V105, realizing a complete responsive data flow closed loop.

[0079] Through the above processing, the event distribution set E103 achieves a precise mapping between runtime events and editing-state binding rules, the action execution result set A104 fully records the execution process and results of each action, and the component state update record U104 synchronizes the state changes after component linkage. E103, A104, and U104 form a closed loop with E101, R101, and K101 mentioned earlier. Subsequently, consistency verification of linkage logic can be carried out based on A104 and U104 without repeatedly parsing user interaction behavior or binding rules, improving the stability and maintainability of runtime linkage. The entire process requires no user coding; the rules of visual configuration dominate the linkage logic throughout, and communication link information can be traced through A104, supporting real-time modification of configurations in the editor with synchronous effects.

[0080] In this embodiment, step S105 is executed by the responsive data linkage unit to realize the responsive data linkage closed loop and component view update. The responsive update module is used to complete the parameter parsing of the action execution result, business logic implementation, data write-back and component responsive update based on A104 (action execution result set), R101 (configuration record set), K101 (event control parameter set) and global responsive data storage G101, and generate variable update log L105 and component view update record V105 to ensure a complete data linkage closed loop from event triggering to interface presentation, and the update process is traceable and verifiable.

[0081] In this embodiment, the specific implementation process of the responsive data linkage unit includes four sub-steps: final parsing and validity verification of runtime parameters, standardized execution of predefined business logic, responsive data write-back of processing results, and responsive update of dependent component views.

[0082] In the final parsing and validity verification of runtime parameters, the reactive data linkage unit receives the action execution result from A104 and then parses all runtime parameter values ​​required for the target action from E103 and G101. For the `callapi` action execution result of the `search` event: it parses the query trigger timestamp in the event object, the `${searchKeyword}` variable value (with the value "Beijing") in G101, and the raw response data returned by the interface, extracting the core parameters that need to be mapped to the table component; for the action execution result of the above event: it parses the raw data of the selected row in the event object, `{selectedRow.id}` (with the value "1001"), and the raw data returned by the details interface in A104, extracting all parameters required for the pop-up display. After parameter parsing is completed, the system performs a final validity check according to the parameter validation rules of K101 to confirm parameter type matching (e.g., ID is numeric and query keyword is string), non-empty constraints (e.g., table rendering data list is not empty), and data mapping relationship compliance (e.g., interface returned fields match global variable fields). If the validation fails, this step is terminated, and the error information is recorded to A104 according to the failure policy configured in R101. If the validation passes, the business logic execution phase begins.

[0083] In the standardized execution of predefined business logic, the reactive data linkage unit executes the corresponding predefined business logic according to the target action type specified in the binding rules in R101. For the `callapi` action of the `search` event: it executes the format conversion logic of the interface response data (such as converting the JSON format data returned by the interface into an array format recognizable by the table component, supplementing field aliases, data formatting, etc.); for the `showDialogWithCallapi` action of the `rowClick` event: it executes the field mapping logic of the detail data (such as mapping the "create_time" field returned by the interface to the "creation time" displayed in the pop-up window, and converting the value (1 / 0) of the "status" field to the text description of "enabled / disabled"). All business logic follows the platform's predefined standardized execution specifications, runs in a secure sandbox environment to avoid malicious logic execution, and the execution time and status (success / failure) are written to the variable update log L105 in real time. L105 is indexed by the variable ID and forms a one-to-one correspondence with A104, ensuring the traceability of the business logic execution process.

[0084] In the reactive data write-back process, the reactive data linkage unit updates the results of business logic processing to the corresponding variables in the global reactive data storage G101 according to the data mapping relationship defined in the R101 binding rules. For the `callapi` action of the `search` event: the formatted table data is updated to the variables in G101, and the total number of rows returned by the interface is updated to the `{totalCount}` variable; for the `showDialogWithCallapi` action of the `rowClick` event: the detailed data after field mapping is updated to the variables in G101. Data write-back adopts atomic operation. If multiple variables need to be updated simultaneously (such as `{tableData}` and `${totalCount}`), it is ensured that all variables are either updated successfully or rolled back completely to avoid data inconsistency. After the write-back is completed, G101 automatically records the variable's value before update, value after update, update timestamp, associated event ID, and action ID, and synchronizes them to L105 to form a complete variable update traceability chain. In the reactive update of dependent component views, G101 immediately triggers its built-in dependency notification mechanism after a variable is updated, automatically identifying and notifying all visualization components that depend on that variable. For variable updates: a reactive update is triggered in the table component, which automatically retrieves the latest value of {tableData}, recalculates the view rendering data, and refreshes the table list to display query results related to "Beijing". For variable updates: a reactive update is triggered in the details pop-up component, which retrieves the latest value of {detailData} and populates the various display fields of the pop-up, completing the visualization of the details data. After the component view update is complete, the system writes information such as update time, updated data volume, and component status (e.g., table loading complete, pop-up display) into the component view update record V105. V105 is indexed by the component ID and associated with L105. If the component update fails (e.g., due to data format incompatibility), the system displays an error message according to the exception handling rules of K101, and records the error code, error message, and handling method in V105, providing a basis for subsequent troubleshooting.

[0085] Through the above processing, variable update log L105 fully records the update process of global reactive data, and component view update log V105 synchronizes the changed state of component views. L105, V105, and E101, R101, K101, E103, and A104 form a complete event-driven, data-linked, and view-update closed loop. Subsequently, data linkage consistency verification can be performed based on L105 and V105 without repeatedly parsing action execution results or binding rules, improving the stability and maintainability of visual linkage. The entire process requires no user coding, relying entirely on the binding rules of the visual configuration. Parameter parsing, data write-back, and view updates throughout the entire chain can be traced through logs. Data mapping rules can be modified in real-time in the editor and take effect synchronously, ultimately completing a full data linkage closed loop from event triggering to interface update.

[0086] Example 3 This embodiment further defines embodiments 1 and 2.

[0087] Based on Embodiment 1 or 2, this embodiment can configure a global variable pool. This central pool serves as the core of this invention for achieving responsive data flow. It not only provides variable storage and parsing capabilities but also maintains a complete dependency graph, ensuring that data changes can accurately drive the updates of related components and actions. Its specific implementation details and responsive principles are as follows: In this embodiment, the core design of the global variable pool revolves around five dimensions: multi-scope management, dynamic dependency association, reactive updates, persistent synchronization, and visual control. The definition and flow logic of the core data structure in the previous embodiments remain unchanged throughout the process, and the reactive capabilities are extended only by adding a data management link. For multi-scope variable management, the global variable pool supports three levels of variable scope, ranked from highest to lowest priority: component scope, page or module scope, and global scope. Component-scoped variables are only visible and accessible to the current component; page or module-scoped variables can be shared and accessed by all components within the current page or module; and global-scoped variables can circulate among all components of the entire application. Variables from different scopes are isolated using independent namespaces, fundamentally avoiding variable name conflicts. It also supports scope inheritance and overriding mechanisms, allowing variables in lower-priority scopes to be overridden by variables with the same name in higher-priority scopes. This ensures that local configurations can flexibly adapt to specific business scenarios without affecting global data consistency.

[0088] Regarding the maintenance of the variable dependency graph, the global variable pool continuously builds and updates a dynamic dependency graph of "variables-dependent objects," which includes front-end components and various action parameters. When a component references a variable during initialization rendering or action configuration parsing, the variable pool automatically adds the component or action parameter to the dependency list of the corresponding variable, forming a bidirectional dependency relationship. If a component is uninstalled, an action is deleted, or a variable reference is canceled, the variable pool will simultaneously remove the corresponding object from the dependency list, ensuring the lightweight and accuracy of the graph. The reactive update mechanism for variables employs a closed-loop logic of "change triggering - notification distribution - partial update". When a variable value is modified through methods such as active `setVariable` calls, API response data mapping, or user interaction, the variable pool first updates its own stored variable value and simultaneously triggers the dependency notification mechanism. This mechanism iterates through the variable's dependency list and sends update notifications to all associated dependency objects. Upon receiving the notification, the dependent component automatically retrieves the latest variable value and performs its own view re-rendering and state recalculation without requiring a global page refresh. When a dependency action parameter receives the notification, it does not immediately execute the action; instead, it re-parses the variable and retrieves the latest parameter value the next time the action is triggered, ensuring the accuracy and timeliness of the action execution.

[0089] The variable persistence and synchronization features can be flexibly configured according to business needs. During variable creation or editing, users can choose from three persistence methods: session-level persistence (variable values ​​are retained after page refresh and cleared after browser closure), local storage persistence (variable values ​​are retained even after browser closure until manually cleared or expired), and no persistence (variable values ​​are immediately lost after page refresh). Simultaneously, the global variable pool supports real-time synchronization of variables across multiple tabs. When a variable value changes in one tab, the variable pools of other tabs opening the same application will synchronize the change in real time through the browser's cross-tab communication mechanism, updating the variable values ​​in local storage and memory, thus achieving data consistency across multiple tabs. Visual management of variables is achieved through a dedicated management panel. The platform provides a visual interface for the global variable pool, allowing users to intuitively view basic information about all variables, including variable name, scope, current value, data type, latest update time, and number of associated dependent objects. Manual modification of variable values ​​is also supported; once a modification is triggered, a reactive update mechanism is immediately activated, simultaneously notifying all dependent objects and quickly adjusting the view and state in tandem. This significantly improves the efficiency of application debugging, testing, and daily maintenance. The entire implementation of the global variable pool only adds data management and reactive triggering links, without changing the structure and generation method of the core data structure in the aforementioned embodiments, ensuring compatibility with the original system.

[0090] Example 4 This embodiment further defines embodiments 1 and 2.

[0091] Building upon Embodiment 1 or 2, this embodiment expands upon the capabilities of composite action orchestration and asynchronous action chains. Through enhanced design of the action execution engine, it adapts to complex business linkage scenarios, improving the controllability and continuity of multi-step asynchronous operations. The following example, "data saving after user form submission - list refresh - feedback prompt," details its extended implementation: The core requirement of this scenario is that after the user submits the form, this embodiment needs to sequentially complete the following steps: saving interface data, retrieving the latest list data, updating the table data source, and displaying a success message pop-up. This forms a multi-step asynchronous action chain, and if any step fails, the process must be terminated and an error message must be provided. This embodiment achieves flexible configuration and reliable operation of this scenario through a visual action orchestration interface and a serial execution mechanism. In the configuration phase, a custom action chain rule is first bound to the submit event of the form component `formEdit`. The action type is selected as "composite action chain". This embodiment provides a visual orchestration interface, allowing users to drag and drop action components, configure the execution order and exception handling strategy, without the need for manual coding. In the orchestration interface, users add four actions in sequence according to business logic and configure them for serial execution mode, meaning that the next action can only be triggered after the previous action is successfully executed, forming a strict execution order dependency. The specific configurations for each action are as follows: Action 1 is `callapi` (interface call action), configured to call the data saving interface ` / api / save / data`, with the request parameter referencing the `formData` variable of the form component to ensure that the submitted data is consistent with the form content. The failure handling strategy is set to "display error message and terminate action chain," meaning that if the interface call fails, an error message pop-up will appear to inform the user, and the execution of all subsequent actions will be interrupted. Action 2 is `callapi` (interface call action), configured to call the list data retrieval interface ` / api / query / list`, with the request parameter referencing the `id` field in the returned data of Action 1, enabling accurate querying based on the previously saved results. The failure handling strategy is the same as Action 1, ensuring rapid termination and feedback in case of process abnormalities. Action 3 is `updateData` (data update action), configured to update the data source of the table component `table`, with the data source being the `data.list` field in the returned data of Action 2, enabling real-time refreshing of the table data. Action 4 is `showDialog` (pop-up display action), configured with the pop-up content as "Save successful," the pop-up type as "Success message," and the automatic close time set to 2 seconds, providing feedback for completing the process loop. During runtime, when a user clicks the form submit button and triggers the submit event, the action execution engine loads the preset action chain configuration and starts executing actions in sequence. The engine first executes action 1, calling the data saving interface. If the interface returns successfully, it extracts the `id` field from the returned data as a parameter for action 2, triggering action 2's execution. After action 2 successfully calls the list query interface, it passes the returned `data.list` data to action 3, completing the table data source update. Finally, action 4 is executed, displaying a success message pop-up, completing the entire action chain. If any action fails (e.g., an interface error or data parsing exception), the engine immediately triggers the failure handling strategy configured for that action, displays an error message, and terminates the action chain; subsequent actions will not be executed. Furthermore, the entire execution process of all actions is recorded by the platform monitoring system, including action execution time, parameter information, execution results (success / failure), reasons for failure, and related components, forming a complete operation log. This provides data support for subsequent problem tracing, performance optimization, and business process analysis. This extended capability is achieved solely by enhancing the orchestration and control logic of the action execution engine, without affecting the core mechanisms of original component interaction, data flow, and multi-terminal adaptation, forming a complete technical closed loop with the aforementioned embodiments.

[0092] This embodiment demonstrates that the communication mechanism of this embodiment not only supports simple "event-action" linkage, but also supports complex action chain orchestration, which can adapt to various complex business linkage scenarios and meet the actual needs of the visualization building platform.

Claims

1. An event-driven visual component linkage method, characterized in that, The method includes the following steps: S101. In the visual building platform, set the configurable events and data binding rules supported by each source component, and generate the source component event structure E101 and the component-level event control parameter set K101. The source component represents the rules for component rendering and configuration; The components include: basic components, multimedia components, form components, data display components, container components, and image components; S102. Based on E101 and K101, complete the rule configuration, obtain the configuration record set R101, store it in the component instance set C104, and create a global variable pool G101 based on E101; S103. Generate an action mapping table based on R101 and G101; When the central event dispatcher detects that any component has triggered an event, the central event dispatcher queries the action mapping table based on the component that triggered the event and generates an event dispatch set E103. S104. Execute the corresponding action according to E103, obtain the action execution result set A104 and store it in the component instance set C104 to obtain the updated C104, and update G101 according to A104; S105. Based on the updated G101, responsively update the visualization components in the visualization platform, complete the interface update, and generate view update record V105.

2. The event-driven visualization component linkage method according to claim 1, characterized in that, The source component event structure E101 includes: variable rules, trigger event types, targetable objects, and executable target action types; Variable rules specify the number of variables that each component can bind to, the meaning of the variables, and restrictions on the variable value types; Trigger event type indicates the type of interactive events that can trigger the component; The target object can be targeted, representing the target component that the triggered component can pass on to; The executable target action type indicates the specific response action type that can be executed on the target object after the component is triggered; The component-level event control parameter set K101 includes: event triggering condition templates, action parameter specifications, and variable referencing rules.

3. The event-driven visualization component linkage method according to claim 2, characterized in that, The rule configuration process is as follows: create a binding rule, select the target component and action based on E101, and then configure the action parameters according to K101; Binding rules: Each component can create several binding rules.

4. The event-driven visualization component linkage method according to claim 3, characterized in that, The configuration record set R101 includes: component type identifier, trigger event types supported by the component, target action type, and action configuration items containing templated parameters; The templated parameters are stored in the action configuration item as variable placeholders.

5. The event-driven visualization component linkage method according to claim 4, characterized in that, The process of creating the global variable pool G101 is as follows: Based on the variable rules in E101, a variable binding region is generated. Within the variable binding region, custom variables and their values ​​are set for any component to obtain a dependency graph.

6. The event-driven visualization component linkage method according to claim 5, characterized in that, The action mapping table includes: several variables, several components bound to each variable, and configuration records corresponding to each component.

7. The event-driven visualization component linkage method according to claim 6, characterized in that, The specific actions to be performed according to E103 are as follows: according to E103, the actions are scheduled, the execution context is prepared, the variable placeholders are dynamically resolved, the component data is updated, and the results are fed back in sequence. The process of updating G101 according to A104 is as follows: based on the action execution result, push the triggered component corresponding to the action execution result in reverse, and then update the value of the variable corresponding to the triggered component in G101 according to the action execution result.

8. The event-driven visualization component linkage method according to claim 7, characterized in that, The specific steps of updating the visualization components in the visualization platform in a responsive manner according to the updated G101 are as follows: synchronizing the visualized values ​​of the corresponding variables in the visualization components with the values ​​of the corresponding variables in the updated G101.

9. An event-driven visual component linkage system, characterized in that, The system is used to implement the method described in any one of claims 1-8, and the system includes: a component metadata manager, a visual binding configurator, an event router, an action execution engine, and a responsive data linkage unit; The component metadata manager is used to set the configurable events and data binding rules supported by each source component in the visual building platform, and to generate the source component event structure E101 and the component-level event control parameter set K101. The visual binding configurator completes rule configuration based on E101 and K101, obtains a configuration record set R101, stores it in the component instance set C104, and creates a global variable pool G101 based on E101; The event router generates an action mapping table based on R101 and G101; When the central event dispatcher detects a trigger event in any component, it queries the action mapping table based on the component that triggered the event and generates the event dispatch set E103. The action execution engine executes the corresponding action according to E103, obtains the action execution result set A104 and stores it in the component instance set C104, obtains the updated C104, and updates G101 according to A104; The responsive data linkage unit updates the visualization components in the visualization platform in a responsive manner based on the updated G101, completes the interface update, and generates view update record V105.

Images