Pluggable interactive drive architecture-based graphic editing system and method

Abstract

The invention discloses a graphic editing system and method based on a pluggable interaction driving framework, and belongs to the technical field of computer application. The system comprises a driver manager module used for maintaining a driver registry and managing the life cycle of an interactive driver; the shared service context module is used for providing singleton services such as a graphic service, an event service, a cursor service and a selection service; a plurality of interaction driving modules, each of which packages a graphic interaction behavior and realizes a uniform driving interface; and the graphic data model module adopts an immutable data mode. According to the method, interaction logic is modularized and pluggable and is decoupled from core business logic, so that the technical problems that a traditional graphic editing system is rigid in architecture, difficult to expand and maintain and serious in interaction behavior coupling are solved, and the expandability, maintainability, development efficiency and flexibility during operation of the system are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of computer application technology, specifically to a graphical editing system and method based on a pluggable interactive driving architecture, and particularly to a graphical editing system and method based on a pluggable interactive driving architecture for low-code / no-code platforms or visual design tools. Background Technology

[0002] With the increasing popularity of visual design and no-code development, graphical editing tools have become an indispensable infrastructure for enterprise application building, UI / UX design, and flowchart drawing. These tools allow users to create and edit complex graphical elements directly on the canvas through intuitive drag-and-drop, connecting, and zooming interactions.

[0003] Currently, mainstream graphical editing tools typically adopt the following architecture schemes when handling user interaction logic: one is a hard-coded scheme based on a single event handler, where all interaction logic is centrally written in a large event processing center and distributed through complex condition judgments; the other is a component-based scheme based on inheritance, where interactive behavior is abstracted into a base class and specific interactions are implemented through subclasses, and the interaction mode is changed by switching the currently active tool.

[0004] The inventors discovered through research that some graphics processing technologies also involve extension or plug-in mechanisms. For example, patent application CN201110039113.9 discloses a web-based graphical editing framework for business processes based on Flex technology, which supports the extension of primitive, view, and attribute editing functions through a plug-in mechanism. However, this solution mainly focuses on the static extension of editing functions (such as adding primitive types and extending attribute dialog boxes), and its plug-in mechanism does not delve into the modular encapsulation and dynamic scheduling management of the core interactive behaviors (such as drag and drop, selection event streams).

[0005] It is evident that the existing technical solutions, including the aforementioned patent applications, have significant drawbacks: 1) System rigidity and high expansion and maintenance costs: Adding new interactive functions requires direct modification of the core event handler, violating the open / closed principle, easily introducing errors, and resulting in slow iteration. 2) Severe coupling of interactive logic and poor reusability: Multiple interactive logics are bundled together, state sharing is chaotic, and complex coordination code is required when combining or disabling specific interactions. 3) Runtime behavior cannot be dynamically adjusted: Interactive behavior is fixed at compile time, and it is impossible to dynamically load, unload, or replace interactive modules based on user roles, editing modes, etc., resulting in insufficient flexibility. 4) Mixing of core business logic and interactive control logic: This leads to high data consistency risks and makes unit testing difficult, resulting in poor system robustness.

[0006] The root cause of the above problems lies in the failure to implement inversion of control in the architecture design, the lack of a unified lifecycle management mechanism for interactive modules, and the failure to effectively abstract and share the interactive context (such as canvas state, keyboard state, and selected element). Summary of the Invention

[0007] To address the problems of rigid architecture, coupled interaction logic, and difficulty in expansion and dynamic adjustment in existing graphical editing systems, this invention provides a graphical editing system and method based on a pluggable interactive driving architecture.

[0008] To achieve the above-mentioned objectives of this invention, the following technical solution is proposed: In a first aspect, the present invention provides a graphical editing system based on a pluggable interactive driving architecture, comprising: The driver manager is used to maintain a driver registry, which stores the mapping relationship between the identifiers and constructors of interactive driver modules, and is responsible for the lifecycle management of instantiation, activation, removal and re-insertion of interactive driver modules. Shared service context, including at least one of graphics service, event service, cursor service and selection service, is used to provide a shared state management and communication interface for the system core and various interactive driving modules; Multiple interactive driving modules, each implementing a predefined driving interface to encapsulate a specific graphical interactive behavior logic, and registering an event listener with the canvas container of the graphical user interface when activated. The graphics data model module is used to store and manage graphics editing data in an immutable data model. The interaction-driven module is configured to: query the current system state in the shared service context before responding to user interaction events captured by the canvas container, and autonomously decide whether to respond to the event based on built-in logic, thereby achieving decentralized scheduling with state awareness.

[0009] The graphic editing system of the present invention further includes the following auxiliary mechanisms to enhance the system's concurrent processing capability, operating efficiency, and adaptability to multiple scenarios: Conflict arbitration mechanism: Add a conflict arbitration service to the shared service context to arbitrate when multiple interaction-driven modules have conflicting responses to the same user interaction event, based on a preset priority strategy, mutual exclusion strategy, or cooperation strategy. Event distribution optimization mechanism: Improve event distribution efficiency and status query performance through event type pre-filtering and driver state caching; State persistence mechanism: The interactive driver module supports state serialization and recovery interfaces. The driver manager saves and restores the driver state during hot-plugging and supports editing continuity across sessions. Multi-instance isolation mechanism: Shared service context supports multi-instance isolation, with each instance having an independent copy of the service context, avoiding state pollution and supporting scenarios where multiple tabs and multiple projects can be edited in parallel.

[0010] As a preferred embodiment of this application, during system initialization, the driver manager instantiates the required interactive driver modules from the driver registry according to the configuration, and injects the shared service context into each interactive driver module instance.

[0011] As a preferred embodiment of this application, the event service provides a publish / subscribe mechanism for publishing data change events after the state of the graphical data model module is updated, and for indirect communication and collaboration between various interactive driving modules.

[0012] As a preferred embodiment of this application, the driver manager provides a hot-plug management interface, including a plug-out interface and a re-plug interface; the plug-out interface is used to move a specified interactive driver module from an active state to an inactive state and deactivate its event listener; the re-plug interface is used to reactivate a specified inactive interactive driver module and register its event listener.

[0013] As a preferred embodiment of this application, the graphics data model module makes its state observable through a reactive programming framework. When the graphics service modifies the data and generates a new model instance, the view components that depend on the model are automatically re-rendered.

[0014] Secondly, the present invention provides a graphical editing method based on a pluggable interactive driving architecture, applied to the graphical editing system described in the first aspect, the method comprising: System initialization and driver registration steps: Initialize the driver manager and shared service context, and instantiate and activate multiple interactive driver modules according to the configuration; The steps for capturing and driving interactive events are as follows: The canvas container captures user interactive events and distributes them to the registered interactive driving modules; each interactive driving module queries the system status in the shared service context and decides independently whether and how to respond. Interaction-driven collaborative work and state synchronization steps: The driver module responding to user interaction events modifies the system state by calling services in the shared service context; after completing the state modification, the service publishes the change event through the event service; The steps for updating and rendering graphics data are as follows: The graphics service updates the graphics data model in an immutable data model and replaces the old model instance; the view components that depend on the model are re-rendered responsively. Interactive driver dynamic hot-plug management steps: In response to external commands, the driver manager performs the operation of unplugging or replugging the specified interactive driver module to dynamically adjust the set of available interactive capabilities at runtime.

[0015] As a preferred embodiment of this application, in the step of capturing and driving the interactive event, each interactive driving module decides autonomously whether to process the current event based on its built-in logic and at least one of the current cursor state, keyboard modifier key state, and currently selected element state.

[0016] As a preferred embodiment of this application, in the interaction-driven collaborative work and state synchronization step, the event service notifies other interaction-driven modules and / or view components that have subscribed to the data change event, triggering the corresponding collaborative logic or view update.

[0017] Thirdly, the present invention provides an electronic device including a processor, a memory, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method described above.

[0018] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0019] Compared with the prior art, the present invention has the following beneficial effects: This invention encapsulates interactive behaviors into independent, pluggable driver modules and decouples them from the system core, so that adding new functions does not require modification of the core code, significantly reducing expansion and maintenance costs, and achieving loose coupling and high scalability at the architectural level.

[0020] This invention employs a "state-aware, self-decision-making" model, where each driver autonomously determines its behavior based on a shared context, elegantly resolving multi-interaction parallel conflicts, constructing a dynamic and collaborative intelligent scheduling mechanism, and achieving decentralized and efficient scheduling.

[0021] This invention supports flexible customization of runtime behavior through a hot-swappable management mechanism: interactive drivers can be dynamically loaded or unloaded at runtime according to the scenario, which greatly improves the system's adaptability and customization capabilities.

[0022] This invention supports parallel development and independent unit testing through modular drivers. The clear architectural boundaries reduce code complexity and improve development efficiency and system robustness.

[0023] This invention, through its open architecture, can easily integrate new interaction paradigms (such as gestures and voice) and supports third-party development of customized plugins, enhancing the long-term vitality and competitiveness of products and laying the foundation for technological evolution and ecosystem expansion.

[0024] Conflict arbitration mechanism: The conflict arbitration service elegantly handles conflicts in multi-driven concurrent responses, improving system stability and user experience in complex interaction scenarios; State persistence support: The driver state serialization and recovery mechanism ensures the continuity of hot-plugging and the persistence of user preferences, and supports cross-session editing; Multi-instance isolation capability: The system supports multiple completely isolated editing instances running in parallel, adapting to complex application scenarios such as multi-tab and multi-project collaboration; Performance optimization mechanisms: Optimization techniques such as event pre-filtering, state caching, and lazy querying significantly improve system response speed and resource utilization. Attached Figure Description

[0025] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 This is a schematic diagram of the structure of a graphics editing system based on a pluggable interactive driver architecture according to an embodiment of the present invention; Figure 2 This is a flowchart of the registration and system initialization process of the interaction driver in an embodiment of the present invention.

[0027] Figure 3 This is a flowchart of the capture and drive scheduling of interactive events in an embodiment of the present invention.

[0028] Figure 4 This is a flowchart illustrating the collaborative work and data update process between interactive drivers in this embodiment of the invention.

[0029] Figure 5 This is a flowchart of the interactively driven dynamic hot-plug management process in an embodiment of the present invention. Detailed Implementation

[0030] The technical solution of the present invention will be clearly and completely described below with reference to the embodiments. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present invention. It should be noted that relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations.

[0031] The core of this invention lies in constructing a graphical editing system centered on a driver manager, which abstracts various graphical interaction behaviors into independently loadable and unloadable driver modules through a unified driver interface and shared service context. This system achieves complete decoupling between interaction logic and core business logic. The embodiments of this invention will be further described in detail below with reference to the accompanying drawings.

[0032] Example 1 See Figure 1 This embodiment provides a graphical editing system based on a pluggable interactive driving architecture, which mainly includes the following five layers of functional modules. Each module works together to achieve the decoupling and dynamic management of interactive logic.

[0033] 1. User Interface Layer: This layer contains the Canvas component, responsible for receiving raw input events (mouse, keyboard) and rendering the final graphics. This layer handles direct user interaction and serves as the system's front-end presentation and input capture entry point. Its core is a Canvas component, typically implemented using HTML5 Canvas, SVG, or WebGL technologies. This Canvas component handles the rendering of all graphical elements and directly listens for raw DOM input events, including mouse events (mousedown, mousemove, mouseup), keyboard events (keydown, keyup), and touch events (touchstart, touchmove, touchend). When an event occurs, the Canvas component does not perform complex logic processing; it simply acts as an event dispatcher, passing standardized event objects (containing coordinates, key states, target element information, etc.) to lower-level modules. View components (such as toolbars and property panels) also belong to this layer; they use reactive mechanisms to listen for changes in the data model layer and update the UI accordingly.

[0034] The canvas container also maintains an event type-driver registry, recording the event types registered and listened to by each interactive driver module. When distributing events, the canvas container first queries this registry, distributing events only to driver modules that have registered the corresponding event types, avoiding invalid broadcasts and improving event distribution efficiency.

[0035] 2. Driver Management Layer: This is the driver manager (such as PluginService), which maintains the driver registry and is responsible for the lifecycle management of interactive driver modules, including instantiation, attachment, unplugging, and replugging. The driver registry stores the mapping between the identifiers and constructors of interactive driver modules.

[0036] The driver management layer is the "control center" of the system, with the driver manager at its core. In the code, this can be represented by classes such as PluginService or DriverRegistryService. The specific implementation process of the driver management layer is as follows: Driver Registry: Internally, the manager maintains a key-value pair registry (e.g., a Map object used in JavaScript). The key is a unique identifier for the interactive driver (e.g., "drag", "selection"), and the value is the corresponding driver's class constructor or factory function. At system startup, all available drivers can be registered in this table through static configuration (e.g., JSON files) or dynamic scanning (e.g., following specific directory conventions).

[0037] Lifecycle management mainly includes the following operations: Instantiation and Activation (attach): Based on the current application mode configuration (such as "Design Mode" or "Preview Mode"), the driver manager retrieves the constructor of the required driver from the registry and instantiates it using the `new` keyword. After instantiation, the driver instance's `attach(context)` method is immediately called, passing the shared service context as a parameter to complete dependency injection. Subsequently, within its `attach` method, the driver registers the required event listeners on the canvas container.

[0038] Unplug: The driver manager provides the `unplug(driverId)` method, which accepts the driver identifier as a parameter. When this method is called, the driver manager finds the corresponding driver instance based on the `driverId` and calls its `detach()` method. Internally, the `detach()` method removes all event listeners registered by the driver on the canvas and may perform necessary state cleanup. Subsequently, the manager transfers the instance from the "active driver pool" to the "inactive driver pool" for storage, maintaining a reference to it for future reactivation.

[0039] Replug: The driver manager provides the replug(driverId) method. This method retrieves the corresponding driver instance from the "inactive driver pool," calls its attach(context) method again to re-register the event listener with the canvas and restore its working state, and then moves the instance back to the "active driver pool."

[0040] Driver state persistence management: To support hot-plugging and state restoration across sessions, the interaction driver module needs to implement the state serialization interface (including the `serializeState()` and `restoreState(stateData)` methods). When a driver is unplugged, the driver manager automatically calls `serializeState()` to save the serialized state data (usually in JSON format) to an inactive driver pool or persistent storage; when the driver is replugged, `restoreState()` is called to restore the state. This mechanism ensures that the driver maintains user preferences, temporary variables, and other runtime states during hot-plugging, achieving a seamless editing experience.

[0041] Example: In the flowchart editor, during initialization, the driver manager loads and activates drivers such as "drag," "selection," and "connection" based on the configuration. When the user switches to "demo mode," the system calls `unplug("drag")` and `unplug("connection")` to disable the graphical editing functions, retaining only the "selection" (for highlighting) and "panzoom" (canvas zooming and panning) drivers, thus enabling smooth and dynamic switching between different modes.

[0042] 3. Interaction Driver Layer: This layer contains multiple interaction driver modules that implement a unified interface (such as defining methods like `activate`, `deactivate`, and `handleEvent`). Examples include drag-and-drop driver (DragDriver), selection driver (SelectionDriver), canvas panning driver (PanningDriver), and keyboard driver (KeyboardDriver). Each interaction driver module implements a predefined driver interface to encapsulate a specific graphical interaction behavior logic and registers an event listener with the canvas container of the graphical user interface upon activation.

[0043] In one embodiment of the present invention, the interaction driving module is configured to: query the current system state in the shared service context before responding to the user interaction event captured by the canvas container, and autonomously decide whether to respond to the event according to the built-in logic, thereby realizing decentralized scheduling with state awareness.

[0044] The interaction driver layer, composed of a series of independent interaction driver modules, is the core of this invention's "pluggable" and "decoupled" functionality. It includes: 3.1. Unified Interface Specification: Each interactive driver module must conform to a predefined driver interface, which defines the contract between the driver and the driver manager, and between the driver and the system kernel. Typical methods include: get id() (get identifier()): Returns a string as an identifier that represents the unique identity of the driver.

[0045] attach(context) (Activate(context)): Called when the driver is loaded by the manager and ready to be used. This method takes the system's shared service context as a parameter. Inside this method, the driver should use this context to initialize itself and register its required event listeners with the canvas container of the graphical user interface.

[0046] detach() (disable()): Called when the driver is disabled or unplugged by the manager. Inside this method, the driver should remove all event listeners it has registered on the canvas and perform necessary internal state cleanup to ensure no resource leaks.

[0047] A series of specific event handling methods, such as onMouseDown(event, context), onMouseMove(event, context), onKeyDown(event, context), etc.

[0048] To support state persistence, the driver interface also includes: serializeState(): Returns the current driver's state data object; restoreState(stateData): Restores the driver state based on the passed-in state data.

[0049] 3.2. State Awareness and Self-Decision-Making Mechanism: Decentralized and intelligent interactive scheduling is achieved through the "state awareness" and "autonomous decision-making" capabilities of the interactive driving module. Specifically, this includes: 1) Event Triggering and State Query: When a user interacts with the canvas (e.g., clicks the mouse (MouseDown), the canvas container distributes standardized event objects to all drivers registered for that type of event. When the corresponding event handling method of each driver is called, its primary action is not to directly handle the event, but to actively query the current global system state through the passed-in shared service context. For example, a "DragDriver" handling the mouse down event (onMouseDown) will simultaneously query: which nodes are currently selected (via the selection service selectionService), and query the keyboard state service or the global state context.keyboardState.isKeyPressed('Space') to check if the space bar is being pressed.

[0050] 2) Built-in Logic and Autonomous Decision-Making: Based on the real-time system status queried, each driver autonomously determines whether and how to respond to the event according to its built-in, independent business logic. The decision-making logic is completely encapsulated within each driver. For example, the decision-making logic of the "drag and drop driver" mentioned above can be described as follows: "If the mouse is pressed on a graphical node, and the node is selected, and the auxiliary function key (such as the space bar) is not activated, then this operation is determined to be a valid drag-and-drop initiation action, and this driver will take over the subsequent interaction process; otherwise, this driver will ignore this event." After deciding to respond, the driver can immediately change the mouse cursor style through the cursor service to provide visual feedback.

[0051] 3) Decentralized Collaboration: This mechanism allows multiple drivers to make independent judgments on the same event in parallel based on a global state, eliminating the need for a centralized coordinator to handle complex interaction priorities and conflicts. For example, when the spacebar is pressed, the "selection driver" will automatically ignore the mouse event based on the state judgment, while the "canvas panning driver" will be activated based on the same state judgment. This design greatly simplifies system complexity and improves scheduling flexibility and reliability.

[0052] 3.3 Optimization of Event Distribution and Status Query: To improve system performance, the following optimization mechanisms are also introduced: Event type pre-filtering: The canvas container maintains an event type-driver registry, and when dispatching events, it only broadcasts to drivers that have registered the event type, avoiding invalid dispatches.

[0053] State Attention Declaration: When activated, the driver can declare the state types it is interested in (such as "keyboard modifier key state" or "selected element state"), and the state caching service will optimize state push accordingly.

[0054] Lazy query strategy: For frequently changing states (such as cursor position), the driver can use lazy query, querying only when necessary to reduce performance overhead.

[0055] Taking SelectionDriver as an example, the complete workflow of state awareness and self-decision-making mechanism is as follows: When attaching, register mousedown, mousemove, and mouseup listeners with the canvas.

[0056] When `onMouseDown` is active, check if the Ctrl or Shift key (used for appending selections) is currently pressed, and if the cursor starts in a blank area. If so, record the starting point and begin drawing the selection box.

[0057] When onMouseMove is called, the selection area is calculated, and the nodes within the selection area are queried using context.graphService.getNodesInRect(rect), and the selection state is updated by calling context.selectionService.setSelection(nodes).

[0058] When onMouseUp is executed, the selection is completed, and a selection change event is published through the event service context.eventService.Publish(newSelection ChangedEvent (...)). This event will notify all other modules in the system that have subscribed to the event (for example, the property panel driver will update the displayed properties accordingly, and the wiring driver may highlight related connections), thereby achieving loose coupling and collaboration between modules.

[0059] 4. Shared Service Layer: Provides singleton services for the core and drivers, forming a shared service context. This layer provides shared state management and communication interfaces for the system core and various interactive driver modules; it includes: The GraphService manages the creation, deletion, modification, and querying of graph data models (graphs, nodes, and connections). All data modifications are performed through this service. Specifically, the GraphService internally holds an instance of the current application's graph data model (from the data model layer). It provides a series of methods for manipulating the graph data model (creating, deleting, modifying, and querying graphs, nodes, and connections), such as addNode(nodeData), removeNode(nodeId), and updateNode(nodeId, newProperties). These methods adhere to the immutability principle when performing modifications. For example, updateNode creates a completely new node object and graph model instance based on the current model and the new passed-in properties, then replaces the old instance held internally by the service with the new instance. After the replacement is complete, it automatically calls the event service to publish a GraphUpdatedEvent.

[0060] EventService: Provides a Pub / Sub mechanism for event publishing and subscription between modules, offering the `subscribe(eventType, callback)` and `publish(event)` methods. When the graph service publishes a `GraphUpdatedEvent`, or the selection service publishes a `SelectionChangedEvent`, callback functions of any drivers or components that have subscribed to these events (such as a "history driver" or "auto-save driver") are asynchronously triggered, thus achieving loosely coupled communication.

[0061] CursorService: Manages the cursor state and type (such as default arrow, moving hand, text input) for the application. Drivers can request to change the cursor using methods such as setCursor('grab'). Internally, the service handles conflicts; for example, when multiple drivers request different cursors simultaneously, it can determine the final cursor to be displayed based on priority.

[0062] SelectionService manages the set of selected states for nodes in the canvas. It provides methods such as setSelection(ids), addToSelection(id), and clearSelection(). Any modification to the selected set will be published as a SelectionChangedEvent via the event service.

[0063] Conflict Arbitration Service: This service provides an arbitration mechanism when multiple interactive driver modules conflict in their responses to the same user interaction event. It maintains a driver priority table and a mutual exclusion rule table, supporting the following arbitration strategies: Priority strategy: Select the highest priority driver to respond based on driver priority; Mutual exclusion strategy: Select a unique driver based on predefined mutual exclusion rules (such as "drag and drop" and "selection by box" being mutually exclusive); Cooperative strategy: Allows multiple drivers to work together, but specifies the primary response driver.

[0064] The arbitration result is communicated to relevant drivers via an event service notification.

[0065] State Cache Service: To improve status query efficiency, the service caches the status types that each driver is interested in (such as keyboard status and selected status), and only pushes updates to the drivers that are interested in the status when the status changes, reducing redundant queries. The service also supports a lazy query mechanism to throttle frequently changing statuses.

[0066] Multi-instance isolation support: Shared service contexts support a multi-instance isolation mechanism, allowing multiple independent graphics editing instances to run simultaneously within the same application. Each instance has its own independent copy of the service context, including independent graphics services, event services, selection services, etc. When instantiating a driver, the driver manager injects the corresponding context instance into the driver, thereby achieving state isolation and parallel operation between instances.

[0067] The shared service layer provides a centralized set of services accessible to all modules, forming the system's "shared context." These services are singletons and are provided to the driver manager and individual drivers via dependency injection.

[0068] 5. Data Model Layer: This layer contains the graph data model module, used to store and manage graph editing data in an immutable data model. Specifically, it includes core data entities such as the GraphModel and NodeModel. These models employ an immutable data model; any modification operation (such as setPosition) returns a completely new instance containing the new state. Simultaneously, reactive state management libraries (such as MobX and Vue reactive) make the model state observable.

[0069] The embodiments of the present invention define the core data structure of the system through a data model layer and specify its operational paradigm, specifically including: Immutable data models: Classes such as NodeModel and GraphModel are designed to be immutable. For example, NodeModel has a setPosition(x, y) method, which does not modify the x and y properties of the current instance, but returns a brand new NodeModel instance with the new coordinates and the same properties as the others.

[0070] Reactive state management: The entire graph model is wrapped as an observable object. This is implemented using technologies such as MobX, Vue's reactive system, or Redux. When the graph service replaces the old model instance with a new one, because the entire model is observable, all computed properties and observers that depend on this model will be automatically and efficiently recomputed or executed.

[0071] Example: A React component for displaying node coordinates, wrapped in an observer, reads node.position.x. When the node's position is modified by the DragDriver and updated via the graph service, because the node is observable, this React component automatically triggers a re-render to display the new coordinates. The entire process requires no manual handling of data synchronization to the view by the developer.

[0072] In one embodiment of the present invention, during system initialization, the driver manager instantiates the required interactive driver modules from the driver registry according to the configuration and injects the shared service context into each interactive driver module instance.

[0073] In one embodiment of the present invention, the event service provides a publish / subscribe mechanism for publishing data change events after the state of the graphical data model module is updated, and for indirect communication and collaboration between the various interactive driving modules.

[0074] In one embodiment of the present invention, the driver manager provides a hot-plug management interface, including a pull-out interface and a re-insertion interface; the pull-out interface is used to move a specified interactive driver module from an active state to an inactive state and deactivate its event listener; the re-insertion interface is used to reactivate a specified inactive interactive driver module and register its event listener.

[0075] In one embodiment of the present invention, the graphics data model module makes its state observable through a reactive programming framework. When the graphics service modifies the data and generates a new model instance, the view components that depend on the model are automatically re-rendered.

[0076] Taking drag-and-drop nodes as an example, the inter-module workflow of a graphical editing system based on a pluggable interactive driver architecture provided in this embodiment is as follows: The user presses the mouse on a node on the canvas (the user interface layer captures the event).

[0077] The event is distributed to all drivers that have registered mousedown, including DragDriver (which acts as a router in the driver management layer).

[0078] The `DragDriver.onMouseDown(event, context)` method is called. It queries `context.selectionService` to confirm that the node is selected, and queries `context.keyboardState` to confirm that no special key is pressed, and then decides to respond (the interaction driver layer makes its own decision).

[0079] If the selection driver also decides to respond to the same event at this time, the conflict arbitration service will be triggered, and the event handling right will be assigned to the drag-and-drop driver according to the preset strategy (such as drag and drop having higher priority than selection).

[0080] DragDriver records the starting position and calculates the displacement in onMouseMove, but it does not directly modify the node data.

[0081] DragDriver calls context.graphService.updateNode(nodeId, {x: newX, y:newY}) (shared service layer).

[0082] GraphService performs an immutable update, generates a new model, and calls context.eventService.publish(graph UpdatedEvent).

[0083] The event service will notify all subscribers of the graphUpdatedEvent (e.g., a view component used to display node positions).

[0084] As an observer of the data model layer, the view component detects changes in the model, automatically re-renders, and moves nodes on the canvas.

[0085] At the same time, another "wire auto-redraw driver" that subscribes to graphUpdatedEvent is also triggered, recalculating and drawing the wires connected to the dragged node.

[0086] When the state caching service detects an update to the graph data, it pushes an update notification to all drivers that are interested in the "node position" state, reducing the overhead of subsequent queries.

[0087] The beneficial effects of the graphical editing system based on a pluggable interactive driver architecture provided in this embodiment are as follows: This approach fundamentally solves the problem of rigid system architecture, achieving high scalability and maintainability. By decoupling core interactive behaviors such as dragging, selection, and panning from the system's core code and encapsulating them into independent "driver modules" that implement a unified interface, and communicating with the system core through an explicit "shared service context," the interaction logic and business logic are completely decoupled. This design allows for the development of new interactive functions by simply developing new driver modules according to the interface specifications and completing their registration, without modifying the system's core code. This significantly reduces the complexity of feature expansion and the risk of introducing errors, adheres to the open / closed principle, and makes the system easy to maintain and evolve in the long term, effectively solving the problems of slow feature iteration and heavy technical debt mentioned in the background technology.

[0088] An intelligent and dynamic interaction scheduling mechanism has been constructed, greatly improving user experience and system flexibility. The "state-aware, self-determining driven scheduling" mode proposed in this invention is a major innovation. Before responding to an event, each interaction driver module actively queries the global state (such as key presses, selection sets, and cursor positions) and makes autonomous decisions based on built-in logic. This decentralized mechanism elegantly resolves conflicts when multiple interactions are running in parallel (for example, when the spacebar is pressed, the selection driver automatically yields to the canvas translation driver), eliminating the need for a complex central coordinator. Combined with the "hot-plug" (unplug / replug) function provided by the driver manager, the system can dynamically adjust the available set of interaction capabilities at runtime according to different scenarios (such as edit mode and preview mode), achieving unprecedented runtime flexibility and meeting the dynamic customization needs of complex applications for interactive behavior.

[0089] This architecture significantly improves development efficiency and code quality, supporting highly efficient team collaboration. It enables "modular development" of interactive functions. Different interaction drivers can be developed, tested, and deployed independently, allowing development teams to work in parallel without interference, and finally integrate them through a driver manager. Because driver modules have single responsibilities, clear interfaces, and communicate indirectly through services, unit testing of individual drivers becomes simple and easy, greatly improving code testability, reducing the difficulty and cost of integration and regression testing, and providing strong support for continuous integration and continuous delivery.

[0090] This enhances the system's robustness and testability. Strict layering, particularly the unified control over data modifications and the application of an immutable data model in the shared service layer, ensures the consistency of core data. Interaction-driven mechanisms do not directly manipulate the data model but instead use service calls, making data flow clear and traceable. Event-driven communication mechanisms (through event services) further reduce direct dependencies between modules, making the impact of system failures controllable. Clear architectural boundaries and loose coupling make the system more robust overall, easier to debug, and easier to locate problems.

[0091] This architecture lays a solid foundation for technological evolution and platform ecosystem development, demonstrating significant application value. Its open, pluggable architecture allows the graphical editing platform to easily adapt to future interactive technology advancements. Whether introducing new paradigms such as touch gestures, voice control, or AI-assisted operation, these can be seamlessly integrated simply by implementing them as new driver modules, without requiring large-scale reconstruction of the existing system. Simultaneously, this architecture naturally supports third-party developers contributing customized interactive plugins to the platform, greatly enriching its functional ecosystem and transforming it from a closed tool into an open interactive platform. This not only accelerates product innovation and iteration and reduces long-term R&D costs but also significantly enhances the product's market competitiveness and user stickiness.

[0092] Furthermore, this system ensures stable response in multi-drive concurrent scenarios through a conflict arbitration mechanism, achieves a seamless hot-swappable experience through state persistence support, adapts to complex multi-task editing environments through multi-instance isolation capabilities, and improves the overall efficiency of the system through a performance optimization mechanism, forming a complete solution from core architecture to auxiliary optimization.

[0093] In another optional embodiment of the present invention, the system of Embodiment 1 is used in a multi-instance isolated editing scenario: This system supports a multi-instance isolation mechanism, making it suitable for scenarios involving multiple tabs and parallel editing of multiple projects. Each editing instance has completely independent: Driver Manager instance; Shared service context copy; Graphical data model; Interactive-driven instance set; The states of each instance are completely isolated and do not interfere with each other. Users can edit multiple flowcharts, UI designs, etc., simultaneously within the same application. The system maintains an independent editing history, user preferences, and plugin configurations for each instance.

[0094] Implementation: The system's top-level container maintains multiple "edit sessions," each corresponding to an independent system instance. The driver manager receives the session identifier during initialization, ensuring that service injection and state storage are bound to the session.

[0095] Example 2 This embodiment provides a graphical editing method based on a pluggable interactive driver architecture, applied to the graphical editing system described in Embodiment 1. The method includes the following steps: S1. System Initialization and Driver Registration Steps: Initialize the driver manager and shared service context; instantiate and activate multiple interactive driver modules according to the configuration; such as... Figure 2 As shown, the system initialization and driver registration steps specifically include: When the system starts, it first performs initialization operations. These include: creating and initializing a shared service context, which contains singleton services such as graphics services, event services, cursor services, and selection services; and initializing the driver manager, which loads and maintains a driver registry that stores the mapping between identifiers of available interactive drivers and their corresponding class constructors.

[0096] Subsequently, the driver manager, based on the current application scenario or mode configuration (e.g., reading a configuration file), determines the list of interactive drivers to be activated from the driver registry (such as "DragDriver", "SelectionDriver", and "PanningDriver"). According to this list, the driver manager instantiates each interactive driver module sequentially, injecting the initialized shared service context as a dependency parameter into each driver instance during instantiation. After instantiation, the driver manager calls the activation method of each driver instance. Within its activation method, the driver registers the event types it needs to listen to with the canvas container of the graphical user interface, thus completing the driver activation and readiness. At this point, the system is ready and enters a state awaiting user interaction.

[0097] During driver instantiation, if the system is configured in multi-instance mode, the driver manager will create an independent shared service context copy for each instance and ensure the correct binding between the driver instance and the context copy.

[0098] S2. Interaction Event Capture and Driving Scheduling Steps: The canvas container captures user interaction events and distributes them to registered interaction driving modules; each interaction driving module queries the system status in the shared service context and autonomously decides whether and how to respond. Further, in the interaction event capture and driving scheduling steps, each interaction driving module autonomously decides whether to process the current event based on its built-in logic and at least one of the queried current cursor state, keyboard modifier key state, and currently selected element state. For example... Figure 3 As shown, the specific steps for capturing and driving the scheduling of interactive events include: When a user interacts with the canvas using a mouse, keyboard, or touchscreen, the canvas component in the user interface layer captures the raw input events and encapsulates them into standardized interactive event objects.

[0099] The canvas component acts as an event dispatcher, broadcasting this event object simultaneously to all active interactive driver modules that have registered event listeners of this type on it. Each driver that receives the event notification, when its corresponding event handling method (such as handling a mouse press event) is triggered, first performs a state query operation: that is, it actively queries the current global system state through the injected shared service context. The queried state information may include, but is not limited to: the currently pressed keyboard modifier key (by querying the keyboard state service), the currently selected set of graphic elements (by querying the selection service), and the current mouse cursor style or position (by querying the cursor service), etc.

[0100] Based on the real-time system status queried, each driver, according to its internally encapsulated and independent business logic, autonomously makes decisions to determine whether and how it should respond to the current event. For example: The logic of selection-driven operation is as follows: if the space bar is not pressed and the mouse button is pressed in a blank area of ​​the canvas, then the selection operation should be started.

[0101] The logic for canvas translation is as follows: if the space bar is pressed, then it is determined that the canvas translation operation should start.

[0102] The logic of drag-and-drop is as follows: if the mouse is pressed on a graphical node, and the node is selected, and no specific auxiliary key is pressed, then it is determined that a drag-and-drop operation should begin.

[0103] If multiple drivers decide to respond to the same event simultaneously, the conflict arbitration step is initiated: the conflict arbitration service makes a ruling based on a preset strategy (priority, mutual exclusion, or coordination strategy), determines the unique or primary responding driver, and notifies the relevant drivers of the ruling result through the event service.

[0104] This invention constructs a decentralized intelligent scheduling mechanism through a model of "first querying the global state, then making autonomous decisions based on built-in logic." It enables multiple drivers to make collaborative or mutually exclusive response decisions to the same event in parallel, based on a unified context, thus elegantly resolving interaction conflicts without the need for a centralized and complex coordinator.

[0105] S3. Interaction-Driven Collaborative Work and State Synchronization Steps: The driver module responding to user interaction events modifies the system state by calling services in the shared service context; after completing the state modification, the service publishes a change event through the event service. Further, the event service notifies other interaction-driven modules and / or view components that have subscribed to the data change event, triggering corresponding collaborative logic or view updates. For example... Figure 4 As shown, the interaction-driven collaborative work and state synchronization steps specifically include: When a driver (such as a drag-and-drop driver) determines that core system data needs to be modified based on its decision logic, it does not directly access or manipulate the data model. Instead, it initiates a modification request by calling the corresponding service interface in the shared service context. For example, a drag-and-drop driver might call the update node method of the graphics service, passing in the target node identifier and the new position coordinates.

[0106] The graph service, acting as the core agent for data operations, receives this request. It performs the update operation according to the principle of immutable data: based on the current graph data model and the incoming new data, it generates a completely new data model instance containing the updated state, and then replaces the old model instance held internally with this new instance. After the data replacement is complete, the graph service immediately publishes a data change event (e.g., a node updated event) through the event service, which carries the relevant change information.

[0107] The event service acts as the system's message hub, responsible for notifying all other modules that have pre-subscribed to this type of state change event. These subscribers may include other interaction drivers (e.g., a "wire auto-redraw driver" subscribes to node update events to adjust wire paths after a node moves) and view components in the user interface layer. This publish-subscribe mechanism enables loosely coupled collaboration and state synchronization between drivers and between drivers and views.

[0108] After detecting a state change event, the state caching service updates its internal cache and pushes the cache update to all drivers that are interested in that state type, reducing the overhead of subsequent queries.

[0109] S4. Responsive Update and Rendering Steps for Graphical Data: The graphics service updates the graphical data model using an immutable data model and replaces the old model instance; view components that depend on this model are responsively re-rendered; specifically including: The data model layer employs reactive programming techniques, making the entire graph data model an observable object. When the graph service replaces an old instance with a new one, because the model is observable, any view components that depend on that data model (e.g., React components wrapped in the observer higher-order component, or Vue's reactive components) will automatically and efficiently detect the data change.

[0110] The aforementioned view component then triggers its re-rendering logic, generating and updating the user interface based on the latest data model, thus reflecting data changes on the screen in real time. The entire process is automatically managed by the responsive framework, eliminating the need for developers to write code to manually update the view, ensuring data and view consistency.

[0111] S5. Dynamic Hot-Swap Management Steps for Interactive Drivers: In response to external commands, the driver manager performs the operation of unplugging or replugging the specified interactive driver module to dynamically adjust the set of available interactive capabilities at runtime. The system supports dynamically adjusting its set of interactive capabilities at runtime, which is achieved through the hot-swap management interface provided by the driver manager, such as... Figure 5 As shown, the interactive-driven dynamic hot-plug management steps specifically include: When a specific interactive function needs to be temporarily disabled (for example, when a user switches from "Design Mode" to "Read-Only Preview Mode"), the system can send a command to the Driver Manager, calling its unplug method and passing in the identifier of the target driver (such as "DragDriver"). The Driver Manager then locates the corresponding driver instance and calls its disable method. In the disable method, the driver unregisters all event listeners on the canvas container and performs necessary state cleanup. Subsequently, the Driver Manager removes the instance from the "Active Driver Pool" and saves it in the "Inactive Driver Pool." After this, the interactive function corresponding to that driver is disabled in the system.

[0112] During the unplugging process, the driver manager calls the serializeState() method of the driver instance to serialize the driver state into a storable format (such as JSON) and save it to persistent storage to support subsequent state recovery.

[0113] Conversely, when the feature needs to be re-enabled, the system calls the driver manager's re-insertion method, passing in the same driver identifier. The driver manager retrieves the corresponding driver instance from the "inactive driver pool" and calls its activation method again. In the activation method, the driver re-registers event listeners with the canvas, and the manager moves it back to the "active driver pool," thus restoring the interactive functionality.

[0114] During the reinsertion process, the driver manager retrieves and deserializes the driver state from persistent storage, calls the restoreState(stateData) method of the driver instance to restore the state, and ensures that the driver is restored to the running state before it was unplugged.

[0115] Through this mechanism, the system can flexibly adapt to different application scenarios and user needs without restarting or modifying the core code.

[0116] Example 3 The present invention also provides an electronic device, including: a processor, a transmitting device, an input device, an output device, and a memory. The processor may be implemented using a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit, or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory may be implemented using a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM), and is used to store computer program code. The computer program code includes computer instructions. When the processor executes the computer instructions, the electronic device executes a method as described in any of the above possible implementation methods.

[0117] Example 4 The present invention also provides a computer-readable storage medium storing a computer program, the computer program including program instructions, which, when executed by a processor of an electronic device, cause the processor to perform a method as described in any of the above possible implementations.

[0118] In the description of this specification, the references to terms such as "an embodiment," "example," "specific example," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of the present invention. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples.

[0119] The above description is merely a specific embodiment of the present invention, enabling those skilled in the art to understand or implement the invention. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the invention. Therefore, the present invention is not to be limited to the embodiments shown herein, but is to be accorded the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A graphical editing system based on a pluggable interactive driving architecture, characterized in that, include: The driver manager is used to maintain a driver registry, which stores the mapping relationship between the identifiers and constructors of interactive driver modules, and is responsible for the lifecycle management of instantiation, activation, removal and re-insertion of interactive driver modules. Shared service context, including at least one of graphics service, event service, cursor service and selection service, is used to provide a shared state management and communication interface for the system core and various interactive driving modules; Multiple interactive driving modules, each implementing a predefined driving interface to encapsulate a specific graphical interactive behavior logic, and registering an event listener with the canvas container of the graphical user interface when activated. The graphics data model module is used to store and manage graphics editing data in an immutable data model. The interaction-driven module is configured to: query the current system state in the shared service context before responding to user interaction events captured by the canvas container, and autonomously decide whether to respond to the event based on built-in logic, thereby achieving decentralized scheduling with state awareness.

2. The system according to claim 1, characterized in that, During system initialization, the driver manager instantiates the required interactive driver modules from the driver registry according to the configuration and injects the shared service context into each interactive driver module instance.

3. The system according to claim 1, characterized in that, The event service provides a publish / subscribe mechanism for publishing data change events after the state of the graphical data model module is updated, and for indirect communication and collaboration between various interactive driving modules.

4. The system according to claim 1, characterized in that, The driver manager provides a hot-plug management interface, including a pull-out interface and a re-insertion interface; the pull-out interface is used to move a specified interactive driver module from an active state to an inactive state and deactivate its event listener; the re-insertion interface is used to reactivate a specified inactive interactive driver module and register its event listener.

5. The system according to any one of claims 1 to 4, characterized in that, The graphical data model module makes its state observable through a reactive programming framework. When the graphical service modifies the data and generates a new model instance, the view components that depend on the model are automatically re-rendered.

6. The system according to claim 1, characterized in that, The shared service context also includes a conflict arbitration service, which is used to adjudicate conflicts arising from responses to the same user interaction event by multiple interaction driving modules according to a preset arbitration strategy, and to notify the relevant driving modules of the adjudication result through the event service. The interactive driver module also implements a state serialization interface and a state recovery interface; the driver manager saves the serialized state when the driver is unplugged and restores the state when it is reinserted. The system supports multi-instance isolation, with each editing instance having an independent copy of the shared service context, a driver manager instance, and a graphical data model instance. The canvas container also maintains an event type-driver registry, broadcasting only to drivers that have registered the corresponding event type when distributing events.

7. A graphical editing method based on a pluggable interactive driving architecture, characterized in that, Applied to the graphics editing system as described in any one of claims 1 to 6, the method comprises: System initialization and driver registration steps: Initialize the driver manager and shared service context, and instantiate and activate multiple interactive driver modules according to the configuration; The steps for capturing and driving interactive events are as follows: The canvas container captures user interactive events and distributes them to the registered interactive driving modules; each interactive driving module queries the system status in the shared service context and decides independently whether and how to respond. Interaction-driven collaborative work and state synchronization steps: The driver module responding to user interaction events modifies the system state by calling services in the shared service context; after completing the state modification, the service publishes the change event through the event service; The steps for updating and rendering graphics data are as follows: The graphics service updates the graphics data model in an immutable data model and replaces the old model instance; the view components that depend on the model are re-rendered responsively. Interactive driver dynamic hot-plug management steps: In response to external commands, the driver manager performs the operation of unplugging or replugging the specified interactive driver module to dynamically adjust the set of available interactive capabilities at runtime.

8. The method according to claim 7, characterized in that, In the step of capturing and driving the interactive event, each interactive driving module decides whether to process the current event based on its built-in logic and at least one of the current cursor state, keyboard modifier key state, and current selected element state.

9. The method according to claim 7, characterized in that, In the interactive collaborative work and state synchronization steps, the event service notifies other interactive driving modules and / or view components that have subscribed to the data change event, triggering the corresponding collaborative logic or view update.

10. The method according to claim 7, characterized in that, The process of capturing and driving the interactive event also includes a conflict arbitration step: when multiple drivers decide to respond to the same event, the conflict arbitration service decides to make a unique or coordinated response driver according to a preset strategy. The interactive driver's dynamic hot-plug management steps also include a state persistence step: serializing and saving the driver state when unplugged, and restoring the state when replugged.

Images