Dynamic rule arrangement method and device, storage medium and terminal

Abstract

The application discloses a dynamic rule arrangement method and device, a storage medium and a terminal. A two-dimensional array is used as a core data model, each array element directly corresponds to a rule unit, a rule expression framework can support multi-dimensional intersection and cell merging. In response to a rule component addition operation of a user and determination of a target position indicated by the operation, a component data object is written into a corresponding array element, interaction and storage are decoupled. Based on a rendering mechanism of the updated two-dimensional array, it is ensured that the view is always the latest projection of the data, rows and columns can be dynamically added or deleted without modifying the rendering logic, and old data is automatically compatible. The method significantly improves the flexibility, maintainability and interactive intuitiveness of rule configuration, and meets the efficient configuration requirements of multi-dimensional intersection rule expression in complex scenarios.

Description

Technical Field

[0001] This application relates to the field of digital configuration technology, and in particular to a dynamic rule arrangement method, apparatus, storage medium and terminal. Background Technology

[0002] Currently, traditional rule configuration often uses static forms or hard-coded rules, relying on one-dimensional object arrays to store rules. This approach has a flat structure and cannot express matrix-type logic such as multi-dimensional intersections and cell merging. Due to the deep coupling between the data model and the view, column expansion or component order adjustment requires simultaneous modification of the front-end and back-end code, resulting in high maintenance costs. At the same time, drag-and-drop functionality only supports row sorting and lacks the WYSIWYG fill experience similar to Excel, leading to inefficient and error-prone configuration of complex rules. Summary of the Invention

[0003] This application provides a dynamic rule arrangement method, apparatus, storage medium, and terminal, which can solve the technical problem of poor digital business management performance in related technologies.

[0004] In a first aspect, embodiments of this application provide a dynamic rule arrangement method, the method comprising: The rule arrangement interface is displayed. The rule arrangement interface uses a two-dimensional array as a data model. Each array element in the two-dimensional array represents a rule unit in the rule arrangement interface. In response to a user operation that adds a target component to a target rule cell in the rule orchestration interface, the target position of the target rule cell in the two-dimensional array is determined. Write the component data object corresponding to the target component to the target location, and render the rule arrangement interface based on the updated two-dimensional array so that the target component is displayed in the target rule unit.

[0005] In one possible implementation, determining the target position of the target rule unit in the two-dimensional array includes: obtaining the row index of the row in the two-dimensional array and the column index of the column in which the target rule unit is located, and using the position determined based on the row index and the column index as the target position.

[0006] In one possible implementation, before writing the component data object corresponding to the target component to the target location, the method further includes: instantiating the target component to generate the component data object corresponding to the target component based on the unique component identifier of the target component.

[0007] In one possible implementation, writing the component data object corresponding to the target component to the target location includes: determining whether an array element already exists at the target location; if it does not exist or is empty, writing it directly; if a non-empty array element already exists, performing an overwrite write operation or an insertion shift operation according to a preset interaction strategy.

[0008] In one possible implementation, rendering the rule arrangement interface based on the updated two-dimensional array includes: traversing each row and column of the updated two-dimensional array, dynamically loading the corresponding target component according to the component data object stored in the array element for each array element, and rendering the loaded target component in the corresponding rule unit.

[0009] In one possible implementation, the aforementioned component data object includes at least a unique component identifier, component attribute value, and component type for the corresponding component; the target component is dynamically loaded from a pre-registered component library based on the aforementioned unique component identifier and / or the aforementioned component type.

[0010] In one possible implementation, the above-mentioned response to the user operation of adding the target component to the target rule unit, determining the target position of the target rule unit in the two-dimensional array, includes: listening to the drag event of dragging the target component from the component selection area to the target rule unit in the rule arrangement interface, and calculating the target position of the target rule unit in the two-dimensional array based on the relative coordinates between the mouse release position and the rule arrangement interface.

[0011] In one possible implementation, the method further includes: when an array element in the two-dimensional array is empty or contains a placeholder, rendering the rule cell corresponding to the array element as a blank cell when rendering the rule arrangement interface.

[0012] In one possible implementation, the method further includes: when multiple array elements with the same component data object are detected to be adjacent in the two-dimensional array, automatically merging the rule units corresponding to the multiple array elements, and calculating the merged row span or column span.

[0013] In one possible implementation, the method further includes: treating each row of the subarray in the two-dimensional array as an independent logical rule unit group; in response to the verification trigger operation, performing an intra-row consistency check on the component data objects stored in each array element of each row of the subarray, and outputting the corresponding verification results for each row.

[0014] Secondly, embodiments of this application provide a dynamic rule arrangement apparatus, the apparatus comprising: The interactive interface display module is used to display the rule arrangement interface. The rule arrangement interface uses a two-dimensional array as a data model. Each array element in the two-dimensional array represents a rule unit in the rule arrangement interface. The component location module is used to determine the target position of the target rule unit in the two-dimensional array in response to the user operation of adding the target component to the target rule unit in the rule orchestration interface. The array update rendering module is used to write the component data object corresponding to the target component into the target position, and render the rule arrangement interface based on the updated two-dimensional array, so that the target component is displayed in the target rule unit.

[0015] Thirdly, embodiments of this application provide a computer storage medium storing a plurality of instructions adapted for loading by a processor and executing the steps of the method described above.

[0016] Fourthly, embodiments of this application provide a terminal, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is adapted to be loaded by the processor and to execute the steps of the above-described method.

[0017] The beneficial effects of the technical solutions provided in some embodiments of this application include at least the following: This application provides a dynamic rule arrangement method, displaying a rule arrangement interface. The rule arrangement interface uses a two-dimensional array as its data model, where each array element represents a rule unit within the interface. In response to a user operation adding a target component to a target rule unit in the rule arrangement interface, the system determines the target position of the target rule unit within the two-dimensional array. The component data object corresponding to the target component is written to the target position, and the rule arrangement interface is rendered based on the updated two-dimensional array, so that the target component is displayed within the target rule unit. Firstly, when displaying the rule arrangement interface, the system proactively constructs a rule arrangement interface with a two-dimensional array as its underlying data model. Each array element in the two-dimensional array is explicitly represented as a rule unit within the interface. By changing the organization of the rule data, leveraging the inherent row and column geometry of the two-dimensional array, each row can independently express a complete set of conditions, and each column corresponds to the same type of attribute or operator, thus supporting the intuitive presentation of complex cross-rules. Simultaneously, since there is a one-to-one correspondence between rule units and array elements, any user edits to the interface can be precisely located at a specific index, facilitating rule expansion. Next, the system responds to the user's action of adding a target component to a target rule cell in the interface and determines the target position of that rule cell in a two-dimensional array. During this process, the user does not directly manipulate the array or write code, but rather performs simple operations such as selecting the target cell, allowing the system to complete the mapping from the visual unit to the underlying storage coordinates. Based on this mechanism, the system decouples interactive behavior from data storage structure. Furthermore, the positioning method based on two-dimensional arrays is more accurate and repeatable; as long as the rule cell's identifier remains unchanged, its target position can be uniquely determined, thus ensuring operational consistency. Finally, the system writes the component data object corresponding to the target component to the determined target position and re-renders the rule orchestration interface based on the updated two-dimensional array, so that the target component is ultimately displayed in the target rule cell initially selected by the user. In this step, because the data and view are entirely driven by a two-dimensional array, the component's position can be changed simply by modifying the array index. The configuration and rendering process does not involve modifying the rendering logic or backend interface, significantly improving the flexibility, maintainability, and intuitiveness of rule configuration, and meeting the efficient configuration requirements for multi-dimensional cross-rule expressions in complex scenarios. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application 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 this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 An exemplary system architecture diagram of a dynamic rule orchestration method provided in this application embodiment; Figure 2 A flowchart illustrating a dynamic rule arrangement method provided in an embodiment of this application; Figure 3 A flowchart illustrating a dynamic rule arrangement method provided in an embodiment of this application; Figure 4 A structural block diagram of a dynamic rule arrangement device provided in an embodiment of this application; Figure 5 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. Detailed Implementation

[0020] To make the features and advantages of this application more apparent and understandable, the technical solutions in the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] In the following description, when referring to the accompanying drawings, unless otherwise indicated, the same numbers in different drawings represent the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims. Furthermore, in the description of the embodiments of this application, unless otherwise stated, " / " means "or," for example, A / B can mean A or B; the word "and / or" in the text is merely a description of the relationship between related objects, indicating that three relationships can exist, for example, A and / or B can represent: A alone, A and B simultaneously, and B alone. Additionally, in the description of the embodiments of this application, "multiple" refers to two or more.

[0022] Hereinafter, the terms "first" and "second" are used for descriptive purposes only and should not be construed as implying or suggesting relative importance or implicitly indicating the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature.

[0023] In digital business management systems, configuring scoring rules, defining risk control strategies, and orchestrating approval processes are high-frequency and critical development tasks. Traditional implementations typically rely on static form lists or hard-coded configuration files. This involves pre-defining fixed fields and layout structures in the front-end code, with the back-end receiving fixed-format JSON objects (JSON is a lightweight data exchange format, short for JavaScript Object Notation; these files have the .json extension and are widely used in web applications, API interfaces, and configuration files). This design approach meets basic needs when business rules are simple, the number of columns is stable, and the logic is linear. However, as business complexity increases, rules gradually exhibit characteristics such as multi-dimensional intersections, dynamic expansion, and nested combinations. For example, risk control scoring cards need to determine scores based on the intersection of "income range" and "age range," or marketing campaigns require configuring multi-condition combination discount matrices. These scenarios naturally have a two-dimensional table format, while traditional one-dimensional arrays or fixed key-value pairs cannot accurately express the correspondence between "rows" and "columns," nor can they support operations like merging cells or dynamically adding / removing rows and columns, similar to those in Excel.

[0024] In existing technological models, developers often assume that rule entries are linear and enumerable during the design process, thus using Arrays. <object>The structure, where each object represents a rule and the object's key corresponds to a fixed column name, essentially hardcodes "column dimensions" as object attribute names. This means that adding, deleting, or rearranging columns requires simultaneous modifications to both the front-end and back-end code, as well as the database table structure, resulting in poor scalability. Furthermore, the front-end rendering logic directly maps the data model to form rows, with component types, positions, and numbers bound to specific business fields, creating a high degree of coupling between data and view. When the business side requests to insert a new conditional component between two columns, the entire rendering process must be redesigned, and compatibility between the old and new data structures must be manually maintained. This repetitive and inefficient development model severely slows down the response time to requirements.

[0025] From an impact perspective, firstly, the maintainability of the system is significantly reduced. Every change to business rules can trigger multiple modifications to the front-end, back-end, and even the database, easily introducing inconsistent data errors. Furthermore, the user experience is significantly constrained; users cannot freely drag and drop components, dynamically add or delete rows and columns, or adjust the order of rules like in a spreadsheet. They must fill out lengthy forms one by one, making the configuration of complex rules inefficient and error-prone. In addition, the system's applicability is severely limited. For scoring cards, decision trees, or risk control matrices requiring multi-dimensional cross-judgments, traditional solutions often have to resort to workarounds (such as predefining a large number of redundant columns), resulting in bloated and difficult-to-understand code structures. Therefore, this application provides a dynamic rule orchestration method to solve the above-mentioned technical problems.

[0026] Please see Figure 1 , Figure 1 An exemplary system architecture diagram of a dynamic rule orchestration method provided in this application embodiment.

[0027] like Figure 1 As shown, the system architecture may include a terminal 101, a network 102, and a server 103. The network 102 serves as the medium for providing a communication link between the terminal 101 and the server 103. The network 102 may include various types of wired or wireless communication links, such as wired communication links including fiber optic cables, twisted-pair cables, or coaxial cables, and wireless communication links including Bluetooth communication links, Wireless-Fidelity (Wi-Fi) communication links, or microwave communication links, etc.

[0028] Terminal 101 can interact with server 103 via network 102 to receive messages from or send messages to server 103. Alternatively, terminal 101 can interact with server 103 via network 102 to receive messages or data sent to server 103 by other users. Terminal 101 can be hardware or software. When terminal 101 is hardware, it can be various electronic devices, including but not limited to smartwatches, smartphones, tablets, laptops, and desktop computers. When terminal 101 is software, it can be installed in the aforementioned electronic devices and can be implemented as multiple software programs or software modules (e.g., to provide distributed services) or as a single software program or software module; no specific limitation is made here.

[0029] In this embodiment, the front-end interactive interface of the terminal 101 first displays a rule arrangement interface. The rule arrangement interface uses a two-dimensional array as a data model, and each array element in the two-dimensional array represents a rule unit in the rule arrangement interface. When the user has a rule configuration requirement, the terminal 101 responds to the user operation of adding the target component to the target rule unit in the rule arrangement interface and determines the target position of the target rule unit in the two-dimensional array. Based on this, the terminal 101 writes the component data object corresponding to the target component to the target position and renders the rule arrangement interface based on the updated two-dimensional array so that the target component is displayed in the target rule unit.

[0030] Server 103 can be a server that provides various services. It should be noted that server 103 can be hardware or software. When server 103 is hardware, it can be implemented as a distributed server cluster consisting of multiple servers, or as a single server. When server 103 is software, it can be implemented as multiple software programs or software modules (e.g., used to provide distributed services), or as a single software program or software module; no specific limitations are made here.

[0031] Alternatively, the system architecture may not include server 103. In other words, server 103 may be an optional device in the embodiments of this specification. That is, the method provided in the embodiments of this specification can be applied to a system structure that only includes terminal 101. The embodiments of this application do not limit this.

[0032] It should be understood that Figure 1 The number of terminals, networks, and servers shown is only illustrative; the number can be any number of terminals, networks, and servers depending on the implementation requirements.

[0033] Please see Figure 2 , Figure 2 This is a flowchart illustrating a dynamic rule orchestration method provided in an embodiment of this application. The execution entity in this embodiment can be a terminal executing dynamic rule orchestration, a processor within the terminal executing the dynamic rule orchestration method, or a dynamic rule orchestration service within the terminal executing the dynamic rule orchestration method. For ease of description, the following example uses a processor within the terminal as the execution entity to illustrate the specific execution process of the dynamic rule orchestration method.

[0034] like Figure 2 As shown, dynamic rule orchestration methods can include at least: S202. Display the rule arrangement interface. The rule arrangement interface uses a two-dimensional array as the data model. Each array element in the two-dimensional array represents a rule unit in the rule arrangement interface.

[0035] Optionally, to support users in orchestrating rules through intuitive interactive operations, the terminal can present a visual rule orchestration interface on the display screen. In traditional layout modes using fixed forms or one-dimensional lists, the interface display (such as the number of columns and component positions) is often hardcoded into the underlying code logic. Every time a user performs rule orchestration (such as adding a column weight or adjusting the component order), both the backend data structure and the frontend rendering logic need to be modified simultaneously. Furthermore, this mode typically only uses one-dimensional arrays of objects. <object>The flat data structure of storage rules is often insufficient to express complex cell merging, nesting rules, or multi-dimensional intersection rules, making it inadequate for handling matrix data similar to Excel. To address this issue, this application uses a matrix-style table as the primary visual form, providing users with a spreadsheet-like rule arrangement operation area. At the underlying data level, this rule arrangement interface does not directly couple the interface state and business data through hard coding, but instead uses a two-dimensional array as the core data model. A two-dimensional array is essentially an array of arrays, i.e., an "array of arrays," with the type specifier "array name [constant expression][constant expression]". For example, a two-dimensional array A with m rows and n columns is represented as A[m][n]. In this embodiment of the application, considering the natural structural isomorphism between the two-dimensional array and the table view, the row and column indices of the array can be directly mapped to the row and column positions in the view. Therefore, each row of the subarray of the two-dimensional array in the underlying data structure can be mapped to a row in the view table, each column can be mapped to a column in the view table, and each array element can be mapped to a unique rule unit in the interface (i.e., a cell in the view table), thereby achieving a precise correspondence between the backend data model and the frontend interface presentation.

[0036] For example, to facilitate understanding, we can assume a two-dimensional array represented as matrix[i][j], where i is the row index and j is the column index. Each array element matrix[i][j] stores a component data object, which describes all the configuration information of the rule component to be presented in the corresponding rule unit. By organizing data using a two-dimensional matrix, business rules are expressed as a structured table with row logic and column semantics. Each row carries a complete set of condition combinations or rule entries, and each column represents a fixed attribute or operator within the rule. Understandably, this structure naturally supports the expression of multi-dimensional cross-rules. For example, in a risk control scoring scenario, "income range" can be used as the row dimension, "age range" as the column dimension, and the array elements at the intersection points store the corresponding scoring components, thus presenting the scoring card matrix in the most intuitive way.

[0037] Furthermore, upon initial loading, the rule orchestration interface can generate a blank table with several rows and columns based on a preset business scenario template. Each rule unit in the blank table corresponds to a null value or placeholder in the underlying two-dimensional array, appearing as a blank cell during rendering, awaiting user input. As the user adjusts the number of rows or columns in the interface, the two-dimensional array synchronously expands or contracts accordingly. For example, it adds elements to the end of each row to add a new column, or adds a subarray to add a new row. This data-view synchronization mechanism ensures that the underlying data model accurately reflects the current state of the interface layout. Therefore, when using two-dimensional arrays for rule orchestration, the system can support dynamic expansion without reconstructing the entire data structure.

[0038] S204. In response to the user operation of adding the target component to the target rule cell in the rule orchestration interface, determine the target position of the target rule cell in the two-dimensional array.

[0039] Optionally, when a user wants to place a component in a specific rule cell in the rule arrangement interface, the addition operation can be achieved through various interactive methods. For example, the user can select the desired component from the component selection area provided in the sidebar of the interface and drag it to the target rule cell in the table; or, the user can also select a blank rule cell by clicking and then confirming the selection from the pop-up component selection list. Regardless of the interactive form used, the core is to support the user in specifying two pieces of information to the system: (1) the target component that is currently being added; and (2) the target rule cell in the rule arrangement interface where the target component is to be placed.

[0040] Optionally, in response to this user action, the system needs to map the position of the rule unit selected by the user to the corresponding row and column index positions in the underlying two-dimensional array. Specifically, when the user positions the target component to the target rule unit in the i-th row and j-th column of the interface by clicking or dragging, the system captures the position information of the target rule unit in the table layout through an event listener mechanism, and then parses out the row index i and column index j of the target rule unit in the two-dimensional array. The row index and column index together determine the unique coordinate identifier of the target rule unit in the two-dimensional array, and its corresponding position is the target position of the target rule unit in the two-dimensional array. In this mapping process, since each visual rule unit in the rule arrangement interface is pre-bound to a specific index position in the two-dimensional array, the row and column index corresponding to a given rule unit remains unchanged no matter how the interface scrolls, zooms, or partially refreshes, thus ensuring the accuracy and consistency of the positioning operation.

[0041] For example, in one feasible implementation, the system can bind custom data attributes to each rule unit (i.e., each table cell) in the interface. These attributes store the row and column indices corresponding to that rule unit. When a user triggers an add operation, the event handler function can directly read these index values ​​from the event target element, thereby quickly and accurately determining the target location. This implementation avoids the overhead of additional coordinate calculations or DOM (Document Object Model) traversal, improving interactive response efficiency.

[0042] S206. Write the component data object corresponding to the target component to the target location, and render the rule arrangement interface based on the updated two-dimensional array so that the target component is displayed in the target rule unit.

[0043] Optionally, after determining the target component and its row and column indices, the system first instantiates the target component. Specifically, based on the target component's type information or unique identifier, the system retrieves the component's configuration template from a pre-registered component library and generates a complete component data object by combining it with the context information of the current rule unit. This component data object is a structured description of the component's presentation and behavioral logic within the rule unit, and includes at least the component's unique identifier, component attribute values, component type, style configuration, and relationships with other components. It should be noted that the component data object is only an abstract description of the component's state and does not contain specific implementation details related to interface rendering, thus ensuring a clear separation between data and view.

[0044] Furthermore, the system writes the generated component data objects into the underlying two-dimensional array at the positions determined by the aforementioned row and column indices. The write operation essentially assigns values ​​to array elements, storing the component data object at the specified array index. During the write operation, the system first checks if an array element already exists at the target position. If the position was previously empty or a placeholder, a new component data object is directly written. If the position already contains a component data object, the system can replace the old component with the new one by overwriting it. After this assignment operation, the state of the two-dimensional array is updated to reflect the component configuration of all current rule units. It's important to note that the two-dimensional array always serves as the sole data source throughout this process; all changes in the interface state are implemented by modifying the two-dimensional array. This single and stable data source design ensures the clarity and traceability of data flow.

[0045] Furthermore, after the two-dimensional array is updated, the system triggers a complete interface rendering process. The renderer traverses each row and column of the updated two-dimensional array. For each array element, the renderer dynamically loads the corresponding target component based on the component data object stored in that element. Specifically, the renderer first parses the type identifier in the component data object, then finds and instantiates a component instance of the corresponding type from the pre-registered component library, passes the attribute values ​​from the component data object to the component instance for configuration, and finally mounts the rendered component to the rule cell at the corresponding row and column position in the rule orchestration interface. This traversal rendering mechanism ensures that each array element in the two-dimensional array can be accurately visually presented on the interface, and that the view structure of the rendering result always corresponds one-to-one with the underlying data structure. Thus, through this closed-loop process of data modification and view refresh, the user's operation of adding a component is directly transformed into the successful display of the target component in the target rule cell. Since the entire process is driven entirely by the two-dimensional array, any addition, deletion, or modification operation of a rule component only requires modifying the element at the corresponding position in the array, without the need to maintain the interface state or synchronize multiple data copies. At the same time, this design also allows subsequent adjustments to the rules to be achieved through simple array operations without rewriting complex rendering logic or backend interfaces, significantly improving the flexibility and maintainability of the rule orchestration system, enabling business personnel to efficiently build complex matrix rule configurations through simple interactive operations.

[0046] In this embodiment, a dynamic rule arrangement method is provided, which displays a rule arrangement interface. The rule arrangement interface uses a two-dimensional array as its data model, and each array element in the two-dimensional array represents a rule unit in the rule arrangement interface. In response to a user operation that adds a target component to a target rule unit in the rule arrangement interface, the target position of the target rule unit in the two-dimensional array is determined. The component data object corresponding to the target component is written to the target position, and the rule arrangement interface is rendered based on the updated two-dimensional array so that the target component is displayed in the target rule unit. First, when displaying the rule arrangement interface, the system actively constructs a rule arrangement interface with a two-dimensional array as the underlying data model. Each array element in the two-dimensional array is explicitly represented as a rule unit in the interface. By changing the organization of the rule data, relying on the inherent row and column geometry of the two-dimensional array, each row can independently express a complete set of conditions, and each column corresponds to the same type of attribute or operator, thereby supporting the intuitive presentation of complex cross rules. At the same time, since there is a one-to-one correspondence between the rule unit and the array element, any edits made by the user to the interface can be accurately located at a specific position index, which facilitates the expansion of rules. Next, the system responds to the user's action of adding a target component to a target rule cell in the interface and determines the target position of that rule cell in a two-dimensional array. During this process, the user does not directly manipulate the array or write code, but rather performs simple operations such as selecting the target cell, allowing the system to complete the mapping from the visual unit to the underlying storage coordinates. Based on this mechanism, the system decouples interactive behavior from data storage structure. Furthermore, the positioning method based on two-dimensional arrays is more accurate and repeatable; as long as the rule cell's identifier remains unchanged, its target position can be uniquely determined, thus ensuring operational consistency. Finally, the system writes the component data object corresponding to the target component to the determined target position and re-renders the rule orchestration interface based on the updated two-dimensional array, so that the target component is ultimately displayed in the target rule cell initially selected by the user. In this step, because the data and view are entirely driven by a two-dimensional array, the component's position can be changed simply by modifying the array index. The configuration and rendering process does not involve modifying the rendering logic or backend interface, significantly improving the flexibility, maintainability, and intuitiveness of rule configuration, and meeting the efficient configuration requirements for multi-dimensional cross-rule expressions in complex scenarios.

[0047] Please see Figure 3 , Figure 3 This is a flowchart illustrating a dynamic rule arrangement method provided in an embodiment of this application.

[0048] like Figure 3 As shown, dynamic rule orchestration methods can include at least: S302. Display the rule arrangement interface. The rule arrangement interface uses a two-dimensional array as the data model. Each array element in the two-dimensional array represents a rule unit in the rule arrangement interface.

[0049] Regarding step S302, its specific implementation is consistent with the aforementioned step S202. After the terminal starts the rule arrangement function, it presents a rule arrangement interface with a matrix-like table as its main component on the interactive display screen. This interface uses a two-dimensional array as its underlying data model, and each element in the array corresponds one-to-one with a rule unit (i.e., a table cell) in the interface. Based on the isomorphic mapping relationship between this data model and the view, all subsequent operations such as adding components, adjusting their positions, and expanding rows and columns can be completed by modifying the two-dimensional array, and the data state is synchronously reflected in the interface view by a unified rendering mechanism. Based on this, for a detailed description of the implementation process and beneficial effects of this step, please refer to the detailed description in step S202, which will not be repeated here.

[0050] S304. Listen for the drag event when the target component is dragged from the component selection area to the target rule cell in the rule arrangement interface, and calculate the target position of the target rule cell in the two-dimensional array based on the relative coordinates between the mouse release position and the rule arrangement interface.

[0051] Optionally, in the rule arrangement interface, users can add components to specific rule cells through intuitive drag-and-drop interaction. In this embodiment, the display interface layout can be divided into two functional areas: a left and a right. The left side is the component selection area (i.e., the component library panel), which centrally displays icons or preview cards of various components available for user selection, such as input box components, dropdown selection box components, numerical comparison operator components, and logical connector components. The right side is the arrangement area, i.e., the aforementioned rule arrangement table using a two-dimensional array as the data model. When constructing rules, users can directly select the desired target component from the left component selection area, drag it with the mouse to the desired target rule cell in the right arrangement area, and release the mouse to complete a component addition operation. This drag-and-drop interaction is highly consistent with the operation habits of spreadsheets, significantly reducing the user's learning cost and operational burden.

[0052] Furthermore, at the technical implementation level, the system needs to accurately capture the user's dragging behavior and precisely parse the row and column indices of the target position. Specifically, the system listens for drag-start events (such as mousedown or dragstart events) in the component selection area. When the user begins dragging, the system records the identification information of the dragged target component. During the dragging process, the system continuously listens for mouse movement events, and when the user drags the component above the main layout area, it calculates in real time the relative offset between the current mouse position and the top and left edges of the main layout area. Based on this relative offset and the width and height of each rule unit (i.e., table cell), the system can calculate and determine the row and column indices corresponding to the mouse release position. After determining the row and column indices, the system uses the position jointly determined by both as the target position, providing a precise array index basis for subsequent component data writing operations.

[0053] S306. Based on the unique component identifier of the target component, instantiate the target component to generate the corresponding component data object.

[0054] Optionally, after determining the target component and its location through the aforementioned drag-and-drop interaction, the system needs to convert the target component into a structured data format that can be stored and rendered. This involves executing the component instantiation process based on the target component's unique component identifier. Specifically, the system continuously maintains a global component registry (i.e., a component library). This registry stores the definition information of all available components in key-value pairs, where the key is the component's unique component identifier, and the value is the corresponding component configuration template or constructor function. Therefore, when a drag-and-drop event targeting a target component is detected, the system uses the component's unique component identifier as an index to search for the corresponding component definition in the component registry, and then calls the component factory method or constructor to create a component instance of the target component.

[0055] Furthermore, this instantiation process generates a lightweight, framework-independent component data object for the target component. This component data object is a structured description of the component's state, containing at least a unique component identifier, component attribute values, and component type. The unique component identifier is used to accurately locate the specific user interface component to be loaded in subsequent rendering stages; the component attribute values ​​record the component's specific configuration data within a specific rule unit, such as the default text of an input box, the currently selected value of a dropdown list, and the comparison type of numerical comparison operators; the component type indicates the category to which the component belongs, such as basic input, logical operation, or flow control, allowing the renderer to group or differentiate it. By instantiating components as abstract data objects rather than concrete view instances, the system decouples business data from the interface view. Component data objects can be stored, transmitted, and persisted without relying on any specific UI framework, and the same component data object can be parsed and rendered into corresponding visual components in different front-end rendering environments.

[0056] S308. Write the component data object corresponding to the target component to the target location.

[0057] Optionally, after generating the component data object corresponding to the target component, the system needs to write it to the target position in the underlying two-dimensional array, determined by the row and column indices. In actual implementation, this write operation can select an appropriate write strategy based on the current data state of the target position and the user's expected behavior.

[0058] Specifically, the system first checks if an array element already exists at the target location. If the location is currently empty, or if an empty element marked as a placeholder exists, the system determines that the location is available and idle, and the generated component data object is directly assigned to that array element. If a non-empty component data object already exists at the target location, it means that the rule unit has been occupied by another component. In this case, the system needs to decide how to handle this conflict according to a preset interaction strategy. In one feasible implementation, the system can adopt an overwrite strategy, that is, directly replace the original component data object at the target location with the new component data object, and the original component data object is discarded. This strategy is suitable for scenarios where users want to change existing components in a rule unit, and the interaction is simple and direct. In another feasible implementation, the system can adopt an insertion and shift strategy, that is, write the new component data object to the target location, and at the same time shift all elements at the original location and after it one position to the right, similar to the operation of inserting a new element in an array. This strategy is suitable for scenarios where users want to insert a new component between two existing rule units without overwriting the original content, and can maintain the integrity of existing data while adding new data. The system can dynamically adjust the writing strategy based on the current interaction mode or the user's pre-configured preferences in the settings. Through this flexible writing mechanism, the system can ensure the security of data operations while also providing users with a diverse orchestration experience.

[0059] S310. Traverse each row and column of the updated two-dimensional array. For each array element, dynamically load the corresponding target component based on the component data object stored in the array element, and render the loaded target component in the corresponding rule unit.

[0060] Optionally, after writing the component data object to the two-dimensional array, the system needs to synchronously reflect the updated data state on the visual presentation of the rule orchestration interface. During rendering, the system first iterates through each row of the updated two-dimensional array using the outer loop, and then iterates through each array element in each row using the inner loop. For each array element encountered, the system first checks whether it is an empty value or a placeholder. If it is empty, a blank cell is rendered in the corresponding rule unit; if it is not empty, the previously stored component data object is read from it. Subsequently, the system dynamically loads the corresponding user interface component based on the information in the component data object. During this dynamic loading process, the system uses a unique component identifier as the primary index to search for the corresponding component definition in the pre-registered component library. This component library is a global resource collection initialized at system startup, which registers all user interface components available for orchestration, including but not limited to numeric input box components, drop-down selection box components, numeric comparison operator components (such as greater than, less than, equal to, etc.), logical connector components (such as AND, OR, NOT, etc.), and conditional branch components. Each component is registered with a unique component identifier as the key, and the corresponding component class, rendering function, or asynchronous loader as the value. By decoupling the component identifier from the specific implementation, the system can flexibly add, replace, or upgrade any component in the component library without modifying the rendering logic, achieving high scalability.

[0061] Furthermore, after obtaining the corresponding component definition, the system passes in the attribute values ​​from the component data object as initial configuration parameters, instantiates or renders the user interface component, and finally mounts the rendered component into the rule cell at the corresponding row and column position in the rule orchestration interface. It is understood that in this embodiment, the rendering process is data-driven; the renderer itself does not contain any judgments regarding business logic or rule semantics, but rather acts as a medium for converting structured data in a two-dimensional array into interface components. This design ensures the purity and testability of the rendering logic, while also allowing users to perform various modifications to the interface, including adding, deleting, and modifying components, expanding and shrinking rows and columns, etc., simply by modifying the two-dimensional array without involving the renderer's internal implementation.

[0062] S312. When multiple array elements with the same component data object are detected to be adjacent in a two-dimensional array, the rule cells corresponding to the multiple array elements are automatically merged, and the row span or column span of the merged array is calculated.

[0063] Optionally, in practical business scenarios involving matrix-type rule arrangement, it is often necessary to merge multiple adjacent rule units with the same configuration to form a large cell spanning multiple rows or columns, thereby visually expressing the rule hierarchy or structure. For example, in a scorecard configuration scenario, if all rows in a column use the same operator component (such as all using the "greater than" operator), adjacent cells with the same operator configuration in that column can be merged into a single cell spanning multiple rows, making the interface more concise and clear. To achieve this effect, this application embodiment introduces an intelligent detection and merging mechanism for sparse matrices and adjacent repeating elements during the rendering process.

[0064] Specifically, before traversing the two-dimensional array and rendering each rule cell, the system first performs a pre-scan process. During the pre-scan, the system checks whether adjacent columns in each row have the same component data object, that is, the unique component identifier, component type, and core attribute value are the same. If so, these adjacent array elements are marked as mergeable; similarly, the system can also check whether adjacent rows in the same column meet the same conditions. When consecutive adjacent elements that meet the conditions are detected, the system automatically merges the multiple rule cells corresponding to these array elements visually into a single rule cell and calculates the row span or column span of the merged cell. For example, if the array elements at the three consecutive positions of row 2, column 3, row 3, column 3, and row 4 all store the same "greater than" operator component and are vertically adjacent to each other, the system can merge these three rule cells into a cell spanning three rows, with a column span of 1 and a row span of 3. The calculation result of the merging information is appended to the rendering instructions so that the final table can correctly display the boundaries and size of the merged cells. This automatic merging mechanism enhances the expressiveness and flexibility of the rule arrangement interface, allowing users to obtain a beautiful matrix display effect without manually adjusting the table style.

[0065] S314. Treat each row of the subarray in the two-dimensional array as an independent logical rule unit group; in response to the verification trigger operation, perform in-row consistency verification on the component data objects stored in each array element of each row of the subarray, and output the verification results corresponding to each row.

[0066] Optionally, during the rule orchestration process, the system also needs to ensure that each presented rule is logically consistent and semantically complete to guarantee that these rules can be correctly implemented. Since each row of the subarray in the two-dimensional array data model used in this application embodiment carries all the components required to constitute a complete rule, each row of the subarray can be treated as an independent logical rule unit group to perform rule consistency verification.

[0067] Specifically, users can actively trigger the verification process by clicking the "Verification Rules" button on the interface, or the system can automatically trigger the verification process when saving rule configurations. When the system receives a verification trigger operation, it first scans each subarray in the two-dimensional array one by one. For each row, the system will check, according to the preset verification rule template, whether the component data object stored in each array element in the row meets the expected type, whether it is missing the necessary attribute values, and whether the combination of components in the row meets the business logic constraints. For example, for a rule row configured as "If [field A] [greater than]

[100] then [add 10 points]", the system will check it sequentially according to the verification rules corresponding to each element: whether the first element is a valid field selection component and a valid field has been selected; whether the second element is a comparison operator component and a valid operator has been selected; whether the third element is a numeric input component and a valid numeric value has been entered; and whether the fourth element is a score component and the score is within the allowed range. If the configuration of all components in a row meets the requirements, the row is marked as valid. Otherwise, if there are missing values, type mismatches, or logical contradictions, the corresponding validation result will clearly indicate the abnormal component and the specific exception information.

[0068] Furthermore, after the verification is completed, the system summarizes the verification results of all rows and generates a structured verification report for the user. For rows that fail verification, the system can highlight the corresponding row number or rule unit on the interface and attach specific error messages to guide the user in making corrections. Through the intra-row consistency verification mechanism, the system can help users discover and correct potential configuration errors during the rule configuration stage, avoiding business execution anomalies caused by incomplete or contradictory rule semantics, and significantly improving the accuracy and reliability of rule configuration.

[0069] This application provides a dynamic rule orchestration method. Based on a two-dimensional array data model and a data-driven rendering mechanism, it further implements precise drag-and-drop positioning based on coordinate calculation; flexible writing strategies for component instantiation and data object generation based on unique identifiers, overwriting and insertion; a dynamic loading and rendering mechanism based on a component library; automatic merging of adjacent identical elements; and in-row logical consistency verification. This constructs a complete, flexible, and highly maintainable dynamic rule orchestration solution. Through this application's solution, users can obtain a WYSIWYG rule configuration experience. The system supports flexible construction from simple row lists to complex multi-dimensional cross-rule matrices, significantly improving the interactive efficiency, data maintainability, and accuracy of business semantic expression in rule configuration.

[0070] Please see Figure 4 , Figure 4 This is a structural block diagram of a dynamic rule arrangement device provided in an embodiment of this application. Figure 4 As shown, the dynamic rule arrangement device 400 includes: The interactive interface display module 410 is used to display the rule arrangement interface. The rule arrangement interface uses a two-dimensional array as a data model. Each array element in the two-dimensional array represents a rule unit in the rule arrangement interface. The component location module 420 is used to determine the target position of the target rule unit in the two-dimensional array in response to the user operation of adding the target component to the target rule unit in the rule orchestration interface; The array update rendering module 430 is used to write the component data object corresponding to the target component to the target position, and arrange the interface based on the updated two-dimensional array rendering rules so that the target component is displayed in the target rule unit.

[0071] Optionally, the component location module 420 is also used to obtain the row index corresponding to the row of the target rule unit in the two-dimensional array and the column index corresponding to the column, and use the position determined based on the row index and column index as the target position.

[0072] Optionally, the dynamic rule orchestration device 400 further includes a component instantiation module, which is used to instantiate the target component and generate a component data object corresponding to the target component based on the unique component identifier of the target component.

[0073] Optionally, the array update rendering module 430 is also used to determine whether an array element already exists at the target position. If it does not exist or there is an empty value, it is written directly. If a non-empty array element already exists, an overwrite write operation or an insertion shift operation is performed according to a preset interaction strategy.

[0074] Optionally, the array update rendering module 430 is also used to traverse each row and column of the updated two-dimensional array. For each array element, the corresponding target component is dynamically loaded according to the component data object stored in the array element, and the loaded target component is rendered in the corresponding rule unit.

[0075] Optionally, the component data object includes at least the unique component identifier, component attribute value, and component type of the corresponding component; the target component is dynamically loaded from the pre-registered component library based on the unique component identifier and / or component type.

[0076] Optionally, the component positioning module 420 is also used to listen for drag events when a target component is dragged from the component selection area to the target rule unit in the rule arrangement interface, and to calculate the target position of the target rule unit in the two-dimensional array based on the relative coordinates between the mouse release position and the rule arrangement interface.

[0077] Optionally, the dynamic rule arrangement device 400 further includes an empty cell configuration module, which is used to render the rule unit corresponding to the array element as a blank cell when rendering the rule arrangement interface, when the array element in the two-dimensional array is empty or contains a placeholder.

[0078] Optionally, the dynamic rule arrangement device 400 further includes a cross-row and cross-column configuration module, which is used to automatically merge the rule units corresponding to the multiple array elements when multiple array elements with the same component data objects are detected to be adjacent in the two-dimensional array, and calculate the row span or column span after merging.

[0079] Optionally, the dynamic rule orchestration device 400 further includes: a front-end verification module, which treats each row of the subarray in the two-dimensional array as an independent logical rule unit group; in response to the verification trigger operation, performs in-row consistency verification on the component data objects stored in each array element in each row of the subarray, and outputs the verification results corresponding to each row.

[0080] In this embodiment, a dynamic rule arrangement device is provided, comprising: an interactive interface display module for displaying a rule arrangement interface, wherein the rule arrangement interface uses a two-dimensional array as a data model, and each array element in the two-dimensional array represents a rule unit in the rule arrangement interface; a component position positioning module for determining the target position of the target rule unit in the two-dimensional array in response to a user operation of adding a target component to the target rule unit in the rule arrangement interface; and an array update rendering module for writing the component data object corresponding to the target component to the target position and rendering the rule arrangement interface based on the updated two-dimensional array, so that the target component is displayed in the target rule unit. Firstly, when displaying the rule arrangement interface, the system actively constructs a rule arrangement interface with a two-dimensional array as the underlying data model, where each array element in the two-dimensional array is explicitly represented as a rule unit in the interface. By altering the organization of rule data and leveraging the inherent row and column geometry of two-dimensional arrays, each row can independently express a complete set of conditions, while each column corresponds to the same type of attribute or operator, thus supporting the intuitive presentation of complex cross-rules. Simultaneously, since a one-to-one correspondence exists between rule units and array elements, any user edits to the interface can be precisely located at a specific index, facilitating rule expansion. Next, the system responds to the user's action of adding a target component to a target rule unit in the interface and determines the target position of that rule unit in the two-dimensional array. During this process, the user does not directly manipulate the array or write code, but performs simple operations such as selecting the target cell, allowing the system to complete the mapping from visual units to underlying storage coordinates. Based on this mechanism, the system decouples interactive behavior from data storage structure. Furthermore, the positioning method based on two-dimensional arrays is more precise and repeatable; as long as the rule unit's identifier remains unchanged, its target position can be uniquely determined, ensuring operational consistency. Finally, the system writes the component data object corresponding to the target component into the determined target location and re-renders the rule orchestration interface based on the updated two-dimensional array, so that the target component is finally displayed in the target rule unit initially selected by the user. In this step, since the data and view are entirely driven by the two-dimensional array, the component's position can be changed simply by modifying the array index. The configuration and rendering process does not involve modifying the rendering logic or backend interface, significantly improving the flexibility, maintainability, and intuitiveness of rule configuration, and meeting the efficient configuration requirements for multi-dimensional cross-rule expression in complex scenarios.

[0081] This application provides a computer program product containing instructions that, when run on a computer or processor, cause the computer or processor to perform the steps of any of the methods described in the above embodiments.

[0082] This application also provides a computer storage medium that can store multiple instructions adapted for loading by a processor and executing the steps of any of the methods described in the above embodiments.

[0083] Please see Figure 5 , Figure 5 This is a schematic diagram of the structure of a terminal provided in an embodiment of this application. Figure 5 As shown, terminal 500 may include: at least one terminal processor 501, at least one network interface 504, user interface 503, memory 505, and at least one communication bus 502.

[0084] The communication bus 502 is used to enable communication between these components.

[0085] The user interface 503 may include a display screen and a camera. Optionally, the user interface 503 may also include a standard wired interface and a wireless interface.

[0086] The network interface 504 may optionally include a standard wired interface or a wireless interface (such as a Wi-Fi interface).

[0087] The terminal processor 501 may include one or more processing cores. The terminal processor 501 connects to various parts within the terminal 500 using various interfaces and lines, and performs various functions and processes data by running or executing instructions, programs, code sets, or instruction sets stored in the memory 505, and by calling data stored in the memory 505. Optionally, the terminal processor 501 may be implemented using at least one hardware form of Digital Signal Processing (DSP), Field-Programmable Gate Array (FPGA), or Programmable Logic Array (PLA). The terminal processor 501 may integrate one or a combination of several of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), and modem. The CPU primarily handles the operating system, user interface, and applications; the GPU is responsible for rendering and drawing the content to be displayed on the screen; and the modem handles wireless communication. It is understood that the modem may also not be integrated into the terminal processor 501 and may be implemented as a separate chip.

[0088] The memory 505 may include random access memory (RAM) or read-only memory (ROM). Optionally, the memory 505 may include a non-transitory computer-readable storage medium. The memory 505 can be used to store instructions, programs, code, code sets, or instruction sets. The memory 505 may include a program storage area and a data storage area, wherein the program storage area may store instructions for implementing an operating system, instructions for at least one function (such as touch function, sound playback function, image playback function, etc.), instructions for implementing the above-described method embodiments, etc.; the data storage area may store data involved in the above-described method embodiments, etc. Optionally, the memory 505 may also be at least one storage device located remotely from the aforementioned terminal processor 501. Figure 5 As shown, the memory 505, which serves as a computer storage medium, may include an operating system, a network communication module, a user interface module, and a dynamic rule arrangement program.

[0089] exist Figure 5 In the terminal 500 shown, the user interface 503 is mainly used to provide an input interface for the user and to obtain the user's input data; while the terminal processor 501 can be used to call the dynamic rule arrangement program stored in the memory 505 and specifically perform the following operations: The rule arrangement interface is displayed. The rule arrangement interface uses a two-dimensional array as the data model. Each array element in the two-dimensional array represents a rule unit in the rule arrangement interface. In response to a user action that adds a target component to a target rule cell in the rule orchestration interface, determine the target position of the target rule cell in the two-dimensional array; Write the component data object corresponding to the target component to the target location, and render the rule arrangement interface based on the updated two-dimensional array so that the target component is displayed in the target rule unit.

[0090] In some embodiments, when the terminal processor 501 determines the target position of the target rule unit in the two-dimensional array, it specifically performs the following steps: obtaining the row index corresponding to the row where the target rule unit is located in the two-dimensional array and the column index corresponding to the column where it is located, and using the position determined based on the row index and the column index as the target position.

[0091] In some embodiments, before writing the component data object corresponding to the target component to the target location, the terminal processor 501 further performs the following steps: instantiating the target component to generate the component data object corresponding to the target component based on the unique component identifier of the target component.

[0092] In some embodiments, when the terminal processor 501 executes the following steps when writing the component data object corresponding to the target component to the target location: determining whether an array element already exists at the target location; if it does not exist or there is an empty value, then writing it directly; if a non-empty array element already exists, then performing an overwrite write operation or an insertion shift operation according to a preset interaction strategy.

[0093] In some embodiments, when the terminal processor 501 executes the interface for arranging rendering rules based on the updated two-dimensional array, it specifically performs the following steps: traversing each row and column of the updated two-dimensional array, for each array element, dynamically loading the corresponding target component according to the component data object stored in the array element, and rendering the loaded target component in the corresponding rule unit.

[0094] In some embodiments, the component data object includes at least the unique component identifier, component attribute value, and component type of the corresponding component; the target component is dynamically loaded from a pre-registered component library based on the unique component identifier and / or component type.

[0095] In some embodiments, when the terminal processor 501 performs a user operation in response to adding a target component to a target rule cell and determines the target position of the target rule cell in a two-dimensional array, it specifically performs the following steps: listening for drag events where the target component is dragged from the component selection area to the target rule cell in the rule arrangement interface, and calculating the target position of the target rule cell in the two-dimensional array based on the relative coordinates between the mouse release position and the rule arrangement interface.

[0096] In some embodiments, the terminal processor 501 further performs the following steps: when an array element in a two-dimensional array is empty or contains a placeholder identifier, the rule unit corresponding to the array element is rendered as a blank cell when rendering the rule arrangement interface.

[0097] In some embodiments, the terminal processor 501 further performs the following steps: when multiple array elements with the same component data object are detected to be adjacent in a two-dimensional array, the rule units corresponding to the multiple array elements are automatically merged, and the row span or column span of the merged array is calculated.

[0098] In some embodiments, the terminal processor 501 further performs the following steps: treating each row of the subarray in the two-dimensional array as an independent logical rule unit group; in response to the verification trigger operation, performing an intra-row consistency check on the component data objects stored in each array element of each row of the subarray, and outputting the corresponding verification results for each row.

[0099] In the several 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 modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules 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 modules may be electrical, mechanical, or other forms.

[0100] The modules described as separate components may or may not be physically separate. Similarly, the components shown as modules may or may not be physical modules; they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0101] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. The computer program product includes one or more computer instructions. When these computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this specification are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in or transmitted through a computer-readable storage medium. The computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, Digital Subscriber Line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The aforementioned available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., Digital Versatile Discs (DVDs)), or semiconductor media (e.g., Solid State Disks (SSDs)).

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

[0103] In addition, it should be noted that the information (including but not limited to user device information, user personal information, etc.), data (including but not limited to data used for analysis, data stored, data displayed, etc.) and signals involved in the embodiments of this application are all authorized by the user or fully authorized by all parties, and the collection, use and processing of related data must comply with the relevant laws, regulations and standards of the relevant countries and regions.

[0104] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0105] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0106] The above is a description of a dynamic rule arrangement method, apparatus, storage medium, and terminal provided in this application. For those skilled in the art, based on the ideas of the embodiments of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.< / object> < / object>

Claims

1. A dynamic rule arrangement method, characterized in that, The method includes: The rule arrangement interface is displayed. The rule arrangement interface uses a two-dimensional array as a data model. Each array element in the two-dimensional array represents a rule unit in the rule arrangement interface. In response to a user operation that adds a target component to a target rule unit in the rule orchestration interface, the target position of the target rule unit in the two-dimensional array is determined. Write the component data object corresponding to the target component to the target location, and render the rule arrangement interface based on the updated two-dimensional array so that the target component is displayed in the target rule unit.

2. The method according to claim 1, characterized in that, Determining the target position corresponding to the target rule unit in the two-dimensional array includes: Obtain the row index corresponding to the row and the column index corresponding to the column in the two-dimensional array where the target rule unit is located, and use the position determined based on the row index and the column index as the target position.

3. The method according to claim 1, characterized in that, Before writing the component data object corresponding to the target component to the target location, the method further includes: Based on the unique component identifier of the target component, the target component is instantiated to generate the corresponding component data object.

4. The method according to claim 1, characterized in that, The step of writing the component data object corresponding to the target component to the target location includes: Determine whether an array element already exists at the target location. If it does not exist or is empty, write it directly. If a non-empty array element already exists, an overwrite write operation or an insertion shift operation will be performed according to the preset interaction strategy.

5. The method according to claim 1, characterized in that, The process of rendering the rule orchestration interface based on the updated two-dimensional array includes: Iterate through each row and column of the updated two-dimensional array. For each array element, dynamically load the corresponding target component based on the component data object stored in the array element, and render the loaded target component in the corresponding rule unit.

6. The method according to claim 5, characterized in that, The component data object includes at least the unique component identifier, component attribute value, and component type of the corresponding component; The target component is dynamically loaded from a pre-registered component library based on the unique component identifier and / or the component type.

7. The method according to any one of claims 1 to 6, characterized in that, The step of determining the target position of the target rule unit in the two-dimensional array in response to a user operation of adding a target component to the target rule unit includes: Listen for drag events that involve dragging the target component from the component selection area to the target rule unit in the rule arrangement interface, and calculate the target position of the target rule unit in the two-dimensional array based on the relative coordinates between the mouse release position and the rule arrangement interface.

8. A dynamic rule arrangement device, characterized in that, The device includes: The interactive interface display module is used to display the rule arrangement interface, which uses a two-dimensional array as a data model. Each array element in the two-dimensional array represents a rule unit in the rule arrangement interface. The component location module is used to determine the target position of the target rule unit in the two-dimensional array in response to a user operation that adds the target component to the target rule unit in the rule arrangement interface. The array update rendering module is used to write the component data object corresponding to the target component to the target position, and render the rule arrangement interface based on the updated two-dimensional array so that the target component is displayed in the target rule unit.

9. A computer storage medium, characterized in that, The computer storage medium stores a plurality of instructions adapted for loading by a processor and executing the steps of the method as described in any one of claims 1 to 7.

10. A terminal, characterized in that, It includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the program, implements the steps of the method as described in any one of claims 1 to 7.

Images