A request information transmission method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application provide a request information transmission method and device, electronic equipment and storage medium, unique routing identifiers are generated for each layer of nested components; the request format of the request information of each layer of the nested components and the matching strategy between each layer of the nested components are determined based on the unique routing identifiers; and the request information is transmitted by each layer of the nested components based on the request format and the matching strategy. A unique routing identifier is generated for each component, a unified request format and an intelligent matching strategy are defined, complete decoupling and efficient and flexible communication between GUI deep nested components are achieved, and thus the maintainability and scalability of the system are significantly improved.

Description

Technical Field

[0001] This invention relates to the field of request information transmission technology, and in particular to a request information transmission method, a request information transmission device, an electronic device, and a computer-readable storage medium. Background Technology

[0002] Qt (pronounced "cute") is a cross-platform C++ graphical user interface application development framework. More broadly, it's not just a GUI library, but a complete application development framework that provides a variety of tools and libraries needed to develop various applications.

[0003] In the field of graphical user interface (GUI) development, especially when using frameworks like Qt that support multi-level nested components, the interface hierarchy can often be very deep. For example, a main interface A might contain multiple sub-components such as B1, B2, and B3, and each sub-component might further nest into even deeper sub-components such as C11, C12, and C13. This results in a complex structure with levels ranging from first-level (e.g., A), second-level (e.g., B), to third-level (e.g., C), and even more.

[0004] When a user clicks a button in a deeper (Nth-level) interface, triggering an event that requires a response from the top-level (first-level) interface, traditional development methods become inadequate. Developers typically have two options:

[0005] Hierarchical propagation: Starting from the Nth level component, the request information and corresponding processing logic are passed upwards layer by layer until the first level interface is reached.

[0006] Global processing: Introduce a global signal processing class or event bus to directly transmit information.

[0007] However, both of these traditional methods have significant drawbacks, especially in terms of efficiency in transmitting request information. Hierarchical transmission leads to strong coupling between components, making it extremely difficult to modify once the logic or component relationships at intermediate levels change; while global signal handling classes tend to become bloated and complex, difficult to manage and maintain, and are constantly modified as functionality increases, which violates the open / closed principle of software design. Summary of the Invention

[0008] The present invention provides a method, apparatus, electronic device, and computer-readable storage medium for transmitting request information to overcome or at least partially solve the above-mentioned problems.

[0009] This invention discloses a request information transmission method, which is applied to a graphical user interface development system for a framework of multi-level nested components, and includes:

[0010] For each nested component in each layer, generate a unique route identifier;

[0011] The request format of the request information of the nested components at each layer is determined based on the unique routing identifier, as well as the matching strategy between the nested components at each layer;

[0012] Based on the request format and the matching strategy, control the nested components at each layer to transmit the request information.

[0013] Optionally, the step of generating a unique route identifier for each layer of nested components includes:

[0014] Obtain the lifecycle information of the nested component;

[0015] A unique route identifier is generated based on the lifecycle information;

[0016] When the lifecycle of the nested component is determined to have ended based on the lifecycle information, the unique route identifier is deregistered.

[0017] Optionally, the step of determining the request format of the request information of each nested component based on the unique routing identifier, and the matching strategy between each nested component, includes:

[0018] The request path is determined based on the unique routing identifier;

[0019] Determine the request format and wildcards for each layer of nested components; the request format includes path information of the request path, method name information of each layer of nested components, and parameter information of the request information;

[0020] Based on the path information and the method name information, a first matching strategy is determined between the nested components at each level;

[0021] A second matching strategy is determined based on the wildcard;

[0022] Based on the parameter information, a third matching strategy is determined between the nested components in each layer.

[0023] Optionally, the step of controlling the transmission of the request information by each layer of nested components based on the request format and the matching strategy includes:

[0024] The root component and target sub-component are determined based on the path information;

[0025] Based on the first matching strategy, a first routing entry is constructed using the path information and the method name information;

[0026] When a route entry that is associated with the first route entry is matched in the preset routing table, the root component is controlled to send the parameter information to the target sub-component based on the path information.

[0027] Optionally, it also includes:

[0028] When no route entry with an association with the first route entry is found in the preset routing table, a second route entry is constructed using the wildcard based on the second matching strategy; the second route entry includes paths of the sub-levels under the root component;

[0029] When a route entry that is associated with the second route entry is matched in the preset routing table, the parameter information is sent based on the path of the sub-level under the root component.

[0030] Optionally, it also includes:

[0031] When no route entry related to the first route entry is found in the preset routing table, and no route entry related to the second route entry is found in the preset routing table, a third route entry is constructed based on the parameter information according to the third matching strategy; the third route entry includes placeholders for the parameter information.

[0032] When a route entry that is associated with the third route entry is matched in the preset routing table, and the value matched from the path information through the placeholder is an integer, the value is used to generate a processing function to represent the general device status query logic, and the processing function is used to control the root component to send the parameter information to the target sub-component.

[0033] Optionally, it also includes:

[0034] When no route entry associated with the first route entry is found in the preset routing table, no route entry associated with the second route entry is found in the preset routing table, and no route entry associated with the third route entry is found in the preset routing table, and the request information is determined to conform to the preset request pattern, other target paths are determined by reading the configuration file.

[0035] Identify other target sub-components corresponding to the other target paths, and transmit the request information to the other target sub-components based on the other target paths.

[0036] Optionally, it also includes:

[0037] Determine the middleware between the root component and the target sub-component;

[0038] If any of the middleware returns an error message, the process of transmitting the request information is immediately terminated.

[0039] This invention also discloses a request information transmission device, which is applied to a graphical user interface development system for a framework of multi-layered nested components, comprising:

[0040] The unique route identifier generation module is used to generate unique route identifiers for the nested components at each layer;

[0041] The matching strategy determination module is used to determine the request format of the request information of the nested components at each layer based on the unique routing identifier, and the matching strategy between the nested components at each layer;

[0042] The request information transmission module is used to control the transmission of the request information by each layer of the nested components based on the request format and the matching strategy.

[0043] This invention also discloses an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0044] The memory is used to store computer programs;

[0045] When the processor executes a program stored in the memory, it implements the method described in the embodiments of the present invention.

[0046] This invention also discloses a computer-readable storage medium storing instructions that, when executed by one or more processors, cause the processors to perform the methods described in this invention.

[0047] The embodiments of the present invention have the following advantages:

[0048] This invention generates unique route identifiers for each layer of nested components; determines the request format of the request information of each layer of nested components and the matching strategy between the nested components based on the unique route identifiers; and controls the transmission of the request information by each layer of nested components based on the request format and the matching strategy. By generating unique route identifiers for each component, defining a unified request format, and implementing an intelligent matching strategy, complete decoupling and efficient and flexible communication between deeply nested GUI components are achieved, thereby significantly improving the maintainability and scalability of the system. Attached Figure Description

[0049] Figure 1 This is a flowchart of the steps of a request information transmission method provided in an embodiment of the present invention;

[0050] Figure 2 This is a structural block diagram of a request information transmission device provided in an embodiment of the present invention;

[0051] Figure 3 This is a hardware structure block diagram of an electronic device provided in an embodiment of the present invention;

[0052] Figure 4 This is a schematic diagram of a computer-readable medium provided in an embodiment of the present invention. Detailed Implementation

[0053] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0054] A graphical user interface (GUI) framework with nested components refers to a software development framework that allows developers to build complex and rich application interfaces by layering and organizing user interface elements (components).

[0055] The characteristics of this architecture are:

[0056] 1. Componentization: The entire user interface is not a single, monolithic entity, but rather composed of many independent, reusable "components." Each component is responsible for a portion of the interface's display and interaction logic. For example, a button is a component, an input box is a component, and a panel containing multiple buttons and input boxes is also a component.

[0057] 2. Hierarchical structure (nesting): This is its core feature. Components can contain other components, forming a tree-like or hierarchical relationship.

[0058] Parent-child relationship: A component can be the "parent" of another component, and the components it contains are the "child".

[0059] Deep nesting: This parent-child relationship can extend indefinitely, resulting in a very deep interface structure. For example:

[0060] A main window (top-level component) may contain a sidebar component and a main content area component.

[0061] The main content area component may contain a tab component, where each tab is an independent component.

[0062] Each tab may contain a data table component and several control button components.

[0063] Each cell of a data table component can even be a smaller component, containing text or icons.

[0064] Example: In Qt, QMainWindow can contain QWidgets (such as QPushButton, QLabel, QLineEdit), and QWidgets can in turn contain other QWidgets. These components are organized using layout managers (such as QVBoxLayout, QHBoxLayout, QGridLayout).

[0065] 3. Event-driven: User interactions with the GUI (such as clicking a button or entering text) trigger events, which are then passed and processed between components through the framework's mechanisms.

[0066] 4. Data binding (optional but common): Many modern frameworks support binding UI components to data models. When the data model changes, the UI will automatically update; conversely, user actions on the UI can also automatically update the data model.

[0067] 5. Separation of duties: Each component typically has a clear responsibility, handling its own part of the interface display and logic processing, which helps with code organization and maintenance.

[0068] The advantages of a multi-layered nested architecture are:

[0069] Modularity and reusability: Small, independent components can be reused multiple times, accelerating the development process.

[0070] Clear structure: Logically, the interface structure is clearly hierarchical, making it easy to understand and manage.

[0071] Easy to collaborate: Different developers can work on different components simultaneously without interfering with each other.

[0072] However, this architecture also presents challenges, especially in cases of deep nesting:

[0073] Communication complexity: When deep child components need to communicate with top-level or non-direct parent components, traditional signal / slot mechanisms (such as Qt) may cause signals to be passed layer by layer, forming "signal tunnels", resulting in tight code coupling and difficulty in maintenance.

[0074] Performance considerations: Excessive nesting may increase the overhead of layout calculation and rendering, affecting performance.

[0075] Management difficulty: When the number of components is large, managing and finding specific components becomes complicated.

[0076] Here are some key features and concepts of Qt:

[0077] Cross-platform compatibility: This is one of Qt's most notable features. Code written in Qt can be easily compiled and run on mainstream desktop operating systems (such as Windows, macOS, and Linux), mobile operating systems (such as Android and iOS), and embedded devices without requiring extensive code modifications.

[0078] C++ Framework: Qt is primarily developed using the C++ language, which enables it to offer high performance and powerful functionality. At the same time, Qt also provides Python bindings (PyQt and PySide), allowing developers to use Python to develop Qt applications.

[0079] Rich GUI components: Qt provides a large number of pre-built UI widgets, such as buttons, labels, text boxes, lists, tables, menus, dialog boxes, and more. These components can help developers quickly build user interfaces.

[0080] Signals and Slots: This is one of Qt's core mechanisms for communication between objects. When a specific event occurs (e.g., a button is clicked), an object emits a "signal." Other objects interested in this signal can connect to the signal's "slot" function and automatically perform the corresponding operation when the signal is emitted. This mechanism achieves loose coupling between objects.

[0081] Layout Managers: Qt provides powerful layout managers that can automatically adjust the size and position of controls in a window to adapt to different window sizes and screen resolutions, ensuring good user interface adaptability.

[0082] Graphics and Animation: Qt provides a rich set of APIs for drawing 2D and 3D graphics and creating a variety of animation effects, enabling developers to create attractive user interfaces and visualizations.

[0083] Network programming: Qt includes classes for network programming, such as support for protocols like TCP / IP, UDP, and HTTP, making it easy to develop network applications.

[0084] Database support: Qt provides APIs for accessing various database systems, such as MySQL, PostgreSQL, SQLite, etc.

[0085] XML and JSON processing: Qt provides convenient classes for parsing and generating XML and JSON data.

[0086] Thread management: Qt provides tools for multithreaded programming, which can help developers create concurrently running applications and improve program responsiveness.

[0087] Internationalization and localization (i18n & L10n): Qt supports the internationalization and localization of applications, making it easy to translate applications into different languages.

[0088] Qt Quick: This is a declarative framework for creating modern, touch-friendly user interfaces. It uses QML (Qt Meta Language) as the language for describing the UI and combines it with JavaScript to implement interaction logic. Qt Quick is ideal for developing mobile applications and user interfaces with smooth animations.

[0089] Tools and ecosystem: Qt has comprehensive development tools (Qt Creator is a powerful integrated development environment), a large developer community, and a wealth of third-party libraries.

[0090] In summary, Qt is a powerful and comprehensive cross-platform application development framework, particularly adept at creating applications with graphical user interfaces, but also suitable for developing non-GUI applications such as console tools and server applications. Its cross-platform compatibility, rich libraries, and robust signal and slot mechanism make it the framework of choice for many developers and enterprises.

[0091] In the field of graphical user interface (GUI) development, especially when using frameworks like Qt that support multi-level nested components, the hierarchical structure of the interface often becomes very deep. For example, a main interface A may contain multiple sub-components such as B1, B2, and B3, and these sub-components may further nest into even deeper sub-components such as C11, C12, and C13, thus forming a complex structure with first-level, second-level, third-level, or even more levels.

[0092] When a user clicks a button in a deeper (Nth-level) interface to trigger an event, and a response is required in the top-level (first-level) interface, traditional development methods face numerous challenges. Two common solutions are:

[0093] Hierarchical signal propagation: Starting from the Nth level component, signals and corresponding processing logic are propagated upwards layer by layer until the first level interface.

[0094] Global signal processing: Information is directly transmitted using a global signal processing class or event bus.

[0095] However, both approaches have significant drawbacks: Passing signals hierarchically makes the connections between each interface very tight, leading to strong coupling. Modifying the call relationship between signals and processing logic becomes extremely difficult and costly to maintain. On the other hand, using a global signal handling class means that as new features are added, the class will be continuously modified, becoming increasingly complex and rigid to manage, violating the open / closed principle of software design (open for extension, closed for modification).

[0096] Inherent flaws of traditional GUI development

[0097] In summary, the traditional GUI development model has the following core flaws:

[0098] Hierarchical signal propagation leads to strong coupling: child components must pass signals through parent components layer by layer, which creates a tight dependency between parent and child components, making it difficult to modify and reuse them independently.

[0099] Rigid global management: The global event bus or signal processing class needs to be frequently modified to adapt to new functions. This not only increases the management difficulty, but also violates the open / closed principle, resulting in poor system scalability.

[0100] Communication paths are not configurable: The communication paths between components are hard-coded into the program during the coding phase and cannot be dynamically adjusted at runtime, resulting in a lack of flexibility.

[0101] While routing mechanisms in web frameworks excel at resolving inter-component communication, their design philosophy differs fundamentally from that of GUI development environments, making them unsuitable for direct application to GUIs. This is primarily due to their lack of the following key features:

[0102] Limitations of existing technologies (Web routing mechanisms):

[0103] Automatic generation of hierarchical paths: Web routes typically rely on predefined URL paths, while the nested structure of GUI components is dynamic, requiring a mechanism to automatically generate unique route paths based on the nesting relationship of the components themselves.

[0104] Request method and parameter support: GUI events may involve various operation instructions and complex parameters. Web routing typically implements this through HTTP methods and query strings. GUIs need a mechanism that can clearly declare operation instructions (method names) and carry complex parameters in the path.

[0105] Runtime route redirection: Web application routing rarely involves dynamic adjustments at runtime, while GUI development may require dynamically binding or redirecting communication links at runtime based on specific business logic or external configuration.

[0106] 1. Routing mechanism:

[0107] To address the aforementioned issues, this invention provides a routing and forwarding mechanism, which includes a routing class. The main function of this routing class is to distribute request information, and the request information can carry various parameters.

[0108] (a) Request submission:

[0109] When making a request, you can use the following method:

[0110] C++

[0111] MessageRouter::Submit("rs: / / xxxx",{ / *request parameters* / },callback function);

[0112] The first parameter "rs: / / xxxx" is like an address, indicating which level and component should handle the request; the second parameter is the parameters carried in the request, which will be organized according to a common data pattern; the third parameter is the callback function, which will be called after the route dispatches and processes the request.

[0113] (II) Request Interception and Processing:

[0114] For components that need to process requests, requests can be intercepted and processed in the following ways:

[0115] C++

[0116] MessageRouter::AddRouter("rs: / / xxxx",[](request data, callback function){ / *Write the specific processing logic code here* / });

[0117] In this way, when a component in the Nth level interface makes a request, the router will forward the request to the corresponding component in the Mth level interface for processing.

[0118] 2. Automatic route assembly and post-binding:

[0119] This invention also implements an automatic route concatenation function, allowing routes to be automatically generated based on the hierarchical nesting relationship of the interface. Specifically, each interface component has a method to obtain its own route name, which is concatenated based on the route name of its parent component.

[0120] For example, if class A inherits from a UI component class, its route name retrieval method is as follows:

[0121]

[0122] When creating components at different levels, the route names are automatically concatenated.

[0123] For example:

[0124] When B*b = new B(nullptr) and A*a = new A(b) are created, the route sent by calling a.onclick() is "rs: / / B / A".

[0125] When you create C*c = new C(nullptr);, B*b = new B(c); and A*a = new A(b);, the route sent by calling a.onclick() is "rs: / / C / B / A".

[0126] After the interface development is complete, this embodiment of the invention can use a routing module to specify the response handling for routing events. For example, a function to handle the response to a routing request can be implemented in class C:

[0127] C++

[0128] class C:public Widget{public: / *Other logic code* / private:void InitClickRequest(){MessageRouter::AddRouter(GetClassRouterName(),[](request data, callback function){ / *Write the specific logic code here* / });}}

[0129] Then, you can use Router::Bind("rs: / / C","rs: / / C / B / A"); to bind the route, so that when a.onclick() is called, the processing logic in C will be triggered.

[0130] Even more conveniently, the two parameters in Router::Bind can be specified through a configuration file instead of being written in the code, which allows for flexible specification of the relationship between requests and responses later.

[0131] Reference Figure 1 The diagram illustrates a flowchart of a request information transmission method provided in an embodiment of the present invention, which may specifically include the following steps:

[0132] Step 101: Generate a unique route identifier for each nested component in each layer;

[0133] This invention applies to a graphical user interface development system for a framework of multi-layered nested components, hereinafter referred to as the system.

[0134] Nested components refer to the various interface elements that make up a graphical user interface (GUI), such as a main window containing multiple panels, and each panel containing controls such as buttons and text boxes.

[0135] Unique route identifier: Just as every webpage has a unique URL, this is a unique string name assigned to each component in the GUI that can receive and send messages. The system uses this name to accurately locate a specific component.

[0136] This invention generates unique route identifiers for each nested component, the purpose of which is:

[0137] This establishes a unified and explicit addressing method for all components in the GUI that need to communicate. It solves the problems of unclear and difficult-to-locate communication addresses between components in traditional methods, and its beneficial effects include:

[0138] Achieve precise addressing: Ensure that every sent request finds a unique and correct recipient, avoiding messages being sent to the wrong place.

[0139] Reduced coupling: When a component sends a request, it does not need to know the specific location of the receiver in memory, but only its route identifier, which greatly reduces the dependencies between components.

[0140] Preparing for subsequent routing: Having a unique identifier allows the system to determine how to pass the request in subsequent steps.

[0141] Example:

[0142] Assuming the main interface is called MainWindow, its routing identifier might be rs: / / MainWindow.

[0143] The MainWindow has a sub-component called DevicePanel, and its route identifier is rs: / / MainWindow / DevicePanel.

[0144] If there is a LightController component inside DevicePanel, its identifier is rs: / / MainWindow / DevicePanel / LightController. In this way, each component has a unique "address" like a file path.

[0145] Step 102: Determine the request format of the request information of the nested components at each layer and the matching strategy between the nested components at each layer based on the unique routing identifier;

[0146] Request information: "Instructions" and "data packets" passed between components, containing the specific operation to be performed (method name) and the relevant data (parameters) required for the operation.

[0147] Request format: Defines what the request message looks like and how it is organized. It specifies a standard structure, which typically includes: which component to send it to (determined by a unique route identifier / request path), what it should do (method name), and what data is needed to complete this operation (parameters).

[0148] Matching strategy: This refers to how a routing system, upon receiving a request, "identifies" and "finds" the component or function that can handle the request. It's like a post office sorting mail, with different rules for identifying targets.

[0149] This invention can determine the request format of request information for each nested component based on a unique routing identifier, as well as the matching strategy between nested components. Its purpose is to establish a standardized communication protocol and an intelligent lookup mechanism. It not only standardizes how request information is "packaged," but also defines how the system "understands" and "distributes" these requests to ensure that requests are correctly received and processed. Beneficial effects include:

[0150] Communication standardization: All requests follow a uniform format, making it simple and efficient for the system to understand and process requests.

[0151] Intelligent search: Through different matching strategies, the system can find the target of the request more flexibly and accurately, improving the efficiency and success rate of request distribution.

[0152] Supports complex scenarios: Different matching strategies (exact, wildcard, parameterized) can handle various complex communication needs, such as precisely calling a specific function or handling a class of general operations.

[0153] Example:

[0154] Request format: To have the LightController turn on the light and set the brightness to 80, the request information can be formatted as: rs: / / MainWindow / DevicePanel / LightController / TurnOn?brightness=80.

[0155] rs: / / MainWindow / DevicePanel / LightController is the request path (based on a unique route identifier).

[0156] TurnOn is the name of the method to be called.

[0157] brightness=80 is parameter information.

[0158] Matching strategy:

[0159] Exact match: The system will prioritize finding route entries that are exactly the same as rs: / / MainWindow / DevicePanel / LightController / TurnOn.

[0160] Wildcard matching: If no exact match is found, the system will try to find routes containing the asterisk (*), such as rs: / / MainWindow / * / TurnOn (matches the TurnOn method at any level under MainWindow).

[0161] Parameterized matching: If neither of the first two matches, the system will try to find a route containing a <placeholder>, such as rs: / / Device / <deviceid:int>Use ` / GetStatus` to extract dynamic parameters from the path (such as 123 in this case).

[0162] Step 103: Based on the request format and the matching strategy, control the nested components at each layer to transmit the request information.

[0163] Control transmission: This refers to the routing system actively directing the request information to the corresponding target component or its processing function and triggering the corresponding operation after receiving the request, based on the request format and matching strategy determined in step 102.

[0164] Root component: usually refers to the top-level window or main interface of a GUI application, which is the starting point of the entire component hierarchy.

[0165] Target subcomponent: The specific component to which the routing system will ultimately pass the request; it may be a deeply nested subcomponent.

[0166] This invention can control the transmission of request information by nested components at each level based on request format and matching strategy. The aim is to put the "address book" and "sorting rules" established in the first two steps into practice, ensuring that request information can reach the receiver and be processed efficiently and accurately according to preset logic. The beneficial effects include:

[0167] Enables dynamic communication: Components no longer need to call each other by hard-coding, but communicate indirectly through the routing system, which improves the flexibility of the system.

[0168] Simplified development: Developers do not need to worry about how requests "jump" between multiple components; they only need to focus on the request sending and processing logic.

[0169] Improve maintainability: When the component structure or communication logic changes, it may only be necessary to adjust the routing rules or the target component itself, without the need for large-scale modifications to the call chain.

[0170] Example:

[0171] Suppose that somewhere in the main interface A (the root component), a trigger sends a request: rs: / / MainWindow / DevicePanel / LightController / TurnOn?brightness=50.

[0172] After receiving this request, the routing system will perform the search according to the matching strategy defined in step 102 (first exact, then wildcard, then parameterized).

[0173] If an exact match is found, the routing system will identify that the target of the request is the TurnOn method of the LightController component (the target child component).

[0174] Next, the system will "control" this request, passing the parameter `brightness=50` to the `TurnOn` method of the `LightController` component, thereby turning on the light and setting its brightness. The entire process may be coordinated by the root component (e.g., a global event dispatcher), ultimately delivering the parameters to the target child component.

[0175] This invention generates unique route identifiers for each layer of nested components; determines the request format of the request information of each layer of nested components and the matching strategy between the nested components based on the unique route identifiers; and controls the transmission of the request information by each layer of nested components based on the request format and the matching strategy. By generating unique route identifiers for each component, defining a unified request format, and implementing an intelligent matching strategy, complete decoupling and efficient and flexible communication between deeply nested GUI components are achieved, thereby significantly improving the maintainability and scalability of the system.

[0176] Furthermore, the overall beneficial effects of steps 101-103 include:

[0177] 1. Complete decoupling, reducing system complexity:

[0178] Addressing pain points: In traditional methods, whether signals are passed step by step or global signal processing classes are used, the components are tightly coupled, making the system structure complex and difficult to maintain and extend.

[0179] Beneficial effects: By generating a unique route identifier (step 101), each component has an independent "address." Request information no longer needs to be passed between components; instead, it is sent directly to the routing system, which distributes it based on the identifier. This completely breaks the direct dependencies between components, achieving a high degree of decoupling, allowing each component to be developed and maintained more independently, thereby significantly reducing the complexity of the entire system.

[0180] 2. Improve communication efficiency and flexibility:

[0181] Addressing pain points: Passing signals step-by-step creates redundant intermediate processing steps, reducing the efficiency of request information transmission; and global signal processing classes become bloated as functionality increases, impacting processing speed. Traditional communication paths are hard-coded during the encoding stage, lacking dynamic adjustment capabilities.

[0182] Beneficial effects: Through a unified request format and intelligent matching strategy (step 102), the routing system can efficiently and accurately locate the target component and transmit request information (step 103). Requests no longer need to go through multiple layers of intermediate components; instead, the routing system directly "navigates" to the destination. This not only greatly improves the transmission efficiency of request information but also provides great communication flexibility through diverse matching strategies (exact, wildcard, parameterized), enabling it to adapt to various complex dynamic interaction scenarios.

[0183] 3. Enhance system maintainability and scalability:

[0184] Addressing the pain points: The global signal processing class becomes rigid due to frequent modifications, violating the open / closed principle and making it difficult to extend the system with new functions. Tightly coupled components also make modification difficult.

[0185] Beneficial effects: The routing mechanism separates communication logic from specific business components, achieving separation of responsibilities. When new component functionalities need to be added or the communication methods between existing components need to be changed, developers can achieve this primarily by configuring or adding new routing rules, without modifying a large amount of existing component code. This greatly improves the maintainability and scalability of the system, enabling it to adapt more flexibly to future changes in requirements, in line with the open / closed principle of software design.

[0186] In summary, the routing and forwarding mechanism constituted by steps 101-103 fundamentally changes the communication mode of deeply nested components in Qt GUI, solves the coupling, efficiency and management problems brought about by traditional methods, and brings a clearer, more efficient, flexible and easy-to-maintain communication architecture to GUI development.

[0187] Based on the above embodiments, modified embodiments of the above embodiments are proposed. It should be noted that, in order to keep the description brief, only the differences from the above embodiments are described in the modified embodiments.

[0188] In an optional embodiment of the present invention, the step of generating a unique route identifier for each layer of nested components includes:

[0189] Obtain the lifecycle information of the nested component;

[0190] A unique route identifier is generated based on the lifecycle information;

[0191] When the lifecycle of the nested component is determined to have ended based on the lifecycle information, the unique route identifier is deregistered.

[0192] Lifecycle information: refers to the process and state of a component from its creation to its destruction.

[0193] Unregister: Remove the route identifier of this component from the routing system so that it no longer receives new requests.

[0194] The purpose of this optional embodiment is to ensure the validity of routing identifiers and the proper management of resources. When a component no longer exists, its routing identifier should also be removed to avoid sending requests to invalid targets, thereby improving system stability and resource utilization, and preventing memory leaks and invalid communication attempts.

[0195] In an optional embodiment of the present invention, the step of determining the request format of the request information of each layer of nested components based on the unique routing identifier, and the matching strategy between each layer of nested components, includes:

[0196] The request path is determined based on the unique routing identifier;

[0197] Determine the request format and wildcards for each layer of nested components; the request format includes path information of the request path, method name information of each layer of nested components, and parameter information of the request information;

[0198] Based on the path information and the method name information, a first matching strategy is determined between the nested components at each level;

[0199] A second matching strategy is determined based on the wildcard;

[0200] Based on the parameter information, a third matching strategy is determined between the nested components in each layer.

[0201] Wildcards: Special symbols used for fuzzy matching of routing paths. For example, "*" can match paths at any level.

[0202] Path information: A string in the route identifier that indicates the component hierarchy.

[0203] Method name information: Specifies the name of the component function to be invoked in the request.

[0204] Parameter information: Data required for executing the method carried in the request.

[0205] First matching strategy (exact match): The request path and method name must be exactly the same as the registered route entry.

[0206] The second matching strategy (wildcard matching): Use wildcards to flexibly match paths.

[0207] The third matching strategy (parameterized matching): matches dynamic parameters in the path using placeholders.

[0208] The purpose of this alternative embodiment is to illustrate in detail the composition of the request format and three different priority matching strategies to improve the flexibility and accuracy of request routing and enable the system to handle a wider range of request scenarios, from exact calls to fuzzy matching and parameterized processing.

[0209] In an optional embodiment of the present invention, the step of controlling the transmission of the request information by each layer of nested components based on the request format and the matching strategy includes:

[0210] The root component and target sub-component are determined based on the path information;

[0211] Based on the first matching strategy, a first routing entry is constructed using the path information and the method name information;

[0212] When a route entry that is associated with the first route entry is matched in the preset routing table, the root component is controlled to send the parameter information to the target sub-component based on the path information.

[0213] Root component: The top-level component of the GUI interface, such as the main window.

[0214] Target subcomponent: The component to which the request will ultimately be sent.

[0215] Route entry: The component path, method name, and corresponding processing function recorded in the routing table.

[0216] The purpose of this optional embodiment is to describe how, after a perfect match is successful, request information is passed from the initiator (which may be the root component or other components) to the final target sub-component to ensure that the perfect match request is accurately delivered to the target processor.

[0217] For example, an exact match:

[0218] When a request is received with the path rs: / / MainWindow / DevicePanel / LightController, the request method name is TurnOn, and it also carries the query parameter brightness=50, the routing system will first initiate the exact matching process.

[0219] The system will strictly search its internal routing record table for a routing rule whose path (rs: / / MainWindow / DevicePanel / LightController) is exactly the same as the request path, and whose method name (TurnOn) is also exactly the same as the request method name.

[0220] If a perfectly matching entry is found in the routing table, and the handler function associated with this route entry happens to be the method named TurnOn in the LightController component, then the request is considered a successful exact match.

[0221] Once a match is successful, the system will parse the parameters carried in the request. In this example, the query string "? brightness=50" will be parsed and returned as a parameter named "brightness" with a value of 50.

[0222] Finally, the parsed parameter (brightness=50) will be passed to the TurnOn method of the LightController component to perform the corresponding operation.

[0223] In an optional embodiment of the present invention, it further includes:

[0224] When no route entry with an association with the first route entry is found in the preset routing table, a second route entry is constructed using the wildcard based on the second matching strategy; the second route entry includes paths of the sub-levels under the root component;

[0225] When a route entry that is associated with the second route entry is matched in the preset routing table, the parameter information is sent based on the path of the sub-level under the root component.

[0226] The path of child components under the root component: refers to the path pattern that starts from the root component and includes several intermediate child components, which may contain wildcards.

[0227] A wildcard is a special symbol that represents one or more undefined or arbitrary characters. Its main purpose is to perform fuzzy matching or pattern matching, rather than exact matching.

[0228] In practical applications, the specific symbols and meanings of wildcards may vary slightly in different contexts:

[0229] In file search or command line:

[0230] * (asterisk): usually represents zero or more arbitrary characters.

[0231] For example: *.txt matches all files that end with .txt (such as document.txt, report.txt).

[0232] The `data*` keyword matches all files or folders that begin with "data" (e.g., data.csv, database).

[0233] ?(Question mark): Usually represents any single character.

[0234] For example: pic?.jpg matches pic1.jpg, picA.jpg, but does not match pic11.jpg.

[0235] In database queries (SQL):

[0236] %(Percent sign): Represents zero or more arbitrary characters (similar to * in file search).

[0237] For example: SELECT * FROM users WHERE name LIKE 'Zhang%'; Finds all users with the surname 'Zhang'.

[0238] _(Underscore): Represents a single arbitrary character (similar to? in file search).

[0239] For example: SELECT * FROM products WHERE code LIKE 'A_123'; Finds products with a code that starts with A followed by a single arbitrary character and then 123.

[0240] In routing or URL matching:

[0241] *(Asterisk): Represents one or more arbitrary levels in the path.

[0242] For example: rs: / / MainWindow / * / TurnOn matches rs: / / MainWindow / DevicePanel / LightController / TurnOn, and also matches rs: / / MainWindow / OtherArea / Lamp / TurnOn. It means that there can be any number of levels under MainWindow, as long as the last part is the TurnOn method.

[0243] The purpose of this optional embodiment is to describe how to use wildcard matching for request routing and passing after an exact match fails, so as to be able to handle requests with an incompletely determined target component path and improve the flexibility of the system.

[0244] Exemplarily:

[0245] When a request is received with a path of rs: / / MainWindow / SomeOtherPanel / AnyComponent, a method name of SetValue, and query parameters value = 10, the routing system will first attempt an exact match.

[0246] The system searches its routing table for a routing rule with the path exactly rs: / / MainWindow / SomeOtherPanel / AnyComponent and the method name SetValue. However, based on the description, no exact match was found.

[0247] Since an exact match failed, the system will then attempt a wildcard match. It will look in the routing table for a routing rule containing the special symbol *. In this example, assume there is a wildcard routing rule: rs: / / MainWindow / * / SetValue.

[0248] This wildcard rule means: match requests that start with rs: / / MainWindow / , followed by any level of path (represented by *), and whose method name is SetValue.

[0249] The request path rs: / / MainWindow / SomeOtherPanel / AnyComponent matches the pattern rs: / / MainWindow / *, because SomeOtherPanel / AnyComponent can be overridden by "any level" represented by *. Additionally, the requested method name SetValue matches the method name in the rule. Therefore, this request was successfully matched using wildcards.

[0250] After a successful match, the system will parse the parameters carried in the request. In this example, the query string "?value=10" will be parsed and a parameter named "value" with a value of 10 will be obtained.

[0251] Finally, the parsed parameter (value = 10) is passed to the handler function associated with the wildcard routing rule. It's important to note that because it's a wildcard match, this handler function might be defined at the MainWindow component level or a higher-level global handler. It needs to be able to perform the appropriate operation based on different contexts (e.g., from which child component the SetValue request originated).

[0252] In an optional embodiment of the present invention, it further includes:

[0253] When no route entry related to the first route entry is found in the preset routing table, and no route entry related to the second route entry is found in the preset routing table, a third route entry is constructed based on the parameter information according to the third matching strategy; the third route entry includes placeholders for the parameter information.

[0254] When a route entry that is associated with the third route entry is matched in the preset routing table, and the value matched from the path information through the placeholder is an integer, the value is used to generate a processing function to represent the general device status query logic, and the processing function is used to control the root component to send the parameter information to the target sub-component.

[0255] Placeholders for the parameter information: markers used in the routing path to match parameter values ​​of a specific type or format, for example... <deviceid:int>.

[0256] A general device status query logic processing function: a functional module that can query the device status based on the input device ID.

[0257] The purpose of this optional embodiment is to provide a way to route and process requests using parameterized matching after both exact matching and wildcard matching have failed. This allows for more precise matching and processing based on parameter types, thereby ensuring that requests that need to be differentiated based on dynamic parameters in the path can be processed, and that specific processing can be performed based on parameter types.

[0258] For example:

[0259] First, the system performs the most rigorous search—an exact match. It searches the registered route records for entries with the exact same path (rs: / / Device / 123 / GetStatus) and the exact same requested method name (GetStatus). If no matching record is found in the route table, the exact match fails.

[0260] If an exact match fails, the system will slightly relax the conditions and attempt a wildcard match. It will look for routing rules containing the special symbol "*". This asterisk can represent any one or more levels in the path. For example, rs: / / Device / * / GetStatus can match rs: / / Device / 123 / GetStatus, and rs: / / * / GetStatus can also match. However, in this example, it can be assumed that no wildcard routing rule matching the current request path and method name was found.

[0261] If both exact matching and wildcard matching fail, the system will attempt parameterized matching as a last resort. This matching method allows the use of placeholders in the routing path to capture dynamic parts of the path. In this example, assume a parameterized routing rule is predefined in the routing table: rs: / / Device / <deviceid:int> / GetStatus.

[0262] The system will compare the request path rs: / / Device / 123 / GetStatus with this rule.

[0263] The structure of the request path was found to match the structure of the rule, and the placeholders... <deviceid:int>The "123" part of the request path was successfully matched. The ":int" indicates that an integer type is expected to be matched here.

[0264] At the same time, the request method name GetStatus is consistent with the method name in the rule.

[0265] Therefore, this request was successfully matched by the parameterized route.

[0266] Once a match is found, the system will parse and extract the parameters captured by the placeholders in the path. In this example, <deviceid:int>If "123" is matched, the system will parse "123" into an integer parameter and store it as deviceId with a value of 123.

[0267] Finally, the system calls the processing function associated with this parameterized routing rule and passes the parsed parameters (deviceId = 123) to this function. This processing function may be a general device status query logic, which can query the status of the corresponding device based on the different passed deviceIds.

[0268] In the parameterized matching example rs: / / Device / 123 / GetStatus, "123" is a placeholder in the path that is used as a parameter. <deviceid:int>A specific numerical value that was matched.

[0269] More specifically, according to the parameterized routing rule rs: / / Device / <deviceid:int> / GetStatus:

[0270] rs: / / Device / and / GetStatus are static path parts that are the same in all requests that match this rule.

[0271] <deviceid:int>It is a parameter placeholder.

[0272] <deviceid>This indicates that this is a parameter named deviceId.

[0273] :int is a type constraint that indicates the expected value to be matched is an integer.

[0274] Therefore, when the request path is rs: / / Device / 123 / GetStatus, the routing system will extract "123" from the path and pass it as a parameter named deviceId to the corresponding processing function.

[0275] "123" can be understood as a specific device ID. This ID may change in different requests (e.g., rs: / / Device / 456 / GetStatus), and parameterized routing rules can capture these different IDs and pass them as parameters to the same processing function, thereby achieving common processing logic for different devices.

[0276] In summary, in the example, "123" is a specific device identifier that is extracted through a placeholder in the parameterized route and used as a dynamic parameter of the request.

[0277] In another example, the three matching priorities can be implemented as follows, assuming the component hierarchy includes: main interface A, child components B1, B2, B3, and child components C11, C12, C13 of B1. Assume each component has some methods that can be called.

[0278] Scenario assumption:

[0279] Component A (MainWindow) has a method UpdateTitle(title). Its route path is rs: / / MainWindow.

[0280] Component B1 (DevicePanel) has a method ShowDetails(deviceId). Its route path is rs: / / MainWindow / DevicePanel.

[0281] The component C12 (LightController) has a method TurnOn(brightness). Its route path is rs: / / MainWindow / DevicePanel / LightController.

[0282] In addition, assume that some general processing functions are also registered.

[0283] Example:

[0284] 1) Exact match:

[0285] Request path: rs: / / MainWindow / DevicePanel / LightController / TurnOn?brightness=50

[0286] Matching process:

[0287] The system first attempts to precisely match the route rs: / / MainWindow / DevicePanel / LightController and the method name TurnOn.

[0288] If an exact match is found in the routing table, and the associated handler function is the TurnOn method of the LightController component, then the request will be matched precisely.

[0289] The parameter brightness=50 is parsed and passed to the TurnOn method of LightController.

[0290] 2) Wildcard matching:

[0291] Request path: rs: / / MainWindow / SomeOtherPanel / AnyComponent / SetValue?value=10

[0292] Matching process:

[0293] First, an exact match was performed, but no exact route was found for rs: / / MainWindow / SomeOtherPanel / AnyComponent / SetValue.

[0294] Next, the system attempts wildcard matching. Assume there exists a wildcard route in the routing table: rs: / / MainWindow / * / SetValue, which matches any sub-level path under rs: / / MainWindow, and the method name is SetValue.

[0295] The request was matched by wildcards because rs: / / MainWindow / SomeOtherPanel / AnyComponent matches the pattern rs: / / MainWindow / * and the method name is SetValue.

[0296] The parameter `value = 10` is parsed and passed to the handler function associated with this wildcard route. This handler function may be defined at the MainWindow level or a global handler, and needs to be able to handle SetValue requests from different child components.

[0297] 3) Parametric matching:

[0298] Request path: rs: / / Device / 123 / GetStatus

[0299] Matching process:

[0300] First, an exact match was performed, but no exact route was found for rs: / / Device / 123 / GetStatus.

[0301] Then, wildcard matching was attempted, but no suitable wildcard route was found.

[0302] Next, the system attempts parameterized matching. Assume a parameterized route exists in the routing table: rs: / / Device / <deviceid:int> / GetStatus.

[0303] The request path rs: / / Device / 123 / GetStatus matches this pattern. <deviceid:int>The code successfully matched "123" and parsed it as an integer parameter named "deviceId". The method name "GetStatus" also matched.

[0304] The extracted parameter deviceId=123 is parsed and passed to the processing function associated with this parameterized route. This processing function may be responsible for handling general logic for different device status queries.

[0305] Matching process summary (for the example above):

[0306] When a request (e.g., rs: / / MainWindow / DevicePanel / LightController / TurnOn?brightness=50) arrives, the routing system matches them in the following order:

[0307] 1. Exact Match: Search the routing table for an entry with the path rs: / / MainWindow / DevicePanel / LightController and the method name TurnOn. If found, call the corresponding handler function and pass in the parameters.

[0308] 2. Wildcard Matching: If no exact match is found, the system searches for routes containing wildcards, such as rs: / / MainWindow / * / TurnOn or rs: / / * / TurnOn, and attempts to match the path and method name. If a match is found, the corresponding handler function is called.

[0309] 3. Parameterized matching: If no match is found, the route containing parameter placeholders is searched, for example, rs: / / MainWindow / <component> / TurnOn or rs: / / <devicetype> / <deviceid>The ` / GetInfo` function attempts to match the path structure and method name, and extracts the parameters from the path. If a match is successful, the corresponding processing function is called, passing in the extracted parameters.

[0310] With this three-level matching priority, the system can flexibly handle requests of various granularities. It can precisely call methods of specific components, or handle more general request patterns through wildcards and parameterized routing.

[0311] In an optional embodiment of the present invention, it further includes:

[0312] When no route entry associated with the first route entry is found in the preset routing table, no route entry associated with the second route entry is found in the preset routing table, and no route entry associated with the third route entry is found in the preset routing table, and the request information is determined to conform to the preset request pattern, other target paths are determined by reading the configuration file.

[0313] Identify other target sub-components corresponding to the other target paths, and transmit the request information to the other target sub-components based on the other target paths.

[0314] Preset request pattern: refers to the matching rules for source requests defined in the dynamic binding configuration file.

[0315] Other target paths: Request forwarding target paths specified in the dynamic binding configuration file.

[0316] Other target sub-components: Components corresponding to other target paths.

[0317] The purpose of this optional embodiment is to implement a dynamic binding mechanism, which redirects requests according to the configuration file after all static routes fail to match, so as to ensure the flexibility of the system operation and change the communication links between components without modifying the code.

[0318] Example: If a request to rs: / / * / LightController / TurnOn?brightness=50 has no match in the static routing table, but the configuration file contains the following rule: {"source":"rs: / / * / LightController / TurnOn","target":"rs: / / Global / DeviceManager / SetLight","params":{"value":"$.brightness"}}, then the request will be redirected to rs: / / Global / DeviceManager / SetLight, and the brightness parameter from the original request will be passed as the value parameter of the target request.

[0319] In an optional embodiment of the present invention, it further includes:

[0320] Determine the middleware between the root component and the target sub-component;

[0321] If any of the middleware returns an error message, the process of transmitting the request information is immediately terminated.

[0322] Middleware: Interceptors or handlers that are executed before or after a request reaches the target processing function. They can be used to implement functions such as authentication, logging, and data verification.

[0323] The purpose of this alternative embodiment is to introduce a middleware mechanism that can insert additional logic at different stages of request processing, enhance the functionality and security of the system, achieve unified management of cross-cutting concerns, and improve the security, maintainability, and scalability of the system.

[0324] Example: During the process of MainWindow sending a TurnOn request to LightController, an authentication middleware can be configured to check whether the user has permission to operate the light. If authentication fails, the request transmission will be terminated.

[0325] To enable those skilled in the art to better understand the embodiments of the present invention, an example is used below to illustrate the embodiments of the present invention.

[0326] Step 1, Route Identification System Construction:

[0327] 1. Automatic registration during construction

[0328] All routable components inherit from the RoutableWidget base class.

[0329] Base class constructor: Generates route paths based on component hierarchy and registers them with the routing core system.

[0330] Path generation rules:

[0331] · Root component path: rs: / / [component identifier] (e.g., rs: / / MainWindow).

[0332] · Child component path: parent path / [component identifier] (e.g., rs: / / MainWindow / DevicePanel).

[0333] Base class destructor: Automatically unregisters the component's route path.

[0334] 2. Component Identifier Definition

[0335] By default, QObject::objectName() is used as the identifier.

[0336] Developers can customize identifiers using the setRouteIdentifier() interface.

[0337] Example:

[0338] • Component tree: MainWindow→DevicePanel→LightController

[0339] • Generation path: rs: / / MainWindow / DevicePanel / LightController

[0340] Step 2, Defining and parsing route requests:

[0341] 1. Request path format

[0342] Full format: rs: / / [path] / [method name]?[parameters]

[0343] Example: rs: / / MainWindow / DevicePanel / LightController / TurnOn? brightness=80

[0344] Method name: Indicates the specific operation instruction (such as TurnOn, SetValue).

[0345] Parameters: key-value pairs, supporting nested data (via URL encoding or JSON format).

[0346] 2. Parameter parsing rules

[0347] Path parameters: Extract dynamic parameters from the path (e.g., rs: / / Device / ) <id:int> / GetInfo to extract the id).

[0348] Query parameters: Parse the ? in the URL to get a set of key-value pairs: key1=value1&key2=value2.

[0349] Step 3, Route matching strategy:

[0350] 1. Three-level matching priority

[0351] 1. Exact match: The path and method name are exactly the same (e.g., rs: / / A / B / C / TurnOn).

[0352] 2. Wildcard matching:

[0353] Use * to match any level (e.g., rs: / / A / * / TurnOn matches rs: / / A / X / Y / TurnOn).

[0354] 3. Parametric matching:

[0355] Extracting parameters using placeholders (e.g., rs: / / Device / ) <deviceid> / <method>Extract deviceId and method).

[0356] 2. Matching Process

[0357] a. Parse the request path, separating the path, method name, and parameters.

[0358] b. Query the routing table by priority:

[0359] Prioritize matching entries where the path and method name are exactly the same.

[0360] If no match is found, try wildcards and parameterized rules.

[0361] c. Call the matching processing function, passing in the parsed parameters.

[0362] Step 4, Dynamic Binding System Implementation:

[0363] 1. Binding rule configuration:

[0364] Configuration file format (JSON):

[0365]

[0366] Parameter mapping: Supports extracting data from the source request, reassembling it, and passing it to the target path.

[0367] 2. Runtime binding process:

[0368] The routing core system loads the configuration file during initialization;

[0369] When a request does not match a handler function, the dynamic binder redirects the request according to the configuration;

[0370] Supports hot-update configurations, which take effect without restarting the application.

[0371] Step 5, Middleware processing mechanism:

[0372] 1. Middleware Functions

[0373] Authentication middleware: verifies the legitimacy of the request source (such as user permissions).

[0374] Log middleware: Records request path, parameters, and response time.

[0375] Data validation middleware: Ensures that parameters conform to a preset format (such as numerical range).

[0376] 2. Execution Process

[0377] Middleware forms a processing chain according to the registration order.

[0378] Each middleware can decide whether to continue transmitting the request or terminate it:

[0379] Markdown

[0380] Request → Middleware 1 → Middleware 2 → ... → Target Processing Function

[0381] If any middleware returns an error, the process is immediately terminated and an error message is returned.

[0382] The core idea of ​​this solution is to introduce a routing and forwarding mechanism, transforming communication between GUI components into a path-based request distribution model. By generating a unique route path for each routable component and defining standard request formats and matching strategies, decoupling and flexible communication between components are achieved. Furthermore, the introduction of dynamic binding and middleware mechanisms further enhances the system's configurability and scalability.

[0383] Key steps explained:

[0384] Step 1, Route Identification System Construction:

[0385] Automatic registration and deregistration: By inheriting the RoutableWidget base class, the component automatically generates and registers route paths when it is created, and automatically deregisters when it is destroyed, which greatly simplifies route management.

[0386] Hierarchical path generation: The path generation rules are clear and concise, accurately reflecting the hierarchical structure of components and facilitating location.

[0387] Flexible identifier definition: It uses objectName() by default and allows for customization, providing flexibility.

[0388] The example is clear: the path generation example of MainWindow→DevicePanel→LightController is intuitive and easy to understand.

[0389] Step 2, Defining and parsing route requests:

[0390] The standard request format, rs: / / [path] / [method name]?[parameters], standardizes the communication method and makes the request intent clear.

[0391] Method name and parameters: Clearly distinguishes between operation instructions and parameters, providing a basis for subsequent processing.

[0392] Flexible parameter passing: Supports key-value pairs and nested data (via URL encoding or JSON), meeting the needs of various complex scenarios.

[0393] Parameter parsing rules: Distinguish between path parameters and query parameters, and provide support for different parameter retrieval methods.

[0394] Step 3, Route matching strategy:

[0395] The three-level matching priority combines exact matching, wildcard matching, and parameterized matching, providing powerful routing matching capabilities and enabling flexible handling of various requests.

[0396] The matching process is clear: the logic of parsing requests, querying the routing table by priority, and calling processing functions is clear.

[0397] Step 4, Dynamic Binding System Implementation:

[0398] Configuration file driven: Binding rules are defined using JSON configuration files, enabling dynamic redirection of requests and changing the communication links between components without modifying the code.

[0399] Parameter mapping: It can extract data from the source request, reassemble it and pass it to the target path, which facilitates data conversion and adaptation between components.

[0400] Runtime hot updates: The ability to take effect without restarting the application greatly improves the flexibility and maintainability of the system.

[0401] Step 5, Middleware processing mechanism:

[0402] The middleware is powerful: the introduction of middleware such as authentication, logging, and data validation adds extra processing steps to the system, enabling unified management of cross-cutting concerns.

[0403] Chain of Responsibility Pattern: Middleware forms a processing chain in the order of registration, with each middleware responsible for a specific function, which conforms to the Single Responsibility Principle.

[0404] Flexible process control: Middleware can decide whether to continue passing on the request, providing support for implementing complex business logic.

[0405] Furthermore, the above solution also includes the following innovative features:

[0406] 1. Lifecycle-bound routes

[0407] ο Automatically register / unregister routes through constructors / destructors to ensure that paths are strictly consistent with the component lifecycle.

[0408] 2. Structured Request Definition

[0409] Explicitly declaring method names in the path makes the communication intent clearer (e.g., TurnOn vs SetValue).

[0410] It supports REST-style parameters, enhancing the expressiveness of requests.

[0411] 3. Dynamic redirection capability

[0412] It enables request forwarding through external configuration, decouples code dependencies, and supports flexible adjustments at runtime.

[0413] 4. Unified pretreatment pipeline

[0414] Middleware mechanisms centrally handle common logic, avoiding code duplication.

[0415] 5. Automatic route generation mechanism for component hierarchy

[0416] Unlike traditional routing that requires manual path registration (such as explicit route table registration for iOS module navigation), this solution automatically generates nested route paths (such as rs: / / A / B / C) based on the parent-child hierarchy of components, achieving dynamic construction of route paths. This mechanism solves the maintenance cost problem caused by hard-coded paths in traditional routing and introduces a URL hierarchy structure similar to that of the Web for the first time in the Qt framework.

[0417] 6. Decoupling of dynamic binding and configuration

[0418] Existing dynamic routing solutions (such as the TheRouter framework) rely on compile-time annotations or server-side rules, while this solution dynamically binds routing relationships through runtime configuration files (such as configuring source and destination path mappings in JSON), supporting hot updates of routing rules without recompiling the code. This feature overcomes the limitation that traditional Qt signals and slots must be statically bound during the coding phase.

[0419] 7. Middleware Chain of Responsibility Pattern

[0420] This solution introduces a middleware pipeline similar to web frameworks (such as permission verification and logging) and implements request preprocessing using the chain of responsibility pattern. Compared to Android's TheRouter, which only supports simple interceptors, this solution supports the sequential execution and dynamic expansion of multiple middleware components, and these middleware components can be developed independently of business logic.

[0421] 8. Lifecycle-driven route management

[0422] By automatically registering routes in the component constructor and automatically unregistering them in the destructor, compared to iOS modules which require unified route table registration during application initialization, a strong binding between routes and component lifecycle is achieved, avoiding memory leaks and invalid route residues.

[0423] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of the present invention are not limited to the described order of actions, because according to the embodiments of the present invention, some steps can be performed in other orders or simultaneously. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions involved are not necessarily essential to the embodiments of the present invention.

[0424] Reference Figure 2 The diagram shows a structural block diagram of a request information transmission device provided in an embodiment of the present invention, which may specifically include the following modules:

[0425] The unique route identifier generation module 201 is used to generate unique route identifiers for the nested components at each layer;

[0426] The matching strategy determination module 202 is used to determine the request format of the request information of the nested components at each layer and the matching strategy between the nested components at each layer based on the unique routing identifier.

[0427] The request information transmission module 203 is used to control the transmission of the request information by each layer of the nested components based on the request format and the matching strategy.

[0428] As the device embodiment is basically similar to the method embodiment, the description is relatively simple, and relevant parts can be found in the description of the method embodiment.

[0429] In addition, embodiments of the present invention also provide an electronic device, such as... Figure 3 As shown, it includes a processor 301, a communication interface 302, a memory 303, and a communication bus 304, wherein the processor 301, the communication interface 302, and the memory 303 communicate with each other through the communication bus 304.

[0430] Memory 303 is used to store computer programs;

[0431] When the processor 301 executes the program stored in the memory 303, it implements any of the request information transmission methods described in the above embodiments:

[0432] The communication bus mentioned above can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0433] The communication interface is used for communication between the aforementioned terminal and other devices.

[0434] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0435] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0436] like Figure 4 As shown, in another embodiment of the present invention, a computer-readable storage medium 401 is also provided, which stores instructions that, when executed on a computer, cause the computer to perform the request information transmission method described in the above embodiment.

[0437] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of the present invention.

[0438] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed in this invention can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

[0439] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0440] In the embodiments provided in this application, it should be understood that the disclosed apparatus and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative. For instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between apparatuses or units may be electrical, mechanical, or other forms.

[0441] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0442] In addition, the functional units in the various embodiments of the present invention can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0443] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, essentially, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0444] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.< / method> < / deviceid> < / id:int> < / deviceid> < / devicetype> < / component> < / deviceid:int> < / deviceid:int> < / deviceid> < / deviceid:int> < / deviceid:int> < / deviceid:int> < / deviceid:int> < / deviceid:int> < / deviceid:int> < / deviceid:int> < / deviceid:int>

Claims

1. A method for transmitting request information, characterized in that, The method is applied to a graphical user interface development system for a framework of multi-level nested components, including: For each nested component, generate a unique route identifier; The request format of the request information of the nested components at each layer is determined based on the unique routing identifier, as well as the matching strategy between the nested components at each layer; Based on the request format and the matching strategy, control the nested components at each layer to transmit the request information; The steps of determining the request format of the request information of each nested component based on the unique routing identifier, and the matching strategy between each nested component include: The request path is determined based on the unique routing identifier; Determine the request format and wildcards for each layer of nested components; the request format includes path information of the request path, method name information of each layer of nested components, and parameter information of the request information; A first matching strategy is determined between the nested components at each level based on the path information and the method name information; wherein, the method name information is the name of the component function to be called in the request; A second matching strategy is determined based on the wildcard; Based on the parameter information, a third matching strategy is determined between the nested components in each layer; The method further includes: After all static routes fail to match, and it is determined that the request information conforms to a preset request pattern, other target paths are determined by reading the configuration file; Identify other target sub-components corresponding to the other target paths, and transmit the request information to the other target sub-components based on the other target paths.

2. The method according to claim 1, characterized in that, The step of generating a unique route identifier for each layer of nested components includes: Obtain the lifecycle information of the nested component; A unique route identifier is generated based on the lifecycle information; When the lifecycle of the nested component is determined to have ended based on the lifecycle information, the unique route identifier is deregistered.

3. The method according to claim 1, characterized in that, The step of controlling the transmission of request information by each nested component based on the request format and the matching strategy includes: The root component and target sub-component are determined based on the path information; Based on the first matching strategy, a first routing entry is constructed using the path information and the method name information; When a route entry that is associated with the first route entry is matched in the preset routing table, the root component is controlled to send the parameter information to the target sub-component based on the path information.

4. The method according to claim 3, characterized in that, Also includes: When no route entry with an association with the first route entry is found in the preset routing table, a second route entry is constructed using the wildcard based on the second matching strategy; the second route entry includes paths of the sub-levels under the root component; When a route entry that is associated with the second route entry is matched in the preset routing table, the parameter information is sent based on the path of the sub-level under the root component.

5. The method according to claim 4, characterized in that, Also includes: When no route entry related to the first route entry is found in the preset routing table, and no route entry related to the second route entry is found in the preset routing table, a third route entry is constructed based on the parameter information according to the third matching strategy; the third route entry includes placeholders for the parameter information. When a route entry that is associated with the third route entry is matched in the preset routing table, and the value matched from the path information through the placeholder is an integer, the value is used to generate a processing function to represent the general device status query logic, and the processing function is used to control the root component to send the parameter information to the target sub-component.

6. The method according to claim 1, characterized in that, Also includes: Determine the middleware between the root component and the target sub-component; If any of the middleware returns an error message, the process of transmitting the request information is immediately terminated.

7. A request information transmission device, characterized in that, The apparatus is applied to a graphical user interface development system for a framework of multi-layered nested components, including: The unique route identifier generation module is used to generate unique route identifiers for the nested components at each layer; The matching strategy determination module is used to determine the request format of the request information of the nested components at each layer based on the unique routing identifier, and the matching strategy between the nested components at each layer; The request information transmission module is used to control the transmission of the request information by each layer of the nested components based on the request format and the matching strategy; The steps of determining the request format of the request information of each nested component based on the unique routing identifier, and the matching strategy between each nested component include: The request path is determined based on the unique routing identifier; Determine the request format and wildcards for each layer of nested components; the request format includes path information of the request path, method name information of each layer of nested components, and parameter information of the request information; A first matching strategy is determined between the nested components at each level based on the path information and the method name information; wherein, the method name information is the name of the component function to be called in the request; A second matching strategy is determined based on the wildcard; Based on the parameter information, a third matching strategy is determined between the nested components in each layer; The device further includes: After all static routes fail to match, and it is determined that the request information conforms to a preset request pattern, other target paths are determined by reading the configuration file; Identify other target sub-components corresponding to the other target paths, and transmit the request information to the other target sub-components based on the other target paths.

8. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; The memory is used to store computer programs; When the processor executes a program stored in the memory, it implements the method as described in any one of claims 1-6.

9. A computer-readable storage medium having instructions stored thereon that, when executed by one or more processors, cause the processors to perform the method as described in any one of claims 1-6.

Images