Component construction method and device based on interactive condition and storage medium

Abstract

The invention discloses a component construction method and device based on interactive conditions and a storage medium, and relates to the technical field of front-end development, and the method comprises the steps: taking a preset date range condition as an initial retrieval default constraint, initializing a root condition group, and obtaining a default root condition group; in response to a selection operation of a user on the secondary field and the logic rule, matching and rendering the corresponding input control in combination with the default root condition group, and generating a condition item structure of the rendering control; after a second condition item is newly added in the condition item structure, constructing a nested condition group according to the added condition item structure, and generating a multi-stage condition query structure; and on the basis of a template storage operation, serializing the multi-stage condition query structure, and outputting a reusable target component construction template. According to the method, the condition item is generated through the response field and the rule selection rendering control, and then the nested multi-level query structure is constructed to obtain the reusable template. The technical problem that the development complexity is too high is solved, and the complexity of component construction is reduced.

Description

Technical Field

[0001] This application relates to the field of front-end development technology, and in particular to a method, device, and storage medium for building components based on interactive conditions. Background Technology

[0002] In complex business retrieval and task management scenarios, the front-end interactive condition building component is the core technology that enables users to efficiently configure retrieval rules and accurately complete task filtering, which directly affects business retrieval efficiency and user experience.

[0003] The relevant technologies mainly involve writing customized conversion functions to match the cascading data of the front-end interface with the flat fields of the back-end interface one by one. This method requires repeated development of adaptation code whenever a new business interface is added or the field definition is adjusted. It also requires extensive modification of the conversion logic across modules, which increases a lot of redundant development work and leads to excessive development complexity.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main objective of this application is to provide a component construction method, device, and storage medium based on interactive conditions, aiming to solve the technical problem of excessive development complexity.

[0006] To achieve the above objectives, this application proposes a component construction method based on interactive conditions, the method comprising: The default root condition group is initialized by using the preset date range as the initial search default constraint. In response to the user's selection operation on the secondary fields and logical rules in the default root condition group, the target control is matched and filtered, and the target control is rendered to generate the corresponding condition item structure; In response to the addition operation on the condition item structure, the added condition item structure is determined to construct a nested condition group; The core hierarchical configuration and logical association information of the nested condition group adaptation are integrated to form a multi-level condition query structure; Based on the template saving operation, the multi-level conditional query structure is serialized and output as a reusable target component construction template.

[0007] In one embodiment, if a component initialization instruction is triggered, the start and end times are determined based on the current time and combined with the current time, and a preset date range parameter is generated; According to the preset date range parameter, the attribute information and logical rules corresponding to the preset date range parameter are matched from the globally preset field configuration list to form the default condition item; After creating the condition group infrastructure marked as the root group, the default condition item is marked as a child item of the root group and stored in the array to update the condition group infrastructure to obtain the default root condition group.

[0008] In one embodiment, based on the target secondary field selected by the user, the complete metadata corresponding to the target secondary field is retrieved from a globally preset field configuration list; Based on the root group identifier in the default root condition group and its corresponding preset strategy, the field rule association data available under the current root condition group is filtered out from the list of supported operators of the complete metadata. By associating data with the target logic rule selected by the user and the field rule, the control rendering configuration parameters are formed by matching the control type, search configuration and data loading method corresponding to the target logic rule; The rendering configuration parameters of the control are passed to the current condition item position, and the mounting and initialization of the target control are completed to generate the condition item structure.

[0009] In one embodiment, based on the target logical rule, a target rule item that is consistent with the target logical rule is matched from the valid rule list of the field rule associated data; Extract the control type identifier, search configuration type, and data source identifier corresponding to the target rule item, and integrate them to obtain the basic rule configuration; Determine the data type of the field metadata in the basic configuration of the rule and the associated data of the field rule, obtain the corresponding parameters according to the data type, and obtain the detailed parameters for data loading; Based on the basic rule configuration, the detailed data loading parameters, and the prompt information in the field metadata, the set of control rendering configuration parameters is determined.

[0010] In one embodiment, in response to a user's operation of adding a second condition item, a second complete condition item is constructed by copying the condition item template and added to the root group sub-item storage array of the condition item structure, thereby obtaining the condition item structure after the addition; Based on the added condition item structure, create a condition group basic structure marked as subgroup, with an initial logical relationship of AND, and a unique group identifier, and initialize to obtain a mixed sub-item structure; Based on the hybrid sub-item structure, update the sub-item type statistics and the display adaptation status of logical selectors, determine the hierarchical affiliation relationship between each condition item and subgroup, and form the multi-level condition query structure.

[0011] In one embodiment, the hierarchical constraint rules, logical relationship configuration specifications, and sub-item identifier generation standards of the root group in the added condition item structure are extracted, and a unique group identifier exclusive to the sub-group is created through a globally unique identifier generation algorithm, and the basic information of the sub-group is obtained by integration. Based on the subgroup basic information and the condition group data structure specification, create a condition group basic structure with the type marked as subgroup, the initial logical relationship set to AND, and inheriting the root group hierarchical constraints; The subgroup basic framework of the associated empty array is incorporated into the root group sub-item storage array of the condition group basic structure to generate the hybrid sub-item structure.

[0012] In one embodiment, non-core fields are removed from the multi-level conditional query structure, and core business data is retained to obtain the core query data structure; Based on the component's preset template data specifications, supplement the necessary metadata of the core query data structure, unify the field naming format and hierarchical nesting rules, and output a standardized template data structure; The standardized template data structure is serialized and converted into text format data that can be transmitted and stored across different scenarios, forming the target component construction template.

[0013] In one embodiment, feedback data on the target component construction template in actual reuse scenarios is collected to obtain a template usage feedback dataset; By statistically analyzing the template usage feedback dataset, we identified combinations of fields and rules that frequently failed to adapt, types of logical relationships that were frequently adjusted, and control configurations that were prone to rendering anomalies. We also extracted the core issues that need to be optimized in the target component construction template and integrated them to generate a template optimization requirement list. To address the issues in the template optimization requirement list, the field rule mapping relationships were adjusted, the control type matching strategy was optimized, the default configuration of nested logic was improved, and the core business data and standardized structure of the template were updated to generate an optimized component building template.

[0014] In addition, to achieve the above objectives, this application also proposes a component building apparatus, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the interactive condition-based component building method as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and which, when executed by a processor, implements the steps of the component construction method based on interactive conditions as described above.

[0016] This application provides a component construction method based on interactive conditions. The method includes initializing a root condition group by using a preset date range as the initial default constraint to obtain a default root condition group. Then, responding to user selection operations on secondary fields and logical rules, and combining this default root condition group, it matches field attributes and rule types to render corresponding input controls, generating a condition item structure containing rendering controls. After adding a second condition item to this structure, it constructs nested condition groups based on the added condition item structure to generate a multi-level condition query structure. Finally, it serializes this multi-level condition query structure based on a template saving operation to output a reusable target component construction template. Simultaneously, it optimizes the component construction template based on template usage feedback. This method solves the technical problems of traditional condition query components, such as poor retrieval consistency due to missing initial constraints, inaccurate adaptation of fields, rules, and controls, complex nested condition group construction logic, and low development and operation efficiency due to the inability to reuse query conditions. It improves the standardization of condition query component initialization, the accuracy of field, rule, and control adaptation, the ease of constructing multi-level nested query structures, and the efficiency of query condition reuse, while reducing user operation complexity and development adaptation costs.

[0017] In summary, this application initializes the root condition group by pre-setting a date range, generates condition items in response to user field and rule selection rendering controls, constructs a nested multi-level query structure after adding new items, and serializes and outputs reusable templates. This solves the technical problem of excessive development complexity, improves the standardization level of query component initialization, the convenience of multi-level condition construction and condition reuse efficiency, optimizes the accuracy of field rule adaptation, and reduces operation and development costs. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] 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, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the component construction method based on interactive conditions in this application; Figure 2 This is a flowchart illustrating the fourth embodiment of the component construction method based on interactive conditions in this application; Figure 3 This is a flowchart illustrating the sixth embodiment of the component construction method based on interactive conditions in this application; Figure 4This is a flowchart illustrating the eighth embodiment of the component construction method based on interactive conditions in this application; Figure 5 A schematic diagram of the structure of the device for constructing the components of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] The relevant technologies mainly involve writing customized conversion functions to match the cascading data of the front-end interface with the flat fields of the back-end interface one by one. This method requires repeated development of adaptation code whenever a new business interface is added or the field definition is adjusted. It also requires extensive modification of the conversion logic across modules, which increases a lot of redundant development work and leads to excessive development complexity.

[0024] This application provides a solution: First, a preset date range condition is used as the initial default constraint for retrieval, and a root condition group is initialized to obtain a default root condition group. Then, in response to the user's selection operation of the secondary fields and logical rules in the default root condition group, the target control is matched and filtered, and the target control is rendered to generate the corresponding condition item structure. Then, in response to the addition operation of the condition item structure, the added condition item structure is determined to construct a nested condition group. Next, the core hierarchical configuration and logical association information adapted by the nested condition group are integrated to form a multi-level condition query structure. Finally, based on the template saving operation, the multi-level condition query structure is serialized and processed to output a reusable target component construction template.

[0025] It should be noted that the executing entity in this embodiment can be a computing service device with data processing, network communication, and program execution functions, such as a tablet computer, personal computer, or mobile phone, or an electronic device or component building device capable of performing the above functions. The following description uses a component building device as an example to illustrate this embodiment and the subsequent embodiments.

[0026] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0027] This application provides a component construction method based on interactive conditions, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the component construction method based on interactive conditions of this application.

[0028] In this embodiment, the component construction method based on interactive conditions includes steps S10 to S50: Step S10: Use the preset date range condition as the initial search default constraint to initialize the root condition group and obtain the default root condition group.

[0029] In this embodiment, the preset date range condition refers to a pre-defined date constraint that includes a start time and an end time. The initial retrieval default constraint refers to the basic query restrictions that automatically take effect when the component starts. The root condition group refers to the top-level container that holds all condition items and sub-condition groups. The default root condition group refers to the top-level condition group structure that can be directly used for subsequent interactions after the initial constraint configuration is completed.

[0030] As an optional implementation, upon receiving the initialization command, the start and end times of the date range are determined based on locally preset time calculation rules, forming complete date range parameters. Metadata for date type fields, including field identifiers, display names, and supported operator lists, is extracted from the locally stored global field configuration list. This is matched against corresponding logical rules and date range input control types. The start and end times are concatenated into condition values ​​according to a standardized format. A non-deletable attribute is set for this condition item, and a unique identifier is generated, completing the construction of the default condition item. A root condition group basic structure, marked as the top-level group and with an initial logical relationship of AND, is created. The child item storage array is initialized, and the constructed default condition item is stored within it. Simultaneously, a locally preset root group-specific disabling strategy is loaded to ensure that the initial condition item conforms to the disabling rules. Finally, a local validation mechanism verifies the field matching of the condition items, the validity of the rules, and the completeness of the control configuration, outputting a structurally standardized default root condition group. This method relies on local static configuration for initialization, requires no network interaction, has fast startup speed and high stability, and can quickly provide standardized initial constraints, adapting to fixed configuration scenarios.

[0031] As an alternative implementation, after receiving the initialization command, a request is sent to the remote service to obtain the base time and date range calculation rules. Based on these date range calculation rules, corresponding start and end time parameters are generated. A remote field configuration list and global disabling policy are requested synchronously. The complete metadata of date-type fields is filtered from the returned results, including field attributes, supported operator sets, control adaptation rules, etc., and the logical rules and corresponding date range input control configurations are matched. The start and end times are concatenated as condition values ​​according to the specifications, non-deletable attributes are set, and they are associated with a unique identifier assigned remotely to construct a complete default condition item. A root condition group structure, marked as the top-level group and with an initial logical relationship of AND, is created. A sub-item storage array is initialized and the default condition item is stored within it. The globally disabling policy returned remotely is integrated into the root group, allowing the disabling rules to override subsequently added sub-items. After the structure assembly is complete, a verification request is sent to the remote service to confirm that the initial structure is consistent with the remote system's data specifications, and a default root condition group that meets the requirements for cross-system interaction is output. This method can dynamically retrieve the latest field configurations, disabling policies, and time rules, exhibiting strong cross-system compatibility.

[0032] Step S20: In response to the user's selection operation on the secondary fields and logical rules in the default root condition group, match and filter the target control, and render the target control to generate the corresponding condition item structure.

[0033] In this embodiment, a secondary field refers to a subdivided field belonging to the primary core business field associated with the default root condition group. It is a functional decomposition of the primary core business field, and the primary core business field is the underlying entity. A logical rule refers to the pre-defined association logic of the component used to associate secondary fields with query conditions. The user's selection operation of secondary fields and logical rules refers to the interactive behavior where the user selects a target secondary field from the primary core business field associated with the default root condition group and chooses the corresponding association logic from the set of optional logical rules. Matching and filtering target controls refers to filtering suitable input control types from the component's pre-defined control library based on the data type and logical rules of the selected secondary field. The condition item structure refers to a complete data structure containing the selected secondary field identifier, logical rules, target control configuration, and information about the default root condition group.

[0034] As an optional implementation, the component loads the basic configuration of the default root condition group during initialization. This includes a list of associated primary core business fields, a list of secondary fields under each primary field, a set of optional logical rules, locally preset secondary fields, and a mapping table between logical rules and controls. The primary core business fields are then displayed for user selection. After the user selects a target primary core business field, the list of secondary fields associated with that primary field is loaded and displayed synchronously. The system receives the user's selected secondary field and corresponding logical rule selection. Based on the selected secondary field data type and logical rules, the local mapping table is queried to filter for suitable target control types. The local control rendering module is then called to load the target control and complete its initialization. The selected secondary field identifier, logical rules, target control configuration parameters, and default root condition group affiliation information are integrated and encapsulated, generating the corresponding condition item structure according to the sub-item structure specification of the default root condition group. This method relies on locally preset configuration and mapping tables to complete matching rendering, requires no network interaction, has a fast response speed, a simple execution flow, can quickly generate condition item structures, and is highly stable.

[0035] As an alternative implementation, during component initialization, a request is sent to the remote business configuration service, carrying the business domain identifier to which the component belongs. The component receives the default root condition group basic configuration, the globally selectable logical rule set, and the remote control matching rules returned by the remote service. First-level core business fields are displayed for user selection. After the user selects a target first-level core business field, the system requests and displays details of the second-level fields associated with that first-level field from the remote service, and receives the user's selected second-level fields and logical rule selections. The selected second-level field identifier, data type, and logical rules are synchronized to the remote control matching service, and the system receives the adapted target control type and dynamic configuration parameters returned by the remote service. The local control rendering module is called to load the target control according to the remote configuration parameters and complete initialization. The selected second-level field identifier, logical rules, remotely returned control configuration, and default root condition group affiliation information are integrated, and the corresponding condition item structure is encapsulated according to the remote specification and synchronously reported to the remote service for record-keeping. This method can dynamically obtain the latest remote configuration and matching rules, supports adding new field combinations and control types, and has strong adaptability across business scenarios.

[0036] Step S30: In response to the addition operation for the condition item structure, determine the added condition item structure to construct a nested condition group.

[0037] In this embodiment, the condition item structure refers to a complete data structure containing field identifiers, logical rules, control configurations, and hierarchical information, serving as the basic unit for constructing nested condition groups. The "add" operation refers to the user-triggered interaction of adding a new condition item or subgroup. The added condition item structure refers to a complete data set integrating the original condition item structure and the newly added unit, with no conflicts in hierarchical affiliation or logical relationships. A nested condition group refers to a composite condition group structure containing a root group, multi-level subgroups, and condition items, with clear hierarchical relationships and logical connections.

[0038] As an optional implementation, in response to an operation adding a condition item structure, the system reads the locally preset configuration of new units, extracts the hierarchical information and logical relationships of the original condition item structure, and verifies the hierarchical compatibility and logical conflicts between the new units and the original structure. The verified new units are added to the original structure in a locally preset order, integrating the core configurations of the original condition items and the new units, determining the hierarchical affiliation of the new units, and generating the added condition item structure. Based on the added condition item structure, the system constructs the hierarchical relationships of the root group, subgroups, and condition items layer by layer, forming nested condition groups. This method relies on local configuration for integration and construction, offering fast response, a simple process, strong stability, and the ability to quickly construct nested condition groups.

[0039] As an alternative implementation, in response to an operation adding a condition item structure, a new request is sent to the remote configuration service, carrying the hierarchical information, logical configuration, and business domain identifier of the original condition item structure. The latest configuration of the newly added unit is received from the remote service, and a compatibility check is performed between the remote configuration and the original structure. The new unit is integrated into the original structure according to the hierarchical insertion rules specified remotely, generating the added condition item structure. This condition item structure is simultaneously reported to the remote service for registration and global uniqueness verification. Based on the hierarchical construction specifications returned remotely, the relationships between the root group, subgroups, and condition items are established layer by layer, constructing a nested condition group that conforms to global standards. This method can dynamically obtain the latest remote configuration, and the generated nested condition groups have strong cross-scenario adaptability, conform to global specifications, and are suitable for multi-business domain linkage scenarios.

[0040] Step S40: Integrate the core hierarchical configuration and logical association information of the nested condition group adaptation to form a multi-level condition query structure.

[0041] In this embodiment, the core-level configuration refers to the set of adapted root group basic configuration, subgroup hierarchical constraints, and core configuration of condition items within a nested condition group. Logical association information refers to the logical relationships and association rules between condition items and subgroups within the nested condition group. The multi-level condition query structure refers to the standardized query data structure formed after integration, containing a complete hierarchical structure and clear logical associations.

[0042] As an optional implementation, the core-level configuration and logical association information after nested condition group adaptation are extracted, and a locally preset structural combination specification is read. The core-level configurations are categorized and sorted according to the specification, and logical association information is bound to corresponding level units. Configuration integrity and logical consistency are verified. Data is organized according to the local standard format to form a multi-level conditional query structure that meets local query execution requirements. This method relies on local specifications for integration, resulting in fast response, a simple process, and strong stability.

[0043] As an alternative implementation, the core-level configuration and logical association information of nested condition groups are extracted, and an integration request is sent to the remote standardized service, carrying the information and the business domain identifier to which the components belong. The globally unified combination specification returned from the remote service is received, and the core-level configuration is categorized and organized according to the specification. Logical association information is bound to hierarchical units according to remote rules, and the initially integrated structure is submitted to the remote verification interface to verify cross-system compatibility, configuration integrity, and logical consistency. Optimization suggestions are received and adjusted, and the results are output according to the remote standard format, forming a multi-level conditional query structure that conforms to the global query specification. This method dynamically adapts to the global specification, has strong cross-system adaptability, and is suitable for multi-business domain linkage scenarios.

[0044] Step S50: Based on the template saving operation, the multi-level conditional query structure is serialized and processed to output a reusable target component construction template.

[0045] In this embodiment, the template saving operation refers to the interactive instruction that triggers the transformation of a multi-level conditional query structure into a reusable template. Serialization processing refers to the process of converting structured query data into a storable and transmittable text format. A reusable target component construction template refers to structured text data that has undergone standardization and can be directly used for component conditional reuse or cross-scenario adaptation.

[0046] As an optional implementation, after receiving the template save operation, the multi-level conditional query structure is first cleaned locally, removing non-core fields such as control instance references, temporary status identifiers, and operation traces, while retaining core business data such as group types, logical relationships, sub-item sets, field attributes of condition items, rule attributes, and value information. Then, according to the locally preset template format specifications, the field naming rules, hierarchical nesting identifiers, and logical relationship representation methods are standardized, and a locally generated unique template identifier and creation timestamp are added to form a standardized core data structure. Finally, the standardized core data structure is converted into text format through a local serialization mechanism, serialization integrity is verified, and a target component construction template that can be directly stored locally and imported offline for component reuse is output. This method does not rely on remote services, generates templates quickly, has no network environment limitations, and can quickly meet local reuse requirements.

[0047] As an alternative implementation, after receiving the template save operation, the complete data of the multi-level conditional query structure is extracted, and a data standardization request is sent to the remote template management service. Non-core fields are removed according to the globally unified specification returned by the server, and metadata such as the remotely assigned unique template ID, structure version number, and global adaptation identifier are simultaneously added. Through the serialization interface of the remote service, the standardized query structure is converted into a text format conforming to cross-system transmission specifications, and a template data verification code is generated. The serialization result and verification code returned by the server are received, and the verification code and template association information are stored locally. The output is a target component construction template that can be transmitted over the network to other systems and adapted and reused according to global specifications. This method follows globally unified specifications, has strong cross-system reusability and adaptability, and allows template versions to be uniformly managed and updated through a remote service, meeting the needs of multi-system linkage and reuse.

[0048] For example, in a component construction scenario, January 1, 2024 to January 30, 2024 is used as a preset date range condition, which is used as the initial default constraint to initialize the root condition group. This default root condition group is marked as the root group, and the initial logical relationship is "AND". The child item storage array contains one non-deletable default condition item. When the user selects "Order Amount" (field type "Number") in the secondary field selector and selects "greater than or equal to" as the logical rule, combined with the default root group's disabling strategy (disabling the "not equal to" rule), the numeric input control is matched, and the control's attribute parameters (placeholder prompt "Please enter the amount", disabled status "No") are loaded. This completes the rendering and generates a condition item structure containing two condition items. A second condition item, "Payment Method" (a secondary field), with the rule "equal to," is added. A dropdown selection control (enumerating options "WeChat Pay" and "Alipay Pay") is rendered. The added condition item structure contains three condition items. Based on this structure, nested condition groups marked as subgroups and with the logical relationship "OR" are created. The "Payment Method" condition item is then added, generating a multi-level condition query structure containing a root group, two first-level condition items, and one nested subgroup (containing one condition item). After triggering the template save operation, this multi-level condition query structure is processed through JSON serialization, removing non-core fields such as control instances, and generating a 2.1KB target component building template. This template can be directly imported into the order query component for reuse.

[0049] By automatically initializing the default root condition group through a preset date range, the system accurately matches input controls such as numerical input controls and drop-down selection controls after the user selects the secondary field and the corresponding logical rule. Finally, the serialized output is a reusable template, which solves the problems of missing initial constraints, complex nested structure construction, and inability to reuse conditions in traditional component construction, and reduces the complexity of component construction.

[0050] Based on any of the above embodiments, in Embodiment 2 of this application, step S10 includes steps A11 to A13: Step A11: If the component initialization instruction is triggered, the start and end times are determined based on the current time and combined with the current time, and a preset date range parameter is generated.

[0051] In this embodiment, the component initialization command is a trigger signal that initiates the component's startup and executes its initial configuration. The preset number of days is a pre-set fixed number of days used to calculate the start time. The preset date range parameter is complete date constraint data that includes both the start and end times.

[0052] As an optional implementation, after receiving the component initialization command, a preset number of days is extracted from the locally stored component configuration file. Using the current time as a base, the duration corresponding to the preset number of days is deducted backwards according to time calculation rules to determine the start time. The current time is directly used as the end time. Format and logical validations are performed on the start and end times. If the validation passes, the start and end times are concatenated in a unified format to generate a preset date range parameter containing the complete time range. If the validation fails, the locally preset spare number of days is used to recalculate until a date range parameter that meets the requirements is generated. This method directly reads the local configuration to complete the calculation, requiring no network interaction, and the time calculation and parameter generation speed is fast.

[0053] Step A12: According to the preset date range parameter, match the attribute information and logical rules corresponding to the preset date range parameter from the globally preset field configuration list to form a default condition item.

[0054] In this embodiment, the globally preset field configuration list refers to a global configuration set that stores complete metadata for all available fields. Attribute information refers to the core configuration data corresponding to a field. Logical rules refer to the time-related comparison operations supported by the field. Default condition items refer to the initial search condition unit containing field attributes, matching logical rules, and date range values.

[0055] As an optional implementation, after receiving the preset date range parameter, its time constraint type is first extracted. The locally stored global preset field configuration list is then traversed to filter out target fields marked as date type. Complete attribute information, including field identifier, field display name, and compatible input control type, is extracted from the target field's metadata. Next, from the list of supported rules associated with the target field, the "between" logic rule that matches the date range parameter is matched, and the rule's identifier, display label, and parameter format requirements are obtained. The start and end times in the preset date range parameter are concatenated into a condition value according to the field configuration requirements. A non-deletable attribute identifier is set for this condition value, and a unique identifier is assigned through a local identifier generation mechanism. Finally, the field attribute information, the "between" logic rule, the concatenated condition value, the non-deletable identifier, and the unique identifier are integrated to form a structurally complete default condition item, which is then output. This method relies on local configuration to complete the entire matching process without network interaction. It has a fast matching speed and direct adaptation logic, and can quickly output standardized default condition items. It is highly stable, but it cannot synchronize remotely added date fields or updated rule configurations. It is not adaptable to global configuration changes and can only meet the initial condition generation needs of fixed scenarios in local configuration.

[0056] Step A13: After creating the condition group infrastructure marked as the root group, the default condition item is marked as a child item of the root group and stored in the array to update the condition group infrastructure and obtain the default root condition group.

[0057] In this embodiment, the condition group infrastructure marked as the root group refers to the initial framework of the condition group, which is marked as top-level, has no parent group, and contains initial logical relationships and group identifiers. The sub-item storage array of the root group refers to a dedicated data container used to store all condition items or sub-groups under the root group.

[0058] As an optional implementation, a basic framework structure for condition groups is created according to a preset condition group structure specification. This basic framework structure is designated as the root group, and the initial logical relationship is set to "AND". A dedicated group identifier is created through a local identifier generation mechanism, and an empty sub-item storage array is initialized, ensuring that the sub-item storage array is used only to store condition items and subgroups under the root group. The default condition items undergo structural validation, verifying that field identifiers, rule identifiers, condition values, non-deletable attributes, and unique identifiers are complete and conform to local configuration specifications. The validated default condition items are stored in the root group's sub-item storage array according to array element format requirements, and the root group's sub-item quantity statistics field and sub-item type marker are updated synchronously. Through a locally built-in structural consistency validation mechanism, the correlation between the root group identifier, initial logical relationship, and default condition items in the sub-item storage array is verified. After confirming no structural conflicts or configuration omissions, a complete default root condition group is generated and output. This method relies entirely on local configuration and validation mechanisms, requires no network interaction, has a fast construction speed and high structural stability, can quickly provide standardized top-level conditions, and is adaptable to local independent operation scenarios.

[0059] For example, in the scenario of component construction, the initialization instruction of the order query component is triggered. The current time is 15:30 on October 20, 2024. Based on this time, the preset number of days is calculated backward by 30 days. After deducting the difference in the number of days in short months, the start time is determined to be 0:00 on September 20, 2024. Combined with the current time, the end time is determined to be 15:30 on October 20, 2024. The preset date range parameters "2024-09-20 00:00, 2024-10-20 15:30" are generated in a unified format of "year, month, day, hour, minute". It iterates through the globally preset field configuration list according to the parameter, matches the attribute information of the date field "Creation Time" (field identifier "create_time", display name "Creation Time", and compatible control type "Date Range Input Control"), and filters the "between" rule (rule identifier "between", display label "between", parameter format requirement "start and end time concatenation") that adapts to the date range parameter from the list of logical rules supported by this field. It uses the preset date range parameter as the condition value, sets the non-deletable attribute and assigns a unique identifier "cond_001", and outputs the default condition item. It creates the basic structure of the condition group marked as the root group (group identifier "root_001", initial logical relationship "AND"), initializes an empty child item storage array, performs structural validation on the default condition item, checks the integrity of field identifiers, rule identifiers, etc., and stores them in the array. It synchronously updates the root group child item count to 1. After passing the consistency check, it obtains the default root condition group (including the root group identifier, logical relationship "AND", and child item storage array [default condition item]).

[0060] By generating default condition items by accurately matching the attribute information and logical rules of the creation time field from the global field configuration list, and storing the default condition items in the sub-item storage array to obtain the default root condition group, the problem of easy errors in the initial condition item construction is solved, the operation cost and time cost of component construction are reduced, and the standardized and automated construction of the initial condition group is realized, laying an efficient foundation for the subsequent addition of condition items and the construction of nested groups.

[0061] Based on any of the above embodiments, in Embodiment 3 of this application, step S20 includes steps B11 to B14: Step B11: Based on the target secondary field selected by the user, query the global preset field configuration list to obtain the complete metadata corresponding to the target secondary field.

[0062] In this embodiment, the target second-level field refers to the specific field selected by the user from the two-level tree-structured field. The globally preset field configuration list refers to the global data set that stores the complete configuration information of all available fields. The complete metadata refers to all the core configurations corresponding to the target second-level field, including field type, supported rules, enumeration options, adapted control types, data specifications, etc.

[0063] As an optional implementation, after the user selects a target secondary field, the unique identifier of that target secondary field is extracted, and the locally cached global preset field configuration list is traversed. The field identifier is precisely matched against the field entries in the list, and complete metadata is extracted from the successfully matched entries. This metadata covers core information such as field type, supported logical rule sets, enumerated options, compatible input control types, and data format requirements. Simultaneously, local integrity verification is performed on the extracted metadata to check for missing key configuration items such as field type and supported rules. If any are missing, locally preset default configuration items are automatically added to ensure the integrity of the metadata structure. Finally, complete metadata for the target secondary field conforming to local configuration specifications is output. This method relies on local caching for querying and verification, offering fast response speeds and no network dependency, with simple and efficient verification logic.

[0064] Step B12: Based on the root group identifier in the default root condition group and its corresponding preset strategy, filter out the field rule association data available under the current root condition group from the list of supported operators of the complete metadata.

[0065] In this embodiment, the root group identifier refers to the unique identifier of the default root condition group, used to associate the corresponding configuration policy. The preset policy refers to the configuration bound to the root group identifier that limits the availability of rules. The supported operator list refers to the set of all logical operators that the field can be adapted to, recorded in the complete metadata. The valid rule list refers to the set of logical operators allowed to be used under the current root condition group after being filtered by the preset policy. The field rule association data refers to the association data set containing the complete metadata of the target secondary field and the valid rule list.

[0066] As an optional implementation, the root group identifier is extracted from the default root condition group. Based on this root group identifier, the corresponding preset policy is matched from the locally stored policy configuration to obtain the constraint information such as the list of disabled rules and the scope of enabled rules specified in the policy. Simultaneously, the list of supported operators is extracted from the complete metadata. Each operator in the list is verified one by one according to the preset policy, and operators that are not disabled and are within the enabled scope are retained to form a valid rule list. The valid rule list is associated and bound with the complete metadata, and the logical consistency of the associated data is checked. After confirmation, the field rule association data containing the complete metadata and the valid rule list is output. This method relies entirely on local configuration to complete filtering and association, has a fast response speed and no network dependency, can quickly output association data that conforms to the local policy, and has strong stability.

[0067] Step B13: By associating data with the target logic rule selected by the user and the field rule, the control type, search configuration, and data loading method corresponding to the target logic rule are matched to form the control rendering configuration parameters.

[0068] In this embodiment, the target logic rule refers to the specific logical operation rule selected by the user from the list of valid rules. The control type refers to the type of interactive input component that adapts to the target logic rule and field type. The search configuration refers to the relevant settings that support the control search function. The data loading method refers to the acquisition and loading mode of the data required by the control. The control rendering configuration parameters refer to the complete set of parameters integrating the control type, search configuration, data loading method, and other rendering attributes.

[0069] As an optional implementation, the method extracts the identifier of the target logical rule selected by the user, retrieves the corresponding adaptation configuration entry from the field rule association data, matches the preset control type within the entry, and extracts basic search configuration information from the complete metadata of the field rule association data. If it is a local search, the search dataset path and matching rules are determined; if there is no search function, empty search parameters are configured. Then, the data loading method is determined based on the field type and rule characteristics. The control type, search configuration, and data loading method are integrated, and rendering auxiliary attributes such as placeholder hints and disabled states are added. The completeness and adaptability of the parameters are verified through a local configuration verification mechanism, and finally, control rendering configuration parameters conforming to local rendering specifications are generated. This method relies on the local preset configuration in the field rule association data to complete the entire matching process. It has a fast response speed, no network dependency, high parameter matching accuracy, and can quickly support real-time control rendering, making it suitable for scenarios with fixed configurations and no frequent updates.

[0070] Step B14: Pass the control rendering configuration parameters to the current condition item position, complete the mounting and initialization of the target control, and generate the condition item structure.

[0071] In this embodiment, the current condition item position refers to the specific location of the target condition item of the control to be attached within the overall structure. Control initialization refers to the process of loading configuration parameters and setting the initial state for the control.

[0072] As an optional implementation, the unique identifier and hierarchical information of the current condition item's location are extracted. The control rendering configuration parameters are then passed to the current condition item's location according to a locally preset parameter injection specification, and the underlying mounting method for the corresponding control type is called. An association is established between the control instance and the current condition item's location. Based on the data loading method in the configuration parameters, the initial data required by the control is loaded. Initial attributes such as placeholder hints, disabled status, and default values ​​for the target control are set, completing the target control initialization. Subsequently, the field attributes of the current condition item, the target logic rules, the already mounted and initialized control instance, and the associated configuration information are integrated. A local structure verification mechanism verifies the association and completeness of each element, ensuring that the control, fields, and rules are correctly matched. Finally, a complete condition item structure that can be directly interacted with is generated. This method relies on local mounting and initialization logic, has a simple operation process, fast response speed, requires no network interaction, and can quickly complete the construction of condition items.

[0073] For example, in a component-based scenario, a user selects the target secondary field "Order Amount" in the order query component. Its unique identifier is "order_amount". The system retrieves the complete metadata of this field from the globally preset field configuration list (field type: "numeric", supported operators: "greater than or equal to", "less than or equal to", "equal to", "not equal to", none enumeration options, "numerical input control" set of compatible controls, and "non-negative number" data format requirement). Based on the root group identifier "root_002" of the default root condition group and its corresponding preset strategy (disabling the "not equal to" rule and enabling numeric comparison rules), the system filters out the three operators "greater than or equal to", "less than or equal to", and "equal to" from the list of supported operators in the complete metadata, forming a valid rule list. The output is field rule association data containing the complete metadata and the valid rule list. The user selects the target logic rule "greater than or equal to". This rule is then matched against field rules to determine the control type as "numerical input control", the search configuration as "no search function, empty parameters", and the data loading method as "immediate loading, no caching". A control rendering configuration parameter is generated, containing the above information, a placeholder prompt "Please enter the amount", and a disabled state "No". This parameter is passed to the current condition item position (the second position in the root group's child item storage array). The underlying mounting method of the numerical input control is called to establish the association, load initial data (default value "0"), and set initial properties, completing control initialization. Finally, the target secondary field properties, the "greater than or equal to" logic rule, and the mounted control instance are integrated to generate a complete condition item structure.

[0074] By automatically matching field metadata, filtering valid rules, generating control configurations, and completing mounting, the problem of cumbersome, error-prone, and inefficient field, rule, and control adaptation in traditional component construction is solved. This improves the standardization, adaptation accuracy, and configuration efficiency of component condition item construction, and reduces operational complexity.

[0075] Based on any of the above embodiments, in Embodiment 4 of this application, referring to Figure 2 , Figure 2 This is a flowchart illustrating the fourth embodiment of the component construction method based on interactive conditions in this application. Step B13 includes steps C11-C14: Step C11: Based on the target logical rule, match the target rule item that is consistent with the target logical rule from the valid rule list of the field rule associated data.

[0076] In this embodiment, the valid rule list refers to the set of logical operators allowed under the current root condition group after being filtered by a preset strategy. The target rule item refers to a rule entry in the valid rule list that is completely identical to the target logical rule in terms of identification and function.

[0077] As an optional implementation, the unique identifier and core attributes of the target logical rule are extracted, and the list of valid rules in the field rule association data is traversed. A precise comparison is performed according to the rule identifier to locate the rule entry that is completely identical to the target logical rule identifier. Complete information including the rule identifier, display label, parameter format, and adapted control type of this rule entry is extracted. The extracted complete information is then subjected to local integrity verification to ensure no core configuration is missing. Finally, the target rule item that completely matches the target logical rule is output. This method completes the matching through local direct traversal and comparison, resulting in fast response speed, no network dependency, simple and efficient matching logic, and rapid output of the target rule item.

[0078] Step C12: Extract the control type identifier, search configuration type, and data source identifier corresponding to the target rule item, and integrate them to obtain the basic rule configuration.

[0079] In this embodiment, the control type identifier refers to a unique identifier that marks the control type to which the target rule item is adapted. The search configuration type refers to the search function configuration category corresponding to the target rule item. The data source identifier refers to a unique identifier that marks the source of the data required by the control. The basic rule configuration refers to the core configuration set that integrates the control type identifier, search configuration type, and data source identifier.

[0080] As an optional implementation, the method extracts the preset control type identifier, search configuration type, and data source identifier from the target rule item. It then queries the complete meaning and adaptation requirements of each identifier from the locally stored configuration dictionary, performing correlation verification on the three identifiers to ensure consistency between the control type, search configuration, and data source logic. If any identifier is missing, it automatically supplements it with a locally preset default identifier, checks whether the identifier format conforms to local configuration specifications, and, after confirming no conflicts, integrates the three identifiers and supplementary adaptation instructions to output a complete rule basic configuration that conforms to local specifications. This method relies on the local configuration dictionary for identifier parsing and verification, requires no network interaction, has a fast extraction speed and a simple process, can quickly output usable rule basic configurations, has strong stability, and can guarantee configuration extraction efficiency and basic adaptation effects in local scenarios.

[0081] Step C13: Determine the data type of the field metadata in the basic rule configuration and the field rule association data, obtain the corresponding parameters according to the data type, and obtain the detailed parameters for data loading.

[0082] In this embodiment, field metadata refers to all the core configurations of the target secondary field. Corresponding parameters refer to the specific configuration items that adapt to specific data types and support data loading. Detailed data loading parameters refer to the complete set of configurations that integrate the basic configuration of the integration rules and the data type adaptation parameters, and can be directly used for control data loading.

[0083] As an optional implementation, this method extracts the control type identifier, search configuration type, and data source identifier from the basic rule configuration. Simultaneously, it clarifies the data type from the field metadata of the data associated with the field rules. Based on the data type, it searches for the appropriate parameters from a locally preset type-parameter mapping table. If the data is enumerated, it obtains the local enumeration collection storage path and read permission configuration. If it is a remote data source type, it extracts the locally cached data source interface base address and request header parameters. These parameters are then correlated with the identifiers in the basic rule configuration to ensure consistency between the control type, search configuration, and data type. Locally preset loading timeout thresholds, retries, and other general parameters are added. After integrating all valid information, detailed data loading parameters conforming to local loading specifications are output. This method relies on a local mapping table and cached data to complete parameter acquisition, requires no network interaction, and offers fast response and high stability.

[0084] Step C14: Based on the rule base configuration, the data loading detailed parameters, and the prompt information in the field metadata, determine the control rendering configuration parameter set.

[0085] As an optional implementation, this method extracts core items from the basic rule configuration, including control type identifiers, search configuration types, and data source identifiers; data source paths, caching strategies, and loading thresholds from detailed data loading parameters; and placeholder hints and input format descriptions from field metadata. These three types of information are then integrated according to a locally preset parameter set format specification, supplementing with locally fixed control style configurations, interaction trigger rules, and default values ​​for disabled states. The integrated configuration information undergoes correlation verification to ensure compatibility between control types and data loading methods, matching of hints and field types, and verification of parameter formats against local rendering engine requirements. After confirming no conflicts or omissions, the configuration is organized hierarchically by field identifier, rule identifier, and control configuration, outputting a well-structured control rendering configuration parameter set adapted to the local rendering environment. This method relies on locally fixed specifications for integration, requires no network interaction, generates configurations quickly and stably, and can rapidly support real-time control rendering, making it suitable for scenarios where local independent operation and configurations do not change frequently.

[0086] By automatically matching rule items, extracting basic configurations, adapting data loading parameters, and integrating rendering configurations, the system solves the problems of tedious manual adaptation of control rendering configurations, inconsistent parameters, and easy errors in component construction, thereby improving the standardization, adaptation accuracy, and construction efficiency of control configurations.

[0087] Based on any of the above embodiments, in Embodiment 5 of this application, step S30 includes steps D11 to D13: Step D11: In response to the user's operation of adding a second condition item, construct a second complete condition item by copying the condition item template and add it to the root group sub-item storage array of the condition item structure to obtain the condition item structure after the addition.

[0088] In this embodiment, the condition item template refers to the component's preset basic structure of condition items, which includes a field configuration framework, logical rule options, and control type placeholders. The second complete condition item refers to a complete condition item unit with independent field identifiers, logical rules, and control configurations, created by copying the template and supplementing it with custom configurations. The root group sub-item storage array of the condition item structure refers to the data container dedicated to the root group in the condition item structure, used to uniformly store all sub-items.

[0089] As an optional implementation, in response to a user's addition of a second condition item, the system reads a locally preset condition item template, copies the template's field configuration framework, logical rule options, and control type placeholders, and generates a unique identifier and sequence identifier for the second condition item. Basic configuration parameters are supplemented, and the compatibility of the second condition item with existing condition items is checked. After confirming no conflicts, the complete second condition item is added to the root group sub-item storage array of the condition item structure according to the locally preset order. The total number of sub-items and type distribution statistics fields in the array are updated, generating the added condition item structure. This method relies on local templates and configurations to complete the addition, offering fast response, a simple process, and strong stability, making it suitable for scenarios with stable local configurations.

[0090] As an alternative implementation, in response to a user's action to add a second condition item, a template retrieval request is sent to the remote configuration service, carrying the configuration information of the original condition item structure and the business domain identifier to which the component belongs. The latest condition item template returned from the remote service is received, copied, and a globally unique identifier is generated. The exclusive parameters of the second condition item are supplemented according to the configuration specifications returned from the remote service. Compatibility and cross-system adaptability with the original condition items are verified through a remote verification interface. Upon receiving feedback that the verification is successful, the second complete condition item is added to the root group sub-item storage array according to the insertion order specified remotely. The updated array is synchronously reported to the remote service for record-keeping, generating the added condition item structure. This method can dynamically obtain the latest remote template and configuration specifications, has strong cross-scenario adaptability, conforms to global standards, and is suitable for multi-business domain linkage scenarios.

[0091] Step D12: Based on the added condition item structure, create a condition group basic structure marked as subgroup, with an initial logical relationship of AND, and a unique group identifier, and initialize to obtain a mixed sub-item structure.

[0092] In this embodiment, the basic structure of a condition group marked as a subgroup refers to the initial framework of a condition group whose type is secondary and belongs to the root group. The initial logical relationship is defined as the default association logic that must be satisfied simultaneously between sub-items when the subgroup is created. The unique group identifier is a unique, non-repeating identifier specific to the subgroup. The subgroup-specific sub-item storage array is a data container used only to store condition items or secondary subgroups within that subgroup. The hybrid sub-item structure refers to a composite data structure in the root group's sub-item storage array that simultaneously contains independent condition items and subgroups.

[0093] As an optional implementation, the sub-item list, root group hierarchy specification, and logical relationship configuration are extracted from the added condition item structure. A basic framework is created according to the locally preset sub-group construction standard, and each sub-group is identified and marked as such, with the initial logical relationship set to "AND". A unique group identifier is created through a local identifier generation mechanism, and an empty sub-group-specific sub-item storage array is initialized, defining the array's storage format, sub-item type restrictions, and order rules. A portion of the specified condition items in the added condition item structure are sequentially moved into the sub-group's sub-item storage array, while the remaining condition items are retained in the original root group storage array. The sub-item count fields of the root group and sub-groups are updated synchronously. A locally built-in structure consistency verification mechanism checks the uniqueness of the sub-group identifier, the adaptability of the logical relationship, and the accuracy of the hierarchical affiliation of the hybrid structure. After confirming no configuration conflicts or structural omissions, a hybrid sub-item structure containing independent condition items and sub-groups is obtained. This method relies on local configuration to complete sub-group creation and structure integration, requires no network interaction, and offers fast construction speed and strong stability.

[0094] Step D13: Based on the hybrid sub-item structure, update the sub-item type statistics and the display adaptation status of logical selectors, determine the hierarchical affiliation relationship between each condition item and subgroup, and form the multi-level condition query structure.

[0095] In this embodiment, sub-item type statistics refer to the quantitative recording of the quantity and type distribution of condition items and subgroups under each level group. The display adaptation status of logical selectors refers to the dynamic adjustment of whether logical selectors are displayed, their display position, and the selectable logical relationships based on the quantity and type of sub-items. Hierarchical affiliation refers to the explicit subordinate relationship between each condition item / subgroup and its parent group.

[0096] As an optional implementation, all sub-items of the root group and sub-groups in the hybrid sub-item structure are extracted and traversed in hierarchical order from top to bottom. The number and type distribution of condition items and sub-groups at each level are counted to form sub-item type statistics. The display adaptation state of logical selectors is dynamically adjusted based on the number of sub-items at each level in the statistics. When there are at least two sub-items, the corresponding logical selector is displayed; when there is only one sub-item, the logical selector is hidden. Simultaneously, the display position of the logical selector is determined according to local preset rules. The association is traced through the unique identifiers of sub-items and groups to determine the hierarchical affiliation of each condition item to its corresponding sub-group and the sub-group to its root group. The sub-item type statistics, the adjusted display state of logical selectors, and the clear hierarchical affiliation are integrated into the hybrid sub-item structure. The accuracy of the affiliation and the rationality of the logical selector display are verified through a locally built-in hierarchical verification mechanism. After confirming that there is no hierarchical confusion or display anomalies, a multi-level conditional query structure with clear hierarchy, logical adaptation, and complete type statistics is formed. This method relies on local traversal and validation logic to complete the update, has a fast response speed and no network dependency, can quickly output a query structure that conforms to local specifications, and has strong stability.

[0097] As an alternative implementation, the hierarchical information, sub-item attributes, and component business scenario parameters of the hybrid sub-item structure are extracted. A request is sent to a remote intelligent adaptation service, and the dynamically adapted rules returned by the remote service are received. These rules include a mapping between the number of sub-items and their display states, a scenario-based optional logical range, and hierarchical display position rules. Sub-item types are statistically analyzed according to the rules, the display states of selectors are dynamically adjusted, optional logical relationships are filtered according to business scenarios, and display positions are intelligently allocated according to hierarchical affiliation. The adjusted selector states and hierarchical relationships are reported to a remote verification service. After receiving optimization suggestions, the structure is improved, and a multi-level conditional query structure is output. This method supports scenario-based intelligent adaptation, and the logical selectors have strong flexibility and adaptability, making it suitable for scenarios with multiple business scenarios and complex hierarchical structures.

[0098] For example, in a component construction scenario, the structure of the first rendered control's condition item is (field "order amount", identifier "cond_002", logical rule "greater than or equal to", control type "numerical input control"). Responding to the user's addition of a second condition item, the condition item template is copied and its configuration replaced to construct a second complete condition item (field "payment status", identifier "cond_003", logical rule "equal to", control type "dropdown selection control", enumeration option "paid / not paid"). This is added to the root group's sub-item storage array (originally containing 1 condition item, now 2 after the addition), resulting in the added condition item structure. Based on this condition item structure, a condition group basic structure is created, marked as a sub-group, with an initial logical relationship of "AND", and a unique group identifier "sub_group_001". The sub-group's dedicated sub-item storage array is initialized, and the second condition item is moved into this sub-group's dedicated sub-item storage array, resulting in a hybrid sub-item structure (the root group's sub-item storage array contains 1 condition item + 1 sub-group, and the sub-group array contains 1 condition item). Based on the mixed sub-item structure, update the sub-item type statistics (root group: 1 condition item, 1 subgroup; subgroup: 1 condition item), display the adaptation status of logical selectors (root group displays "AND", subgroup displays "AND"), determine the hierarchical relationship of "cond_002" belonging to the root group, "cond_003" belonging to "sub_group_001", and subgroup belonging to the root group, and output a multi-level condition query structure containing the root group, 1 nested subgroup, and 2 condition items.

[0099] By automatically copying templates to add condition items, constructing nested subgroups, and clarifying hierarchical affiliation, the problems of complex manual construction of nested structures, chaotic hierarchical relationships, and low configuration efficiency in component construction are solved, thereby improving the standardization, hierarchical clarity, and construction efficiency of multi-level conditional structures.

[0100] Based on any of the above embodiments, in Embodiment Six of this application, referring to Figure 3 , Figure 3 This is a flowchart illustrating the sixth embodiment of the component construction method based on interactive conditions in this application. Step D12 includes steps E11 to E13: Step E11: Extract the hierarchical constraint rules, logical relationship configuration specifications, and sub-item identifier generation standards of the root group in the added condition item structure, and create a unique group identifier exclusive to the sub-group through a globally unique identifier generation algorithm, and integrate to obtain the basic information of the sub-group.

[0101] In this embodiment, the root group's hierarchical constraint rules refer to the configuration rules that limit the subgroup's hierarchical affiliation, nesting depth, and sub-item types. The logical relationship configuration specification refers to the optional range, default values, and configuration format requirements for subgroup logical relationships. The sub-item identifier generation standard refers to the standard that specifies the naming rules, format length, and uniqueness verification of subgroup identifiers. The globally unique identifier generation algorithm refers to the calculation method that can generate unique identifiers that are non-repeating and conform to the specification. The subgroup basic information refers to the initial configuration set of the subgroup, which includes the unique group identifier, hierarchical constraint rules, and logical relationship configuration specifications.

[0102] As an optional implementation, the hierarchical constraint rules, logical relationship configuration specifications, and sub-item identifier generation standards of the root group are extracted from the added condition item structure. A locally integrated globally unique identifier generation algorithm is invoked, and algorithm parameters are set according to the sub-item identifier generation standards to generate a standard-compliant sub-group-specific unique identifier. After verifying through a local uniqueness check mechanism that the sub-group-specific unique identifier does not conflict with the root group and other sub-item identifiers, the unique identifier, extracted hierarchical constraint rules, and logical relationship configuration specifications are integrated, supplemented with locally preset sub-group basic attributes, and the structurally complete sub-group basic information is generated and output. This method relies on local configuration and algorithms to complete the generation, requires no network interaction, has a fast response speed and a simple process, can quickly output sub-group basic information, and has strong stability, making it suitable for scenarios with stable global configurations.

[0103] As an alternative implementation, the root group configuration and the current component's hierarchical usage status data are extracted. An identifier generation request is sent to the remote configuration service, carrying the root group identifier and component business domain information. The system receives a globally unique identifier and dynamic constraint binding rules returned from the remote service. A remote intelligent algorithm analyzes the compatibility between root group constraints and subgroup usage scenarios, dynamically binding hierarchical constraint rules to identifiers according to scenario priority, establishing a real-time synchronization mechanism for constraint changes. Cross-system compatibility verification is performed on the binding relationship between identifiers and constraints, and basic subgroup information containing dynamic binding logic is generated. This method supports dynamic adaptation of constraints and identifiers, has strong cross-system compatibility, and is suitable for scenarios with frequent changes in hierarchical constraints.

[0104] Step E12: Based on the subgroup basic information and the condition group data structure specification, create a condition group basic structure with the type marked as subgroup, the initial logical relationship set as AND, and inheriting the root group hierarchical constraints.

[0105] In this embodiment, the condition group data structure specification refers to a pre-defined, unified standard for the condition group framework structure, attribute fields, and format requirements. "Type tag as subgroup" means adding a type label to the condition group's basic structure to explicitly identify it as a subgroup. "Initial logical relationship set to AND" refers to the default association logic configured when the subgroup is created, which must be simultaneously satisfied by the sub-items. "Inherit root group hierarchy constraints" means that the subgroup adopts the root group's nesting depth restrictions, sub-item type restrictions, and other hierarchy rules. The condition group basic structure refers to the initial framework of the subgroup that includes type tags, logical relationships, hierarchy constraints, and unique identifiers.

[0106] As an optional implementation, the unique group identifier, hierarchical constraint rules, and logical relationship configuration specifications are extracted from the subgroup basic information, and the condition group data structure specification is read from local storage. A condition group framework is created according to the specification, a type marker field is added to the framework and assigned a subgroup value, the initial logical relationship is set to AND according to the logical relationship configuration specification, the hierarchical constraint rules of the root group in the subgroup basic information are fully inherited, and the basic attributes required by the local specification are supplemented. The completeness of the framework's attributes, format compliance, and the accuracy of hierarchical constraint inheritance are verified through a locally built-in structure verification mechanism to ensure that the type marker, logical relationship, and hierarchical constraints are consistent with the specification, ultimately generating a condition group basic structure that conforms to the local standard. This method relies on local configuration and specifications to complete the creation, requires no network interaction, and has a fast response time and a simple process.

[0107] Step E13: Incorporate the subgroup basic framework of the associated empty array into the root group sub-item storage array of the condition group basic structure to generate the hybrid sub-item structure.

[0108] In this embodiment, an empty array refers to creating a blank data container without initial elements, specifically for storing sub-items under a subgroup. The subgroup basic framework refers to the initial structure containing subgroup type markers, initial logical relationships, unique group identifiers, and hierarchical constraints.

[0109] As an optional implementation, an empty array without initial elements is created. Basic attributes such as sub-item type restrictions and sequential storage rules are set according to the local subgroup storage array format specification. This empty array is then associated with the subgroup's basic framework, establishing it as the exclusive storage container for the current subgroup. An association identifier is recorded to ensure unique ownership. The sub-item storage array of the root group in the condition group's basic structure is extracted. According to locally preset sub-item inclusion rules, the subgroup's basic framework associated with the empty array is added to this sub-item storage array, and the total number of sub-items and sub-item type distribution statistics fields of the root group are updated synchronously. A locally built-in structure verification mechanism checks the validity of the association between the empty array and the subgroup's basic framework, the compatibility of the array format with the subgroup's hierarchical constraints, and the logical consistency of the root group's sub-item storage array after inclusion. After confirming no association conflicts, format deviations, or statistical errors, the hybrid sub-item structure is output. This method relies on local specifications to complete the association and inclusion, requires no network interaction, has a fast response time, and a simple process, enabling rapid generation of hybrid sub-item structures.

[0110] For example, in a component construction scenario, the hierarchical constraint rules of the root group in the added condition item structure are "nesting depth ≤ 2, allowing sub-items to be condition items / sub-sub-groups", the logical relationship configuration specifications are "optional logic 'AND / OR', default logic 'AND', configuration format is character type", and the sub-item identifier generation standard is "prefix 'sub' + 8-digit alphanumeric combination". A globally unique identifier generation algorithm is called to generate a unique sub-group identifier "sub7f2d9a4c" according to the standard. The above rules, specifications, and identifiers are integrated to generate the basic information of the sub-group. Based on this basic information of the sub-group and the condition group data structure specifications (including type marker fields, logical relationship fields, and hierarchical constraint fields), a basic condition group structure is created with the type marker "sub-group", the initial logical relationship set to "AND", and inheriting the root group hierarchical constraints (nesting depth ≤ 2, sub-item type restrictions). Initialize an empty array "[]", set the array sub-item type restriction according to the specification (only accept condition items / subgroups), establish a belonging association with the subgroup basic framework, mark the association identifier "rel_004", extract the root group sub-item storage array of the condition group basic structure (originally containing 2 independent condition items: cond_004, cond_005), add the subgroup basic framework of the associated empty storage array to the root group sub-item storage array according to the sorting rules, update the total number of root group sub-items to 3, and the sub-item type distribution to "2 condition items, 1 subgroup", and output the mixed sub-item structure after passing the structure verification (root group sub-item storage array = [cond_004, cond_005, subgroup with empty array sub7f2d9a4c]).

[0111] By automatically extracting the root group configuration to generate basic subgroup information, creating subgroup structures according to specifications, associating empty arrays and incorporating them into the root group management, the problems of cumbersome subgroup creation and configuration, non-unique identifiers, and chaotic hierarchical constraints in component construction are solved, thereby improving the standardization, uniqueness of identifiers, and configuration efficiency of subgroup construction.

[0112] Based on any of the above embodiments, in Embodiment Seven of this application, step S40 includes steps F11 to F13: Step F11: Remove non-core fields from the multi-level conditional query structure, retain the core business data, and obtain the core query data structure.

[0113] In this embodiment, non-core fields refer to auxiliary fields that do not support query execution logic and are only used for local rendering, state management, or adaptation. Core business data refers to the critical data that ensures the implementation of the query function. The core query data structure refers to a standardized query data structure with a streamlined structure that retains only core business data after removing non-core fields.

[0114] As an optional implementation, this method extracts the complete hierarchical data of the multi-level conditional query structure, reads a locally preset list of core fields, and traverses each level of the structure from top to bottom, filtering and retaining the core business data specified in the list one by one, while removing non-core fields such as style configurations, local status identifiers, creation timestamps, and temporary cache parameters. The filtered structure undergoes local integrity verification to check for missing core fields, intact hierarchical relationships, and unbroken logical configurations. Simultaneously, the data is arranged according to a locally simplified format to ensure structural regularity, ultimately outputting a core query data structure that meets local query execution requirements. This method relies on a locally fixed list of core fields for filtering, requires no network interaction, has a fast processing speed and a simple workflow, can quickly achieve data structure simplification, and is highly stable.

[0115] As an alternative implementation, a multi-level conditional query structure and component query execution dependency data are extracted. A request is sent to a remote field recognition service, carrying the structure data and query scenario identifier. The service receives intelligent recognition rules returned remotely, including field function classification algorithms and query dependency determination criteria. The algorithm analyzes the functional attributes of each field, including core business and auxiliary rendering, and determines whether a field is necessary for the query based on query dependencies. Core query data is automatically filtered, and non-core fields are accurately eliminated. The initially simplified structure is reported for remote verification to confirm the integrity of core data and query adaptability. After receiving optimization suggestions, adjustments are made, and the core query data structure is output. This method supports intelligent field recognition and dynamic filtering, with high accuracy in elimination, and is suitable for scenarios with dynamically changing core fields and complex query scenarios.

[0116] Step F12: Based on the preset template data specifications of the component, supplement the necessary metadata of the core query data structure, unify the field naming format and hierarchical nesting rules, and output a standardized template data structure.

[0117] In this embodiment, the component's preset template data specification refers to the standardized configuration built into the component, which includes a unified data structure, field naming requirements, and hierarchical nesting restrictions. Necessary metadata refers to the basic information supporting data standardization and interaction that is missing from the core query data structure. A unified field naming format refers to adjusting the case, prefixes, suffixes, and expression methods of field names according to the specifications to ensure consistent naming. Hierarchical nesting rules refer to the standards that define the inclusion relationship of data levels, the upper limit of nesting depth, and the order of sub-items. A standardized template data structure refers to a well-organized data structure that conforms to the global interaction specifications after supplementing necessary metadata, unifying the naming format, and implementing nesting rules.

[0118] As an optional implementation, this method extracts complete core business data from the core query data structure, reads the locally stored component preset template data specifications, determines the necessary metadata list, field naming format requirements, and hierarchical nesting rules for the core query data structure, supplements the locally preset necessary metadata according to the necessary metadata list, adjusts the field names of the core data one by one to conform to the naming format, and reconstructs the hierarchical structure to adapt to the nesting rules. A locally built-in format validation mechanism verifies naming consistency, hierarchical compliance, and metadata integrity to ensure no format deviations or rule conflicts. The data is arranged according to the local specifications, and finally, a template data structure conforming to local standardization requirements is output. This method relies on locally preset specifications to complete the processing, requires no network interaction, and has a fast response speed and a simple process.

[0119] Step F13: The standardized template data structure is serialized and converted into text format data that can be transmitted and stored across scenarios, forming the target component construction template.

[0120] In this embodiment, cross-scenario transmission refers to the ability to transfer data seamlessly between different systems, platforms, or environments. Stored text-formatted data refers to text-based data that is suitable for persistent storage, has a uniform format, and is easy to parse.

[0121] As an optional implementation, this method extracts the complete fields and hierarchical relationships of the standardized template data structure, reads locally preset serialization rules, including target text format standards, field value escaping rules, and hierarchical relationship separator definitions. The structured data is converted to text format layer by layer according to these rules, with special characters undergoing locally preset escaping processing to ensure no syntax conflicts in the text format. Simultaneously, the relationships between core fields and hierarchical nesting logic are preserved. After conversion, a local text format verification mechanism checks the text's parsability, field completeness, and accuracy of hierarchical expression. Once it is confirmed that there is no data loss or formatting error, the text is formatted according to local storage specifications, outputting a target component construction template that can be stored locally and reused in local scenarios. This method relies on local serialization rules to complete the conversion, requires no network interaction, has a fast processing speed and a simple workflow, can quickly generate usable text format templates, and exhibits strong stability.

[0122] For example, in a component-based scenario, the multi-level conditional query structure includes a root group identifier "root_003", a subgroup "sub_g_8a3e6d1b", and two conditional items (cond_006 and cond_007). Non-core fields include "style_config", "create_time", and "local_status". The core business data consists of the root group identifier, subgroup identifier, field identifiers of the conditional items ("order_type" and "pay_time"), logical rule identifiers ("equal" and "greater_than"), hierarchical affiliation, and logical relationship ("AND"). After removing the non-core fields, the core query data structure is obtained, which includes the core business data of the root group, subgroups, and conditional items. Based on the component's preset template data specifications, supplement necessary metadata (data version number "v1.2", business domain category "order_query", validation rule identifier "check_005"), unify the field naming format to lowercase ("root_id", "sub_group_id", "field_id"), reconstruct the structure according to the hierarchical nesting rules of "root group, subgroup, condition item", and output a standardized template data structure, including metadata, core business data after unified naming, and standardized hierarchy. By using JSON serialization, the standardized template data structure is converted into text format data that can be transmitted and stored across different scenarios ({"root_id":"root_003","sub_group_id":"sub_g_8a3e6d1b","metadata":{"version":"v1.2","business_domain":"order_query"},"conditions":[{"field_id":"order_type","rule_id":"equal"},{"field_id":"pay_time","rule_id":"greater_than"}]}), thus obtaining the target component construction template.

[0123] By eliminating redundant fields, standardizing data formats, and performing serialization conversion, the problems of data redundancy, inconsistent formats, and difficulty in cross-scenario reuse in component construction have been solved, thereby improving data conciseness, standardization, and cross-scenario reuse efficiency.

[0124] Based on any of the above embodiments, in Embodiment Eight of this application, referring to Figure 4 , Figure 4 This is a flowchart illustrating the eighth embodiment of the component construction method based on interactive conditions of this application. Following step S40, steps G11-G13 are also included: Step G11: Collect feedback data on the target component construction template in actual reuse scenarios to obtain template usage feedback dataset.

[0125] In this embodiment, actual reuse scenarios refer to various specific usage environments in which the template is applied to component construction. Feedback data refers to usage-related data generated during template reuse. Template usage feedback dataset refers to a structured data set that integrates feedback data from various reuse scenarios and organizes it according to a unified standard.

[0126] As an optional implementation, this method monitors the calling behavior of the target component construction template in actual reuse scenarios, captures core feedback data in real time during the template reuse process, and categorizes and labels the captured data according to locally preset feedback data collection specifications, filtering out invalid and redundant data. The categorized feedback data is stored in a local data container in timestamp order. The integrity of the locally stored feedback data is periodically verified; after confirming that no core fields are missing, all valid feedback data is integrated according to local data format requirements to form a well-structured template usage feedback dataset. This method relies on a local real-time capture and storage mechanism, requires no network interaction, has a fast data collection response speed, and can quickly summarize feedback information from local reuse scenarios.

[0127] Step G12 involves statistically analyzing the template usage feedback dataset to identify combinations of frequently failing adaptation fields and rules, frequently adjusted logical relationship types, and control configurations prone to rendering anomalies. The core issues requiring optimization in the target component construction template are then extracted and integrated to generate a template optimization requirement list.

[0128] In this embodiment, the combination of frequently failing adaptation fields and rules refers to the association combination of field identifiers and logical rules that frequently cause adaptation conflicts in reuse scenarios. Frequently adjusted logical relationship types refer to logical relationship types that users modify multiple times during template reuse. Control configurations prone to rendering anomalies refer to configurations such as control type identifiers and data loading parameters that frequently cause control rendering failures and style errors. Core issue points refer to key issues affecting template reuse efficiency, adaptability, and stability. The template optimization requirement list refers to a structured list that integrates the core issue points that need optimization, clearly defining the optimization direction and priority.

[0129] As an optional implementation, the template feedback dataset is read, and the data is categorized and broken down according to preset analysis dimensions. The frequency of adaptation failures for each field and rule combination is counted, and combinations with frequencies exceeding a preset threshold are filtered out. The number of adjustments for logical relationship types is counted, and the type with the highest adjustment frequency is identified. Records related to control rendering anomalies are extracted, and the common characteristics of the control configurations corresponding to the anomalies are analyzed. High-frequency adaptation failure combinations, frequently adjusted logical relationship types, and control configurations prone to rendering anomalies are correlated and compared with the template structure to locate the template configuration nodes causing the problems. Core issues such as insufficient adaptation compatibility, unreasonable default configuration of logical relationships, and narrow adaptation range of control configurations are extracted. The optimization priorities are determined by sorting the problems according to their frequency of occurrence, and problem descriptions and preliminary optimization directions are supplemented to generate a clearly structured template optimization requirement list. This method relies on local preset analysis dimensions to complete the processing, requires no network interaction, has a fast analysis speed and a simple process, can quickly locate high-frequency problems, and is suitable for template optimization in local independent reuse scenarios.

[0130] As an alternative implementation, the template usage feedback dataset and complete template configuration data, including field rules, control strategies, and logic configurations, are synchronized to a remote correlation analysis service. A multi-dimensional correlation algorithm is then invoked to uncover the deep causal relationships between the feedback data and configuration parameters. By combining historical data from global template reuse with industry-standard configurations, the root causes of problems are identified, distinguishing between common and unique issues. Prioritization is based on the scope and severity of the problem's impact, supplementing the analysis with data-driven, precise optimization suggestions, and generating a template optimization requirement list. This method supports deep causal analysis and precise problem localization, offering highly targeted and feasible optimization requirements, making it suitable for scenarios involving multi-scenario reuse and complex template configurations.

[0131] Step G13 involves adjusting the field rule mapping relationship, optimizing the control type matching strategy, improving the default configuration of nested logic, and updating the core business data and standardized structure of the template to generate an optimized component building template for the issues in the template optimization requirement list.

[0132] In this embodiment, the field rule mapping relationship refers to the association and correspondence between field identifiers and logical rules. The control type matching strategy refers to the adaptation method for determining the control type corresponding to the combination of fields and rules. The default configuration of nested logic refers to the basic configuration such as the default logical relationships and hierarchical constraints when subgroups are created. Core business data refers to the key data that ensures template reuse and component construction. The optimized component construction template refers to a standardized text format template with improved adaptability and reusability after problem adjustments and configuration updates.

[0133] As an optional implementation, this method reads the core issues from the template optimization requirement list, retrieves the locally stored field rule mapping table, and adjusts the mapping relationships for frequently failing field and rule combinations. It optimizes the control type matching strategy, replacing control configurations prone to rendering errors with locally validated adaptation schemes, thus expanding the compatibility range between control types and field data types. Referring to frequently adjusted logical relationship types, it improves the default configuration of nested logic, setting frequently adjusted logical relationships as new default values ​​to enhance the compatibility of hierarchical constraints. Based on the adjusted configuration, it updates the core business data of the template, reconstructs the hierarchy and field naming according to local standardized structural specifications, and verifies the adjusted configuration for conflicts through a locally built-in adaptability verification mechanism, ensuring the integrity of core business data and compliance of the standardized structure. Finally, it generates an optimized component building template adapted for local reuse scenarios. This method relies on local configuration for optimization and adjustment, requires no network interaction, has a fast optimization response speed and a simple process, and can quickly resolve frequently occurring local issues.

[0134] For example, in a component building scenario, the target component building template was called in 100 actual reuse scenarios. The collected template usage feedback dataset contained data such as adaptation results, logic adjustment records, and rendering status. Among them, the combination of the field "user_type" and the rule "in" failed to adapt 15 times, and the combination of the field "order_amount" and the rule "between" failed to adapt 12 times. The logical relationship "OR" was adjusted by the user 20 times, and "AND" was adjusted 8 times. The control type "multi_select" showed rendering errors in 18 scenarios. By statistically analyzing this template usage feedback dataset, the high-frequency adaptation failure field and rule combinations ("user_type-in", "order_amount-between"), frequently adjusted logical relationship types ("OR"), and control configurations prone to rendering anomalies ("multi_select") were identified. The core issues of incompatible field rule mappings, unreasonable default configurations of logical relationships, and narrow control adaptation range were extracted, and a template optimization requirement list was generated. To address the list issue, we adjusted the field rule mapping relationship (adding a compatibility parameter for the "in" rule to "user_type" and optimizing the numerical format validation of the "between" rule for "order_amount"), optimized the control type matching strategy (replacing "multi_select" with the more adaptable "tag_select" control), improved the default configuration of nested logic (setting the default logical relationship to "or"), updated the core business data of the template (correcting field, rule, and control association information) and standardized structure, and generated an optimized component building template.

[0135] By collecting feedback in a closed loop, accurately locating problems, and optimizing configurations in a targeted manner, the problems of low template reuse rate, numerous adaptation conflicts, and high adjustment costs in component building have been solved, thereby improving the success rate of template reuse, the accuracy of adaptation, and the efficiency of component building.

[0136] This application provides a component building apparatus, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the interactive condition-based component building method in Embodiment 1 above.

[0137] The following is for reference. Figure 5 The diagram illustrates a structural schematic suitable for implementing the component building apparatus of the embodiments of this application. The component building apparatus in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, mobile development terminals, personal digital assistants (PDAs), tablet computers (PADs), portable media players (PMPs), testing and verification equipment, and fixed terminals such as compatibility testing equipment and desktop computers. Figure 5 The component building device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0138] like Figure 5As shown, the component building device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the component building device. The processing unit 1001, the ROM 1002, and the RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the component building device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows component building devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0139] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0140] The component building device provided in this application, employing the interactive condition-based component building method described in the above embodiments, can solve the technical problem of excessively high development complexity. Compared with the prior art, the beneficial effects of the component building device provided in this application are the same as those of the interactive condition-based component building method provided in the above embodiments, and other technical features of this component building device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0141] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0142] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0143] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the component construction method based on interactive conditions in the above embodiments.

[0144] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, radio frequency (RF), etc., or any suitable combination thereof.

[0145] The aforementioned computer-readable storage medium may be included in the component building apparatus or may exist independently and not assembled into the component building apparatus.

[0146] The aforementioned computer-readable storage medium carries one or more programs that, when executed by a component building device, cause the component building device to: initialize a root condition group by using a preset date range condition as an initial retrieval default constraint, thereby obtaining a default root condition group; in response to a user's selection operation on the secondary fields and logical rules in the default root condition group, match and filter target controls, and render the target controls to generate corresponding condition item structures; in response to an addition operation on the condition item structure, determine the added condition item structure to construct nested condition groups; and based on a template saving operation, serialize the multi-level condition query structure and output a reusable target component building template.

[0147] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0148] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0149] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0150] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described interactive condition-based component construction method, thereby solving the technical problem of excessively high development complexity. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the interactive condition-based component construction method provided in the above embodiments, and will not be repeated here.

[0151] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A component construction method based on interactive conditions, characterized in that, The method includes: The default root condition group is initialized by using the preset date range as the initial search default constraint. In response to the user's selection operation on the secondary fields and logical rules in the default root condition group, the target control is matched and filtered, and the target control is rendered to generate the corresponding condition item structure; In response to the addition operation on the condition item structure, the added condition item structure is determined to construct a nested condition group; The core hierarchical configuration and logical association information of the nested condition group adaptation are integrated to form a multi-level condition query structure; Based on the template saving operation, the multi-level conditional query structure is serialized and output as a reusable target component construction template.

2. The component construction method based on interactive conditions as described in claim 1, characterized in that, The step of initializing the root condition group by using the preset date range condition as the initial search default constraint to obtain the default root condition group includes: If the component initialization instruction is triggered, the start and end times are determined based on the current time, and a preset date range parameter is generated. According to the preset date range parameter, the attribute information and logical rules corresponding to the preset date range parameter are matched from the globally preset field configuration list to form the default condition item; After creating the condition group infrastructure marked as the root group, the default condition item is marked as a child item of the root group and stored in the array to update the condition group infrastructure to obtain the default root condition group.

3. The component construction method based on interactive conditions as described in claim 1, characterized in that, The steps of responding to the user's selection operation on the secondary fields and logical rules in the default root condition group, matching and filtering the target control, and rendering the target control to generate the corresponding condition item structure include: Based on the target secondary field selected by the user, the complete metadata corresponding to the target secondary field is retrieved from the globally preset field configuration list; Based on the root group identifier in the default root condition group and its corresponding preset strategy, the field rule association data available under the current root condition group is filtered out from the list of supported operators of the complete metadata. By associating data with the target logic rule selected by the user and the field rule, the control rendering configuration parameters are formed by matching the control type, search configuration and data loading method corresponding to the target logic rule; The rendering configuration parameters of the control are passed to the current condition item position, and the mounting and initialization of the target control are completed to generate the condition item structure.

4. The component construction method based on interactive conditions as described in claim 3, characterized in that, The step of associating data by the user-selected target logic rule and the field rule, and matching the control type, search configuration, and data loading method corresponding to the target logic rule to form the control rendering configuration parameters includes: Based on the target logical rule, match the target rule item that is consistent with the target logical rule from the valid rule list of the field rule associated data; Extract the control type identifier, search configuration type, and data source identifier corresponding to the target rule item, and integrate them to obtain the basic rule configuration; Determine the data type of the field metadata in the basic configuration of the rule and the associated data of the field rule, obtain the corresponding parameters according to the data type, and obtain the detailed parameters for data loading; Based on the basic rule configuration, the detailed data loading parameters, and the prompt information in the field metadata, the set of control rendering configuration parameters is determined.

5. The component construction method based on interactive conditions as described in claim 1, characterized in that, The step of determining the added condition item structure in response to the addition operation on the condition item structure to construct a nested condition group includes: In response to the user's operation of adding a second condition item, the second complete condition item is constructed by copying the condition item template and added to the root group sub-item storage array of the condition item structure to obtain the condition item structure after the addition. Based on the added condition item structure, create a condition group basic structure marked as subgroup, with an initial logical relationship of AND, and a unique group identifier, and initialize to obtain a mixed sub-item structure; Based on the hybrid sub-item structure, update the sub-item type statistics and the display adaptation status of logical selectors, determine the hierarchical affiliation relationship between each condition item and subgroup, and form the multi-level condition query structure.

6. The component construction method based on interactive conditions as described in claim 5, characterized in that, The step of creating a basic structure of condition groups marked as subgroups, with an initial logical relationship of AND and a unique group identifier, based on the added condition item structure, and initializing to obtain a mixed sub-item structure includes: Extract the hierarchical constraint rules, logical relationship configuration specifications, and sub-item identifier generation standards of the root group in the added condition item structure, and create the unique group identifier exclusive to the sub-group through a global unique identifier generation algorithm, and integrate them to obtain the basic information of the sub-group; Based on the subgroup basic information and the condition group data structure specification, create a condition group basic structure with the type marked as subgroup, the initial logical relationship set to AND, and inheriting the root group hierarchical constraints; The subgroup basic framework of the associated empty array is incorporated into the root group sub-item storage array of the condition group basic structure to generate the hybrid sub-item structure.

7. The component construction method based on interactive conditions as described in claim 1, characterized in that, The steps of serializing the multi-level conditional query structure based on template saving operations and outputting a reusable target component construction template include: Remove the non-core fields from the multi-level conditional query structure and retain the core business data to obtain the core query data structure; Based on the component's preset template data specifications, supplement the necessary metadata of the core query data structure, unify the field naming format and hierarchical nesting rules, and output a standardized template data structure; The standardized template data structure is serialized and converted into text format data that can be transmitted and stored across different scenarios, forming the target component construction template.

8. The component construction method based on interactive conditions as described in claim 1, characterized in that, After the steps of serializing the multi-level conditional query structure based on template saving and outputting a reusable target component construction template, the component construction method based on interactive conditions further includes: Collect feedback data on the target component construction template in actual reuse scenarios to obtain a template usage feedback dataset; By statistically analyzing the template usage feedback dataset, we identified combinations of fields and rules that frequently failed to adapt, types of logical relationships that were frequently adjusted, and control configurations that were prone to rendering anomalies. We also extracted the core issues that need to be optimized in the target component construction template and integrated them to generate a template optimization requirement list. To address the issues in the template optimization requirement list, the field rule mapping relationships were adjusted, the control type matching strategy was optimized, the default configuration of nested logic was improved, and the core business data and standardized structure of the template were updated to generate an optimized component building template.

9. A component assembly device, characterized in that, The component building apparatus includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the component building method based on interactive conditions as described in any one of claims 1 to 8.

10. A storage medium, characterized in that, The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, it implements the steps of the component construction method based on interactive conditions as described in any one of claims 1 to 8.

Images