A dynamic form rendering method and system based on dual-protocol separation

Abstract

The embodiment of the application discloses a dynamic form rendering method and system based on double-protocol separation, and relates to the technical field of computers, wherein the method comprises the following steps: obtaining first and second configuration information which are independent of each other, wherein the first configuration information defines form field data types and check rules, and the second configuration information defines field component types and layout modes; analyzing the two types of configuration information respectively to generate field metadata sets and layout metadata sets; combining the two types of metadata to match each field with a corresponding front-end form component; arranging the components according to the layout mode of the layout metadata to form a page structure; rendering an interactive form based on the page structure, and checking form input data by using built-in rules in the field metadata. The scheme can solve the problem that configuration maintenance and evolution are mutually restricted due to the fact that data model definitions and interface display information are interwoven in the same configuration.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a dynamic form rendering method and system based on dual protocol separation. Background Technology

[0002] In enterprise-level business management systems, forms are the core interactive interface for users to enter data, submit information, and manage business processes. Currently, the mainstream form development method is still mainly hard-coding, that is, front-end developers write corresponding page code separately for each independent business scenario (such as customer complaint forms, insurance claim forms, tax declaration forms, etc.), including hypertext markup language structure, cascading style sheets, data binding logic, front-end interactive events, and form submission interface calls, etc.

[0003] The hard-coded development approach described above has significant technical shortcomings when facing the increasingly complex business needs of enterprises undergoing digital transformation. On the one hand, there are many structurally similar fields and layouts among different business forms, but developers still need to repeatedly write similar code, resulting in high labor costs and long delivery cycles. On the other hand, business rules and interface display requirements change frequently, and any addition, deletion, or layout adjustment of fields requires developers to manually modify the code and recompile and deploy it, making it difficult to quickly respond to dynamic changes in the market and business.

[0004] To address these issues, a technical solution has emerged in the industry that generates dynamic forms through configuration. This involves describing the form structure in a configuration file, which is then dynamically generated by the rendering engine at runtime. However, in existing dynamic form solutions, information such as field data types, validation rules, page layout parameters, and component types are often intertwined within the same configuration file. When business requirements change and the page display needs adjustment, modifications that originally only involved the interface layer may require simultaneous adjustments to the data definition due to the interdependencies between configurations. Conversely, the evolution of the data structure may also disrupt existing interface configurations, resulting in a mutually restrictive relationship between configuration maintenance and evolution. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a dynamic form rendering method and system based on dual protocol separation to solve the problem in the prior art where configuration maintenance and evolution are mutually constrained because data model definition and interface presentation information are intertwined in the same configuration.

[0006] In a first aspect, embodiments of the present invention provide a dynamic form rendering method based on dual-protocol separation, comprising:

[0007] Obtain first configuration information and second configuration information. The first configuration information is used to define the data type and validation rules of the form fields. The second configuration information is independent of the first configuration information and is used to define the component type and layout mode of the form fields.

[0008] The first configuration information and the second configuration information are parsed respectively to generate a set of field metadata based on the first configuration information and a set of layout metadata based on the second configuration information.

[0009] Based on the data type information in the field metadata set and the component type information in the layout metadata set, each field is mapped to the corresponding front-end form component;

[0010] Based on the layout pattern information in the layout metadata set, the front-end form components are organized into a page structure according to the layout pattern;

[0011] An interactive form is generated based on the page structure, and the input data of the interactive form is validated according to the validation rules information in the field metadata set.

[0012] Further, the step of parsing the first configuration information and the second configuration information respectively to generate a field metadata set based on the first configuration information and a layout metadata set based on the second configuration information includes:

[0013] The first configuration information is parsed using a pattern parsing engine to extract the data type information and validation rule information of each field, and to generate the field metadata set.

[0014] The second configuration information is parsed by the pattern parsing engine to extract the component type information, layout pattern information, width information and grouping information of each field, and generate the layout metadata set.

[0015] Further, the step of organizing the front-end form components into a page structure according to the layout pattern information in the layout metadata set includes:

[0016] Based on the layout pattern information in the layout metadata set, the current layout pattern is determined, and the layout pattern includes at least two of the following: grid layout, tab layout, step bar layout, and card grouping layout.

[0017] Based on the grouping information in the layout metadata set, determine the group to which each field belongs;

[0018] According to the determined layout pattern, the front-end form components in each group are organized into corresponding page structure units. In the grid layout, each group is represented as a card group; in the tab layout, each group is represented as a tab; and in the step bar layout, each group is represented as a step.

[0019] Furthermore, when the layout mode is a grid layout, the step of organizing the front-end form components within each group into corresponding page structure units according to the determined layout mode specifically includes:

[0020] Obtain the column count and cross-column count information from the layout metadata set;

[0021] Obtain the viewport width of the current terminal, and determine the terminal type of the current terminal based on the viewport width;

[0022] The number of grid columns is determined based on the terminal type and the column number information;

[0023] Based on the column span information, determine the column span number of each field under the grid column number;

[0024] Based on the number of grid columns and the number of columns spanned by each field, the front-end form components within each group are filled into the grid to generate the page structure unit corresponding to each group.

[0025] Furthermore, the step of filling the front-end form components within each group into the grid based on the number of grid columns and the number of columns spanned by each field, thereby generating the page structure unit corresponding to each group, includes:

[0026] Based on the width information in the layout metadata set, determine the width configuration information of each field in the page structure unit;

[0027] According to the grid column number, the number of columns spanned by each field, and the width configuration information of each field, the front-end form components in each group are filled into the grid to generate the page structure unit corresponding to each group.

[0028] Further, the step of validating the input data of the interactive form based on the validation rule information in the field metadata set includes:

[0029] The current layout mode is determined based on the layout mode information in the layout metadata set;

[0030] When the determined layout mode is a step bar layout, obtain the field subset corresponding to the current step, and perform validation on the input data of the field subset based on the validation rule information;

[0031] When the determined layout mode is a tab layout, obtain the field subset corresponding to the current tab. When a tab switching instruction is received, perform validation on the input data of the field subset based on the validation rule information. If the input data fails the validation, prevent tab switching and highlight the fields that failed the validation.

[0032] Furthermore, the method also includes:

[0033] Obtain the field dependency information in the first configuration information. The field dependency information is used to characterize the activation condition or execution trigger condition of the verification rule of at least one first field, which depends on the current value of at least one second field.

[0034] A field dependency graph is constructed based on the field dependency information. The nodes of the field dependency graph represent form fields, and the directed edges represent the dependency directions between fields.

[0035] The validation of the input data for the subset of fields includes:

[0036] Based on the field dependency graph, determine the dependency relationships between the fields in the field subset;

[0037] According to the dependency order determined by the field dependency graph, each field in the field subset is validated. Fields in the field subset that are dependency sources are validated first. If the validation of a dependency source field fails, the validation of the target field that depends on the dependency source field is delayed or skipped, and a prompt message indicating that the dependency validation failed is generated.

[0038] Further, obtaining the first configuration information and the second configuration information includes:

[0039] Receive natural language descriptions;

[0040] Input the natural language description into the large language model, and obtain the first configuration information and the second configuration information output by the large language model;

[0041] Save the first configuration information and the second configuration information as a form template.

[0042] Secondly, embodiments of the present invention provide a dynamic form rendering system based on dual-protocol separation, comprising:

[0043] The protocol layer is used to store first configuration information and second configuration information. The first configuration information is used to define the data type and validation rules of the form fields, and the second configuration information is independent of the first configuration information and is used to define the component type and layout mode of the form fields.

[0044] The core processing layer is used for: parsing the first configuration information and the second configuration information respectively, to generate a field metadata set based on the first configuration information and a layout metadata set based on the second configuration information; mapping each field to a corresponding front-end form component based on the data type information in the field metadata set and the component type information in the layout metadata set; organizing the front-end form components into a page structure according to the layout mode information in the layout metadata set; rendering an interactive form based on the page structure; and validating the input data of the interactive form according to the validation rules information in the field metadata set.

[0045] The data layer is used to store the form data of the interactive form in a structured format defined by the first configuration information.

[0046] Furthermore, the core processing layer includes:

[0047] A pattern parsing engine is used to parse the first configuration information and the second configuration information respectively, generate a set of field metadata based on the first configuration information, and generate a set of layout metadata based on the second configuration information.

[0048] A component mapper is used to map each field to a corresponding front-end form component based on the data type information in the field metadata set and the component type information in the layout metadata set.

[0049] A layout renderer is used to organize the front-end form components into a page structure according to the layout pattern information in the layout metadata set.

[0050] A form engine is used to render and generate interactive forms based on the page structure.

[0051] The validation engine is used to validate the input data of the interactive form according to the validation rules information in the field metadata set.

[0052] Furthermore, the data layer stores the form data in JSON format and establishes a general inverted index to support retrieving the form data by any field.

[0053] The technical solution provided by this invention physically separates the first configuration information used to define the data model from the second configuration information used to define the presentation layer. Based on the separately parsed and generated set of field metadata and layout metadata, the component mapping is driven by data type information and component type information, and the page structure organization is driven by layout mode information. Finally, an interactive form is rendered and output, and data validation is performed based on validation rule information. This makes the data model and the presentation layer no longer mutually restrictive, and the two can be modified and evolved independently without affecting each other. This decouples the relationship and improves the flexibility and maintainability of form development. Attached Figure Description

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

[0055] Figure 1 A flowchart illustrating a dynamic form rendering method based on dual-protocol separation provided in Embodiment 1 of the present invention;

[0056] Figure 2 This is a flowchart of an embodiment of the present invention, which describes how to organize the front-end form components in each group into corresponding page structure units.

[0057] Figure 3 This is a flowchart illustrating how to perform validation on input data of a subset of fields based on a constructed complete field dependency graph, as provided in Embodiment 3 of the present invention.

[0058] Figure 4 This is a schematic diagram of a dynamic form rendering system architecture based on dual protocol separation, provided in Embodiment 4 of the present invention. Detailed Implementation

[0059] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0060] It should be understood that the described embodiments are merely some, not all, of the embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0061] The technical solution of the present invention will be described in detail below through various embodiments.

[0062] Example 1

[0063] This embodiment provides a dynamic form rendering method based on dual-protocol separation, applicable to various business scenarios requiring dynamic form generation and rendering, including but not limited to: data entry and approval forms in enterprise information management systems (such as office automation, enterprise resource planning, and customer relationship management systems); warehousing quality inspection and reporting forms in supply chain management systems; production reporting and equipment inspection forms in manufacturing execution systems; risk control approval and compliance data reporting forms in the financial industry; medical record entry and data filling forms in the healthcare field; and various application and registration forms in government service platforms. This method can be executed by the corresponding dynamic form rendering system based on dual-protocol separation. See also... Figure 1 The method specifically includes the following steps 101-105.

[0064] Step 101: Obtain the first configuration information and the second configuration information.

[0065] The first configuration information defines the data types and validation rules for the form fields. Specifically, it follows the JSON Schema specification, using a standardized JSON structure to describe the data types (e.g., strings, numbers, booleans, arrays, objects), format constraints (e.g., date formats, email formats, regular expression patterns), and validation rules (e.g., required fields, length constraints, numeric range constraints, enumeration constraints, etc.) of each field. The second configuration information is independent of the first and defines the component types and layout patterns for the form fields. Specifically, the second configuration information is independent of the first, with no nesting or dependency between them. It uses an independent configuration protocol to describe how each field should be presented as a front-end component in the user interface (e.g., input boxes, dropdown selection boxes, date pickers, radio buttons, checkboxes, etc.), and the overall form layout (e.g., grid layout, tab layout, step bar layout, or card grouping layout). Optionally, the second configuration information also includes the width strategy (e.g., percentage width, pixel width, or flexible width) and group affiliation (e.g., business groups such as "Basic Information," "Contact Information," "Approval Information," etc.) for each field. By separating the definition of data types and validation rules from the definition of component types and layout modes into two independent configuration information, the data layer and UI layer are decoupled. This allows the same set of data definitions (first configuration information) to be used with different UI definitions (second configuration information) to render forms with different styles and interaction methods. It also ensures that changes to data validation logic will not affect the UI layout configuration, and vice versa.

[0066] In traditional form configuration, users typically need the technical skills to write structured configuration information, manually defining form fields, validation rules, and UI layouts by writing configuration files in JSON or XML formats. This method not only requires a high level of technical expertise from operators but is also inefficient and struggles to quickly respond to changes in business needs. Therefore, this embodiment provides a natural language-driven automatic configuration generation mechanism, including: receiving a natural language description input by the user; inputting the natural language description into a large language model to obtain first and second configuration information output by the large language model; and saving the first and second configuration information as a form template.

[0067] In practical implementation, a unified natural language input interface can be provided to receive form business requirements described by users in natural language form, and a preset prompt template is provided, which contains explicit constraints on the output format:

[0068] The first part of the instruction instructs the large language model to generate the first configuration information according to the JSON Schema specification. This includes extracting all field names, inferring the data type of each field based on the semantics of the field names (e.g., fields containing the keyword "date" are inferred to be date type, fields containing the keywords "amount" or "number" are inferred to be numeric type, fields containing the keywords "whether" or "identifier" are inferred to be boolean type, and fields containing the keywords "list" or "set" are inferred to be array type), and extracting validation rules based on the field names and business semantics (e.g., fields containing the keywords "required" or "must" are marked as required, and fields containing the keywords "not exceeding" or "maximum" have length constraints or numeric range constraints extracted).

[0069] The second part of the instruction instructs the large language model to generate a second configuration information independent of the first configuration information. This includes matching the corresponding front-end component type for each field based on the field name and business semantics (e.g., fields containing the keyword "date" are mapped to date pickers, fields containing the keywords "dropdown" or "select" are mapped to dropdown selection boxes, fields containing the keywords "description" or "remarks" are mapped to multi-line text input boxes, and other fields are mapped to single-line text input boxes by default), and determining the overall layout mode based on the layout keywords in the user description (e.g., when the keywords "step" or "steps" are included, it is determined to be a step bar layout, when the keywords "pagination" or "tags" are included, it is determined to be a tab layout, and when the keywords "grouping" or "cards" are included, it is determined to be a card grouping layout).

[0070] Next, the prompt word template containing the aforementioned instructions is concatenated with the received natural language description and input into the large language model. The output format parameters of the large language model are set to force it to output in JSON format. The large language model performs semantic parsing on the natural language description according to the prompt word instructions, generating first configuration information and second configuration information respectively, and returns them. After receiving the output of the large language model, the system performs format validation on the generated first and second configuration information respectively, checking whether the first configuration information conforms to the JSON Schema specification format and whether the second configuration information conforms to the predefined UI configuration format specification. If the format validation passes, it is saved as a form template; if the format validation fails, the error information is fed back to the large language model according to the preset retry strategy, requesting it to correct and regenerate.

[0071] By combining natural language processing technology with the dual-protocol separation architecture of this embodiment through the aforementioned automatic configuration generation mechanism, the technical threshold for form configuration is significantly reduced, and the efficiency and intelligence of form generation are improved. Users do not need to have the technical ability to write structured configuration information; they only need to describe their business requirements in everyday language to automatically obtain a complete form configuration that conforms to the dual-protocol architecture specification of this embodiment.

[0072] In a preferred embodiment, after obtaining the first configuration information and the second configuration information, the method further includes:

[0073] (1) Perform consistency verification on the first configuration information and the second configuration information; wherein, the consistency verification includes: verifying whether all fields defined in the first configuration information have corresponding component configurations in the second configuration information, and verifying whether all fields referenced in the second configuration information are defined in the first configuration information;

[0074] When a field inconsistency is detected between the first configuration information and the second configuration information, a list of inconsistent fields is generated. This list records in detail all inconsistent fields and their inconsistency types (such as "data definition missing" or "component configuration missing").

[0075] (2) Process the inconsistent fields according to the preset resolution strategy:

[0076] If a field is defined in the first configuration information but missing in the second configuration information, it indicates that the field has a data definition but lacks UI configuration. In this case, a default component type (such as a text input box) and a default layout configuration (such as placing the field in the default group and arranging it according to the field definition order) will be automatically generated for the field.

[0077] If a field is referenced in the second configuration information but is missing in the first configuration information, it indicates that the field is referenced at the UI level but lacks a corresponding data definition. In this case, all references to the field are removed from the second configuration information, including the component configuration and layout references of the field, and a corresponding warning log is generated for the user to review.

[0078] (3) Use the resolved first and second configuration information as valid configuration information for subsequent steps.

[0079] This preferred implementation effectively avoids form rendering anomalies caused by inconsistent dual-protocol configurations through automated bidirectional consistency verification and intelligent resolution mechanisms, thereby improving the robustness and usability of the system.

[0080] More preferably, when it is detected that a corresponding component configuration is missing in the second configuration information for a first field defined in the first configuration information, an intelligent completion mechanism is triggered, which includes:

[0081] The first completion strategy is to perform word segmentation and keyword extraction on the field name of the first field, match the extracted keywords with the pre-set field name-component type mapping rule library, and recommend the corresponding component type and field width configuration based on the matching results and the data type of the first field.

[0082] Second completion strategy: When the first completion strategy fails to generate recommendation results, a query vector is constructed using the field name, data type, and group information of the first field. Similarity retrieval is performed in the historical form template library, and the configuration records of semantically similar fields retrieved are used as candidate recommendation configurations.

[0083] The third completion strategy is to make consistent adaptation adjustments to the candidate recommendation configuration based on the layout mode information of the current form, the component type and width configuration of other fields in the same group, and the type information of the current terminal.

[0084] The candidate recommended configurations are sorted from high to low according to their adaptability, and the configuration with the highest adaptability is selected as the complete configuration.

[0085] If none of the first, second, and third completion strategies can generate a completion configuration, the default configuration will be used.

[0086] Step 102: Parse the first configuration information and the second configuration information respectively, so as to generate a set of field metadata based on the first configuration information and a set of layout metadata based on the second configuration information.

[0087] Specifically, the first configuration information can be parsed using a schema parsing engine to extract the data type information and validation rule information of each field, generating a field metadata set. The field metadata set is the standardized data foundation for subsequent field mapping and validation execution. The data type information indicates the data type and format constraints of each field, and the validation rule information includes one or more validation rules such as mandatory constraints, length constraints, numerical range constraints, and enumeration value constraints for each field.

[0088] Simultaneously, the second configuration information is parsed through a pattern parsing engine to extract component type information, layout mode information, width information, and grouping information for each field, generating a layout metadata set. This layout metadata set forms the standardized layout foundation for subsequent component mapping and page structure organization. Specifically, the component type information indicates which front-end component each field should be presented as in the user interface; the layout mode information indicates whether the overall form uses a grid layout, tab layout, step bar layout, or card grouping layout; the width information indicates the width configuration information for each field, including the width strategy type and corresponding strategy parameters, with the width strategy type including at least two of percentage width, pixel width, and flexible width; and the grouping information indicates the business group to which each field belongs (such as "Basic Information," "Contact Information," "Approval Information," etc.).

[0089] It should be noted that the pattern parsing engine can use the well-known JSON parsing method in the field to perform structured parsing of the first configuration information and the second configuration information respectively, and extract the configuration information contained therein.

[0090] Step 103: Based on the data type information in the field metadata set and the component type information in the layout metadata set, map each field to the corresponding front-end form component.

[0091] Specifically, the field-to-component mapping decision needs to be determined based on both the data type information in the field metadata and the component type information in the layout metadata. Data type information describes the data nature of the field (e.g., string, number, boolean, date, etc.), while component type information describes the expected interaction form of the field in the user interface (e.g., input box, dropdown selection box, date picker, radio button, checkbox, etc.). During the mapping process, the component type information in the layout metadata is used as the primary factor to determine the corresponding front-end component type for each field. If the component type information for a certain field in the layout metadata is missing or conflicts with its data type information (e.g., the data type is boolean but the component type is configured as a date picker), then compatibility adjustments are made based on the data type information, automatically selecting the default component type that matches that data type (e.g., boolean type is mapped to a switch or radio button by default, and date type is mapped to a date picker by default). For each front-end form component obtained from the mapping, input constraints are also configured based on the data type information and validation rules in the field metadata (e.g., configuring a numeric input mode for numeric type components, configuring a maximum length limit for text type components, etc.) to ensure that the input behavior of the front-end component is consistent with the back-end data definition.

[0092] Step 104: Based on the layout pattern information in the layout metadata set, organize the front-end form components into a page structure according to the layout pattern.

[0093] After mapping each field to the front-end form components, the mapped front-end form components need to be organized into a complete page structure according to a predetermined layout pattern. The layout pattern determines how the form fields are arranged on the page and their interaction. The display order, grouping method, and user operation path of the fields are all different under different layout patterns.

[0094] Specifically, the current layout mode is determined based on the layout mode information in the layout metadata set. The layout modes include at least two of the following: grid layout, tab layout, step bar layout, and card group layout. Simultaneously, based on the grouping information in the layout metadata set, the group to which each field belongs is determined, with each group corresponding to a logically related set of fields. After determining the layout mode and grouping information, the front-end form components within each group are organized into corresponding page structure units according to the determined layout mode.

[0095] In the grid layout, each group is represented as a card group, and the field components are arranged according to the number of grid columns in each card. Users can browse and fill in all fields on the same page.

[0096] In the tab layout, each group is represented as an independent tab, and each tab contains the field components of the corresponding group. Users can switch between different groups by switching tabs.

[0097] In the step bar layout, each group represents an independent step, and each step page contains the field components of the corresponding group. Users fill in the fields of each group in the order of the steps.

[0098] In a card group layout, each group appears as an independent card area, with the cards arranged sequentially from top to bottom on the page.

[0099] Step 105: Render an interactive form based on the page structure, and validate the input data of the interactive form according to the validation rules in the field metadata set.

[0100] After organizing the front-end form components into a page structure according to step 104, the page structure needs to be rendered into an actual operable form page, and the user input data needs to be validated to ensure the validity and integrity of the data.

[0101] Specifically, based on the page structure generated in step 104, the front-end rendering engine is invoked to render the page structure into an actual interactive form page. The rendering engine calculates the final pixel width of each field within the actual width of the grid container based on the layout information of each node in the page structure (including the number of grid columns, the number of columns spanned by each field, and width configuration information), component type, and style configuration. It then generates the corresponding document object model tree and presents it as a user-visible and operable form interface. Specifically, for fields with a width strategy type of percentage, the rendering engine calculates the final pixel width by multiplying the actual available width of the field (grid column width × number of columns spanned) by a preset percentage value; for fields with a width strategy type of pixel width, the rendering engine directly uses the preset pixel value as the final pixel width; for fields with a width strategy type of flexible width, the rendering engine allocates the final pixel width according to the remaining space within the row according to a preset flexible ratio. Users can perform interactive operations such as data input, selection, editing, and deletion on the rendered form page, and the form page updates its interface status in real time based on user interactions.

[0102] After the form is rendered and presented to the user, the input data of the interactive form is validated according to the validation rules information in the field metadata set. The execution of validation rules is carried out throughout the entire interaction between the user and the form, and its basic mechanism is as follows: Each field in the form is associated with a corresponding validation rule. The validation rules are derived from the validation rule information of each field in the field metadata set, including mandatory field constraints, length constraints, numerical range constraints, format constraints (such as date format, email format, regular expression pattern, etc.), and enumeration value constraints. When the user enters or modifies data in a field, real-time validation of that field is triggered. The user's input data is compared with the validation rules defined in the field metadata. If the data meets the validation rules, the validation passes; if the data violates the validation rules, a corresponding error message is generated and presented to the user visually near the field location (such as displaying red error text below the field or adding a highlighted mark on the field border) to guide the user to correct the input error in a timely manner.

[0103] Furthermore, when a user triggers a form submission, a comprehensive validation can be performed on all fields of the form. This involves iterating through all field inputs and comparing them one by one with their respective validation rules. If all fields pass validation, submission is allowed; otherwise, submission is blocked. All failed fields are listed and scrolled to the first failed field to guide the user in correcting them. This combination of real-time and comprehensive validation provides timely feedback on user input and ensures completeness before final submission.

[0104] The technical solution provided in this embodiment separates the data model definition and interface presentation information into independent first configuration information and second configuration information. This decouples the data type and validation rules of the fields from the type and layout mode of the components, allowing each to be parsed and evolved independently. This effectively avoids the configuration coupling and maintenance conflicts caused by the intertwining of the two in traditional solutions. Based on this, the dynamic mapping and on-demand combination of field metadata and layout metadata can flexibly adapt to different component rendering and layout requirements while maintaining the centralized and unified validation logic. Ultimately, this significantly improves the maintainability, scalability, and evolutionary flexibility of form configuration.

[0105] Example 2

[0106] This embodiment, based on Embodiment 1 above, further elaborates on the step of "organizing the front-end form components into a page structure according to the layout pattern information in the layout metadata set." In this embodiment, the layout pattern is exemplified as a grid layout, and the focus is on explaining how, under the grid layout, the front-end form components in each group are organized into corresponding page structure units based on terminal adaptation, column management, and width strategy.

[0107] The grid layout refers to dividing the available area of ​​the form into several columns of equal width according to a preset number of columns. Fields are arranged sequentially from left to right and top to bottom according to a preset order, with each field occupying a preset number of columns as its width within the grid. When the remaining columns in a row are insufficient to accommodate the next field, that field automatically wraps to the beginning of the next row and continues to be arranged until all fields are placed. The number of columns each field spans (i.e., the number of columns each field occupies in the grid) can be specified independently during the configuration phase; for example, a field can be set to span 1, 2, or 3 columns. By independently configuring the number of columns spanned for each field, different fields can occupy different widths within the same grid, thus forming a flexible, non-uniform column width layout. In this embodiment, all fields of the same form together constitute a grid; rows are merely wrapping positions during the flow arrangement process and do not constitute any record boundaries in terms of business semantics.

[0108] It should be noted that the steps described in this embodiment are all internal refinements of the higher-level step in Embodiment 1, which involves "organizing the front-end form components into a page structure according to the layout pattern information in the layout metadata set." Specifically, firstly, a grid layout is determined based on the layout pattern, and the group to which each field belongs is determined based on the grouping information. Based on this, it is further specified how to organize the front-end form components within each group into corresponding page structure units according to the determined grid layout pattern. See [link to relevant documentation]. Figure 2 Specifically, this includes the following steps 201-205.

[0109] Step 201: Obtain column count information and cross-column count information from the layout metadata set.

[0110] The column count information defines the total number of columns in the grid layout by default, serving as a baseline value when there is no terminal-specific configuration. In a preferred embodiment, the column count information may further include a terminal coverage column count configuration, which specifies the number of grid columns for different terminal types. When a coverage configuration exists for the current terminal, this configuration value is used preferentially. The column span information indicates the column span occupied by each field in the grid (e.g., a field spans 2 columns). For example, for fields such as "Remarks" or "Description" that may require a larger input area, the configurator can set their column span to 3 or 4 columns in the second configuration information, allowing them to occupy a wider display area on the page than ordinary fields, thus improving the input experience. For ordinary fields, if the configurator does not set a separate column span, the default column span is 1 column. All of this information originates from the second configuration information and is part of the layout metadata set. It was already parsed in the "parse the first configuration information and the second configuration information respectively" step in Embodiment 1, and this step reads the required specific fields from it.

[0111] Step 202: Obtain the viewport width of the current terminal and determine the terminal type of the current terminal based on the viewport width.

[0112] In practice, the viewport width of the current terminal can be obtained through the browser viewport API and compared with a preset width threshold to determine the current terminal type. Specifically, the viewport width refers to the actual width of the area within the browser window that can be used to display webpage content, not the device's physical resolution. Even on the same laptop, when a user switches the browser window from full-screen mode to half-screen mode, the viewport width will decrease accordingly. This allows the terminal type to be reclassified from desktop to tablet or even mobile, thus achieving true responsive adaptation. The width threshold can be set using industry-standard breakpoints, such as classifying widths less than 768 pixels as mobile, 768 to 1024 pixels as tablet, and 1024 pixels or more as desktop. These thresholds can be flexibly customized in the second configuration information according to actual product needs.

[0113] Step 202 is the environment awareness stage in the entire dynamic adaptation process. It maps continuous viewport width values ​​to discrete terminal type labels, enabling layout decisions to be dynamically adjusted based on the user's actual access device, rather than relying on static default values. Furthermore, this step only involves layout-related parameters in the second configuration information and is completely independent of the field data types and validation rules in the first configuration information. This fully embodies the core design concept of the dual-protocol separation architecture of this invention: layout adaptation logic does not intrude on the data model, and dynamic changes in the terminal environment only affect the form's presentation layer, without affecting the stability and integrity of the data layer.

[0114] Step 203: Determine the number of grid columns based on the terminal type and the column number information.

[0115] For example, the system first obtains the preset column count coverage configuration for different terminal types from the second configuration information. This column count coverage configuration allows developers to specify the number of grid columns individually for different terminals, such as 4 columns for desktops, 3 columns for tablets, and 2 columns for mobile devices. If a column count coverage configuration for the current terminal type exists, the number of grid columns is determined directly according to this configuration, thus prioritizing the display requirements of the specific terminal; if no column count coverage configuration for the current terminal type exists, the system proceeds to the next step of column count degradation logic.

[0116] If no column count coverage configuration exists for the current terminal type, the column count information in the layout metadata set is used as the starting point for degradation, and column count degradation is performed according to the current terminal type. For example, if the column count information in the layout metadata set is 4 columns and the current terminal is a mobile device, the column count is downgraded from 4 columns to 2 columns to ensure the display effect on mobile devices; if the column count information in the layout metadata set is 3 columns and the current terminal is a tablet device, the column count is downgraded from 3 columns to 2 columns. If a valid column value is obtained after degradation, the downgraded column value is used as the grid column count; if degradation cannot be performed because the terminal type is not predefined in the degradation mapping table (e.g., non-standard terminals such as smartwatches and in-vehicle screens), or if a valid column value still cannot be obtained after degradation, the fallback logic is invoked.

[0117] In the fallback logic, the preset safe default column count is used as the final grid column count. The safe default column count is independent of the original column count information in the second configuration information. It is a pre-configured fixed value (e.g., 2 columns) to ensure that the form can be rendered normally in any extreme environment and avoid layout abnormalities due to missing configuration or terminal non-recognition.

[0118] The above example demonstrates a three-tiered decision-making logic: prioritizing overriding configuration, followed by column count degradation, and using default values ​​as a fallback. This logic is suitable for scenarios requiring fine-grained column count customization for different terminals. Each tier has independent responsibilities: overriding configuration addresses development needs, column count degradation adapts to terminals, and default values ​​ensure system usability. The hierarchical priority matches the degree of information certainty, and the configuration logic is clear. The transition conditions between each layer are clearly defined, progressing step-by-step, ultimately ensuring the output of valid grid column values ​​under any circumstances.

[0119] However, this embodiment is not limited to this. In other embodiments, step 203 can also be implemented in the following ways:

[0120] Specifically, the scaling factor mapping relationship preset for different terminal types in the second configuration information is obtained, for example, the scaling factor for desktop is 1.0, the scaling factor for tablet is 0.75, and the scaling factor for mobile is 0.5;

[0121] Based on the column count information in the layout metadata set and the scaling factor corresponding to the current terminal type, the number of grid columns is calculated as follows:

[0122] Grid column count = max(1, round(column count information × terminal scaling factor))

[0123] Here, `round` represents rounding to the nearest integer, and `max(1,...)` ensures that the number of grid columns is at least one. For example, suppose the layout metadata set contains 6 columns, the desktop scaling factor is 1.0, the tablet scaling factor is 0.75, and the mobile scaling factor is 0.5. When a user accesses the site via desktop, the number of grid columns = `round(6 × 1.0)` = 6 columns; when a user accesses the site via tablet, the number of grid columns = `round(6 × 0.75)` = 5 columns (rounded to the nearest integer); and when a user accesses the site via mobile, the number of grid columns = `round(6 × 0.5)` = 3 columns.

[0124] This implementation only requires maintaining the default column count information and the scaling factor for each terminal (usually several predefined values), making the configuration very simple. Furthermore, the number of columns for each terminal changes proportionally based on the default column count, maintaining visual consistency in the layout style. This approach is suitable for application scenarios where the types of terminals are relatively fixed and a smooth change in the number of columns is desired.

[0125] Step 204: Determine the number of columns spanned by each field under the number of grid columns based on the column span information.

[0126] After determining the number of grid columns according to step 203, it is necessary to further determine the number of columns each field occupies in the grid, that is, the number of columns each field spans.

[0127] Specifically, the preset column span for each field is obtained from the layout metadata set, and then compared with the grid column number determined in step 203. If the preset column span for a field is less than or equal to the grid column number, then the preset column span is directly used as the actual column span for that field in the current terminal. If the preset column span for a field is greater than the grid column number, then the actual column span for that field is adjusted to be equal to the grid column number, meaning that the field occupies all columns of its row in the current terminal's grid. Simultaneously, since the actual column span for that field has been adjusted to be equal to the grid column number, no other fields can be placed in the row containing that field, and subsequent fields continue to be arranged sequentially starting from the beginning of the next row.

[0128] In this way, the actual number of columns spanned by each field is limited to no more than the number of grid columns. This preserves the personal configuration intentions of the configurator for the wide display of specific fields, while ensuring the integrity and stability of the grid structure in adaptive degradation scenarios through the automatic capping mechanism.

[0129] Step 205: Based on the number of grid columns and the number of columns spanned by each field, fill the front-end form components in each group into the grid to generate the page structure unit corresponding to each group.

[0130] After determining the number of grid columns according to step 203 and the actual number of columns spanned by each field according to step 204, the front-end form components in each group need to be filled into the grid according to the grid layout to generate the page structure unit corresponding to each group.

[0131] Specifically, for each group, all front-end form components within that group are sequentially filled into the grid in a preset order. Each group shares the same grid column count and span configuration. The filling rules are as follows: components are arranged sequentially from left to right in the same row, with each component occupying the same number of columns as the actual span determined in step 204 for its corresponding field; when the remaining columns in a row are insufficient to accommodate the next component, that component automatically wraps to the beginning of the next row and continues filling until all components within the group are filled into the grid. Each group independently performs the above filling process, generating the corresponding page structure unit for that group. The page structure units for each group are independent of each other.

[0132] For example, suppose the entire form has 4 grid columns. Group 1 contains fields A (spanning 1 column), B (spanning 1 column), C (spanning 1 column), D (spanning 1 column), E (spanning 2 columns), and F (spanning 1 column). The filling process is as follows: In the first row, fill in fields A, B, C, and D in sequence, filling all 4 columns; in the second row, fill in E (spanning 2 columns) and F (spanning 1 column), E and F together span 3 columns, leaving 2 columns to the right of E, and F occupying 1 of those columns. Leave the remaining column in the second row empty; if there is also a field G (spanning 1 column) in Group 1, then this field will automatically wrap to the third row to continue the arrangement.

[0133] In a preferred embodiment, step 205 specifically includes the following sub-steps 2051-2052.

[0134] Sub-step 2051: Determine the width configuration information of each field in the page structure unit based on the width information in the layout metadata set.

[0135] Retrieve the width information of each field from the layout metadata set. The width information is an optional configuration item, and the configuration personnel can configure the width information for some or all fields according to actual needs. For fields without configured width information, the width strategy identification in this sub-step will not be performed, and the number of columns spanned determined in step 204 will be used directly for subsequent grid filling.

[0136] For fields with configured width information, the width configuration information for each field is determined based on the original configuration data in the width information. The width configuration information includes the width policy type for each field and its corresponding policy parameters. Specifically, based on the original data format or keywords in the width information, the width strategy type adopted by each field is identified, and the corresponding strategy parameter values ​​are extracted simultaneously: If the width information contains a "%" symbol or a percentage value, it is identified as a percentage width strategy, and the corresponding strategy parameter is a preset percentage value (e.g., 50%). This percentage value represents the proportion of the field width to its actual available width. The actual available width is determined by the sum of the column widths corresponding to the number of columns spanned by the field. This sum of column widths is dynamically calculated by the rendering engine based on the actual width of the grid container during the rendering stage. If the width information contains a "px" suffix or a pure numeric value, it is identified as a pixel width strategy, and the corresponding strategy parameter is a preset pixel value (e.g., 120px). This pixel value represents the fixed width of the field. If the width information contains a flexible keyword (e.g., "flex:1"), it is identified as a flexible width strategy, and the corresponding strategy parameter is a preset flexible ratio value (e.g., flex:1 or flex:2). This flexible ratio value represents the weight of the field in the remaining space within the row. The width information originates from the second configuration information and is a component of the layout metadata set.

[0137] It should be noted that the width configuration information mentioned above does not include the calculation of specific pixel values. The number of columns spanned determines the column position and column range occupied by the field in the grid (macro framework), while the width configuration information determines the field's width scaling method within that range (micro adjustment). Both are applied together in the grid filling process in sub-step 2052. The final pixel width of the field during rendering is calculated by the rendering engine in step 105 based on the actual width of the grid container, the number of columns spanned by each field, and the width configuration information. This sub-step only completes the determination and recording of the width configuration information.

[0138] Sub-step 2052: According to the grid column number, the number of columns spanned by each field, and the width configuration information of each field, fill the front-end form components in each group into the grid to generate the page structure unit corresponding to each group.

[0139] Based on the number of grid columns determined in step 203, the actual number of columns spanned by each field determined in step 204, the width configuration information of each field determined in sub-step 2051, and the front-end form components corresponding to each field, all front-end form components in each group are filled into the grid in a preset order.

[0140] The filling process follows these rules: Each field occupies a corresponding number of column positions in the grid according to its actual number of column spans. The actual available width of a field is uniquely determined by its number of column spans; that is, if it spans N columns, it occupies the sum of the widths of N columns. This value is dynamically calculated by the rendering engine based on the actual width of the grid container during the rendering phase. The number of column spans determines the number of positions that the field occupies in the grid, that is, the number of columns that the field logically occupies in the grid columns. For fields whose width configuration information has been determined in sub-step 2051, their width configuration information determines the display width of the field within the column positions it occupies—if the field is configured with a percentage width (such as 50%), its display width is 50% of its actual available width (that is, the total width of all columns it occupies); if the field is configured with a pixel width, it is displayed with a fixed pixel value. If the preset pixel value exceeds its actual available width, it is automatically compressed to within its actual available width to avoid overflow; if the field is configured with a flexible width, it is allocated according to the remaining space in the row during rendering in a flexible proportion. For fields without configured width information, their display width defaults to occupying the full width of their actual available space. This means that during rendering, the final pixel width of the field is directly equal to its actual available width, without any additional scaling. The number of columns spanned determines the space occupied by the column, while the width configuration information determines the actual display width within that space. Both affect the grid column logic level and the visual rendering level, respectively, and together determine the final presentation of the field in the grid.

[0141] Line break determination is strictly based on the number of columns (seats) spanned by each field, and is not affected by width configuration information. When the remaining number of columns in a row is insufficient to accommodate the next field, that field automatically wraps to the beginning of the next row and continues filling until all components within that group are filled into the grid. Each group independently executes the above filling process, generating its own corresponding page structure unit. Each page structure unit is a complete card group grid structure, which can be directly used for form page rendering in subsequent step 105.

[0142] The technical solution provided in this embodiment achieves dynamic adaptation capabilities based on grid layout: on the one hand, it can automatically adjust the number of columns and field widths according to the screen size of different terminals, while retaining independent column coverage configurations, making layout customization more flexible; on the other hand, by introducing multiple types of width strategies (percentage, pixel, elastic), it further refines the precise width control of each field in the grid, meeting diverse UI design needs. More importantly, all the above layout-related configurations are independently stored in the second configuration information, completely decoupled from the field data types and validation rules in the first configuration information. This ensures a responsive experience while maintaining the advantages of configuration separation architecture, effectively avoiding the problem of data model stability being affected by layout adjustments.

[0143] Example 3

[0144] This embodiment further optimizes the step of "validating the input data of the interactive form according to the validation rule information in the field metadata set" based on the above embodiments. The validation method described in this embodiment can be combined with the methods described in the foregoing embodiments to form the complete technical solution of the dynamic form rendering method of the present invention.

[0145] In this embodiment, the input data of the interactive form is validated according to the validation rule information in the field metadata set, including the following steps 301 to 302.

[0146] Step 301: Determine the current layout mode based on the layout mode information in the layout metadata set.

[0147] Specifically, layout mode information is read from the layout metadata set to determine the layout mode used by the current form. The layout mode includes at least two of the following: step bar layout, tab layout, grid layout, and card grouping layout. In this embodiment, the validation mechanism performs differentiated validation control for step bar layout and tab layout.

[0148] Step 302: Execute the corresponding verification process based on the currently determined layout pattern.

[0149] When the determined layout mode is a step bar layout, the subset of fields corresponding to the current step is obtained, and the input data of the field subset is validated based on the validation rule information in the field metadata set. For example, the validation performed under the step bar layout includes two levels: real-time validation and batch validation before step switching.

[0150] The real-time verification is as follows: when the field input value changes (for example, after the user types characters in the input box, selects a drop-down option, or toggles the status of a switch, etc.), a single-field verification of the field is immediately triggered, the current input value of the field is compared with the verification rules defined in the field metadata, and the verification result is displayed in real time near the field (e.g., a green checkmark is displayed when it passes, and a red error message is displayed below the field when it fails).

[0151] The batch validation before step switching is as follows: Upon receiving a step switching instruction (e.g., the user clicks the "Next" button), batch validation is performed on all fields in the subset of fields corresponding to the current step. This batch validation is independent of real-time validation; that is, regardless of whether a field has passed real-time validation, the complete validation logic is re-executed. After traversing the input data of each field and its corresponding validation rules, if any field fails validation, the user is prevented from jumping to the next step. All fields that failed validation are highlighted, and the user is scrolled to the position of the first field that failed validation to guide the user to correct them one by one. After the batch validation is completed, the result of the batch validation is displayed as the final validation status of the current step, overriding the display result of real-time validation.

[0152] Real-time validation is triggered field by field during user input, providing immediate feedback to the user; batch validation is triggered uniformly when the user clicks the step switching button, performing overall checks on all fields of the current step. Both operate at different stages of the user's input process: real-time validation during input and batch validation upon step submission, forming a complete validation chain from process to result.

[0153] When the determined layout mode is a tab layout, the subset of fields corresponding to the current tab is obtained. Upon receiving a tab switching instruction, the input data of the field subset is validated based on the validation rules. Similar to the step bar layout, each field in the tab layout also supports real-time validation, triggering immediate feedback field by field during user input. Furthermore, upon receiving a tab switching instruction, the following validation process is executed: Unlike the step bar layout, there is usually no strict sequential dependency between tabs in the tab layout. Therefore, in this embodiment, validation is only performed on the fields of the current tab when the user actively triggers a tab switch. If there are fields in the field subset of the current tab whose input data fails validation, tab switching is prevented, all fields that fail validation are highlighted, and the first field that fails validation is scrolled into the visible area, prompting the user to correct the error in the current tab before switching to another tab. If all fields of the current tab pass validation, switching to the target tab is allowed.

[0154] The differentiated validation process under the above step bar layout and tab layout avoids generating a large number of meaningless error messages on fields that the user has not yet filled in by limiting the validation scope to a subset of fields in the user's current operation or tab. This reduces the user's cognitive burden and improves the filling efficiency in complex form scenarios.

[0155] As a preferred implementation, this embodiment further includes field dependency-based validation optimization in addition to step 302 above, in order to further improve the accuracy of validation and user experience.

[0156] Specifically, the field dependency information in the first configuration information is first obtained. This field dependency information characterizes the enabling or execution triggering conditions of at least one first field's validation rule, which depends on the current value of at least one second field. In other words, the field dependency information describes the conditional triggering relationship between field validation rules: when the current value of the second field meets or does not meet a certain condition, the validation rule of the first field is enabled or disabled, or the validation of the first field is triggered at a specific time.

[0157] Based on the field dependency information, a complete field dependency graph is constructed for all fields in the form. The purpose of constructing a complete field dependency graph is to allow for the flexible extraction of dependency subgraphs corresponding to any subset of fields from this graph, supporting the validation requirements of different field subsets under different layout modes. Nodes in the field dependency graph represent form fields, and directed edges represent the dependency direction between fields. Specifically, if the validation rule of field A depends on the current value of field B, a directed edge from B to A is constructed in the field dependency graph, indicating that B is the dependency source of A, and A depends on B. A complete field dependency graph is formed by traversing and constructing the graph for the dependencies of all fields. After constructing the field dependency graph, cycle detection is performed. If a dependency cycle is detected (e.g., A depends on B, B depends on C, C depends on A), a dependency cycle alarm is generated, prompting the user to correct the dependency configuration to avoid deadlocks or logical errors caused by circular dependencies during the validation process.

[0158] Accordingly, see Figure 3 Based on the constructed complete field dependency graph, the process of performing validation on the input data of the field subset in step 302 includes the following sub-steps 3021-3023.

[0159] Sub-step 3021: Based on the constructed field dependency graph, determine the dependency relationships between the fields in the field subset.

[0160] Since the field subset may only contain some fields corresponding to the current step or tab, rather than all form fields, it is necessary to extract a subgraph related to the field subset from the complete field dependency graph. Only the dependency edges between fields within the field subset are retained, while dependencies involving fields outside the field subset are ignored to avoid expanding the validation scope to fields outside the current step or tab. If the source field is not in the current field subset, it is considered to have passed validation, and validation is performed directly on the target field. This processing strategy is based on the assumption that fields outside the current field subset (such as fields in previous steps) have already passed validation before entering the current step or tab, and therefore do not need to be validated again within the current validation scope.

[0161] Sub-step 3022: Perform validation on each field in the field subset according to the dependency order determined by the constructed field dependency graph.

[0162] Specifically, based on the topological sorting order of the field dependency graph, fields that are dependency sources (i.e., fields that are depended on by other fields) in the field subset are verified first, followed by target fields that depend on these dependency source fields. For fields in the field subset that have no dependency relationships, they are verified according to their original sorting order in the field subset.

[0163] Sub-step 3023: When the validation of the dependent source field fails, delay or skip the validation of the target field that depends on the dependent source field, and generate a prompt message indicating that the dependency validation failed.

[0164] For example, the validation rule for field B might depend on the current value of field A (e.g., "Field B becomes required when field A's value is 'Yes'"). When the input data for field A fails validation, since the validation prerequisite for field B (field A's value being valid) has not yet been met, the validation of field B is skipped, and the message "Field A's value is invalid; please correct it before checking field B" is displayed. This mechanism avoids a series of meaningless validation error messages caused by invalid source data, allowing users to correct errors layer by layer according to the dependency order, thus improving the efficiency and experience of form error correction.

[0165] It should be noted that the above-mentioned field dependency-based validation optimization works in conjunction with the differentiated validation process under the aforementioned step bar layout or tab layout, and does not conflict with it. Specifically, step 302 first determines the subset of fields of the current step or the current tab as the validation scope based on the layout mode. Then, within this validation scope, the validation order of each field is determined based on the field dependency graph, prioritizing the validation of dependent source fields, and blocking the validation of dependent fields if the dependent source fails. Both of these operate on two different decision dimensions: "determining the validation scope" and "determining the validation order," together constituting a complete layout-aware and dependency-aware collaborative validation mechanism.

[0166] The technical solution provided in this embodiment, through layout-aware differentiated validation, precisely limits the validation scope to a subset of fields in the current step or tab, avoiding the user experience issues caused by global validation. Through dependency-aware validation optimization, the validation order is determined according to dependencies within the field subset, prioritizing the validation of dependent source fields and blocking dependent fields if they fail, effectively preventing the cascading propagation of error messages. The two working together significantly improve the validation accuracy and user experience in complex form scenarios.

[0167] Example 4

[0168] This embodiment provides a dynamic form rendering system based on dual-protocol separation, which can be used to execute the dynamic form rendering method based on dual-protocol separation described in any of the foregoing embodiments of the present invention. See also Figure 4 The system adopts a three-layer separation architecture, which includes the following components: protocol layer 401, core processing layer 402 and data layer 403.

[0169] Protocol layer 401 is used to store first configuration information and second configuration information. The first configuration information is used to define the data type and validation rules of form fields, while the second configuration information, independent of the first configuration information, is used to define the component type and layout mode of form fields. Protocol layer 401 stores the first and second configuration information as two independent configuration protocols, with no nesting or dependency between them, and each maintaining its own independent version and lifecycle. Protocol layer 401 is also used to respond to configuration read requests from core processing layer 402, providing the requested configuration information to core processing layer 402 for subsequent processing. In addition, as an optional implementation, protocol layer 401 also supports version management of stored configuration information, including saving historical versions of configuration information, replacing the current configuration information with a specified historical version in response to version rollback instructions, and generating a visualization report of the differences between the current version and historical versions in response to configuration comparison instructions.

[0170] The core processing layer 402 is the core logic processing unit of the system, responsible for core functions such as parsing form configuration information, mapping fields to components, organizing page structure, rendering forms, and validating input data. Specifically, the core processing layer 402 is used to: parse the first configuration information and the second configuration information respectively, to generate a field metadata set based on the first configuration information and a layout metadata set based on the second configuration information; map each field to a corresponding front-end form component based on the data type information in the field metadata set and the component type information in the layout metadata set; organize the front-end form components into a page structure according to the layout mode information in the layout metadata set; render an interactive form based on the page structure; and validate the input data of the interactive form according to the validation rules information in the field metadata set.

[0171] For example, the core processing layer 402 includes the following sub-modules.

[0172] The schema parsing engine 4021 is used to parse the first configuration information and the second configuration information respectively, generating a field metadata set based on the first configuration information and a layout metadata set based on the second configuration information. Specifically, the schema parsing engine 4021 uses a well-known JSON parsing method to perform structured parsing on the first configuration information conforming to the JSON Schema specification, extracting data type information, validation rule information, and dependency information between fields to generate a field metadata set; simultaneously, it parses the second configuration information, extracting component type information, layout mode information, width configuration information, and grouping information for each field to generate a layout metadata set. The schema parsing engine 4021 is also used to perform consistency checks on the parsed field metadata set and layout metadata set, checking whether all fields defined in the first configuration information have corresponding component configurations in the second configuration information, and whether all fields referenced in the second configuration information are defined in the first configuration information. If a field is defined in the first configuration information but missing in the second configuration information, the corresponding component type and layout configuration are automatically generated for that field; if a field is referenced in the second configuration information but missing in the first configuration information, the reference to that field is removed from the second configuration information, thereby ensuring consistency between the two sets of configuration information.

[0173] Component mapper 4022 is used to map each field to a corresponding front-end form component based on the data type information in the field metadata set and the component type information in the layout metadata set. Specifically, component mapper 4022 primarily uses the component type information in the layout metadata to determine the front-end component type corresponding to each field; if the component type information of a certain field in the layout metadata is missing or conflicts with its data type information, then compatibility adjustments are made based on the data type information, and a default component type matching that data type is automatically selected.

[0174] The layout renderer 4023 is used to organize front-end form components into a page structure according to the layout pattern information in the layout metadata set. Specifically, the layout renderer 4023 determines the currently used layout pattern (including at least two of grid layout, tab layout, step bar layout, and card group layout) based on the layout pattern information in the layout metadata set, determines the group to which each field belongs based on the grouping information, and then organizes the front-end form components in each group into corresponding page structure units according to the determined layout pattern. Under grid layout, the layout renderer 4023 is also used to dynamically determine the terminal type based on the current terminal's viewport width and adaptively downgrade the number of grid columns based on the terminal type, and determine the position and display width of each field in the grid based on the number of columns spanned and the width configuration information of each field.

[0175] Form engine 4024 is used to render and generate interactive forms based on the page structure. Specifically, form engine 4024 receives the page structure generated by layout renderer 4023, calls the front-end rendering engine to render the page structure into an actual interactive form page, generates the corresponding document object model tree, and presents it as a form interface that is visible and operable to the user. The user can perform interactive operations such as data input, selection, and editing in the rendered form.

[0176] The validation engine 4025 validates the input data of interactive forms based on validation rules in the field metadata set. Specifically, the validation engine 4025 supports layout-aware validation and dependency-aware validation, and can apply both mechanisms simultaneously. In layout-aware validation, the validation engine 4025 determines the current layout mode based on the layout mode information in the layout metadata. When the layout mode is a step bar layout, it obtains the field subset corresponding to the current step and performs real-time validation and batch validation before step switching. When the layout mode is a tab layout, it obtains the field subset corresponding to the current tab and performs validation upon receiving a tab switching instruction. In dependency-aware validation, the validation engine 4025 obtains the field dependency information in the first configuration information, constructs a field dependency graph, and performs validation according to the dependency order determined by the dependency graph. It prioritizes validating dependent source fields and delays or skips the validation of target fields that depend on that dependent source field if the validation of a dependent source field fails. Layout-aware validation and dependency-aware validation can work together: layout-aware validation determines a subset of fields in the current step or tab as the validation scope, while dependency-aware validation determines the validation order of each field within that scope. The two work on two different decision dimensions: "determining the validation scope" and "determining the validation order," together forming a complete layout-aware and dependency-aware collaborative validation mechanism.

[0177] Data layer 403 is used to store the form data of the interactive form according to the structured format defined in the first configuration information. Specifically, after the user completes the data input and submits the interactive form rendered by form engine 4024, data layer 403 persistently stores the user-input form data according to the field data types and structured format defined in the first configuration information. For example, data layer 403 uses JSON format to store the form data. JSON format can provide efficient indexing support and data query performance while maintaining the flexibility of the JSON document structure. Data layer 403 is also used to build a general inverted index to support the retrieval of the form data by any field, without the need to pre-build a separate index for each field, thereby supporting flexible retrieval and querying of the form data.

[0178] The dynamic form rendering system based on dual protocol separation in this embodiment can realize the dynamic form rendering method based on dual protocol separation described in any of the foregoing embodiments. Its implementation principle and corresponding technical effects are basically the same as those in the foregoing method embodiments, and will not be repeated here. The configuration information interaction between the protocol layer 401 and the core processing layer 402, the data transfer between the engines within the core processing layer 402, and the form data flow between the core processing layer 402 and the data layer 403 all follow the steps and processing logic described in the foregoing method embodiments. Those skilled in the art, based on reading the foregoing method embodiments, can understand the specific functions and collaborative relationships of the various components of the system described in this embodiment.

[0179] It should be noted that in this article, relational terms such as "first" and "second" are only used to refer to...

[0180] Distinguishing one entity or operation from another does not necessarily require or imply these distinctions.

[0181] There is no such actual relationship or order between entities or operations. Furthermore, the terms "including" and "package" do not apply.

[0182] The word "comprise" or any other variation thereof is intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprises a..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0183] In this embodiment of the invention, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0184] The various embodiments in this specification are described in a related manner. The same or similar parts between the various embodiments can be referred to each other. Each embodiment focuses on describing the differences from other embodiments.

[0185] In particular, the device embodiment is basically similar to the method embodiment, so the description is relatively simple. For relevant details, please refer to the description of the method embodiment.

[0186] For ease of description, the above apparatus is described by dividing it into various functional units / modules. Of course, in implementing this invention, the functions of each unit / module can be implemented in one or more software and / or hardware.

[0187] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

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

Claims

1. A dynamic form rendering method based on dual-protocol separation, characterized in that, include: Obtain first configuration information and second configuration information. The first configuration information is used to define the data type and validation rules of the form fields. The second configuration information is independent of the first configuration information and is used to define the component type and layout mode of the form fields. The first configuration information and the second configuration information are parsed respectively to generate a set of field metadata based on the first configuration information and a set of layout metadata based on the second configuration information. Based on the data type information in the field metadata set and the component type information in the layout metadata set, each field is mapped to the corresponding front-end form component; Based on the layout pattern information in the layout metadata set, the front-end form components are organized into a page structure according to the layout pattern; An interactive form is generated based on the page structure, and the input data of the interactive form is validated according to the validation rules information in the field metadata set.

2. The method according to claim 1, characterized in that, The step of parsing the first configuration information and the second configuration information respectively, to generate a field metadata set based on the first configuration information and a layout metadata set based on the second configuration information, includes: The first configuration information is parsed using a pattern parsing engine to extract the data type information and validation rule information of each field, and to generate the field metadata set. The second configuration information is parsed by the pattern parsing engine to extract the component type information, layout pattern information, width information and grouping information of each field, and generate the layout metadata set.

3. The method according to claim 1 or 2, characterized in that, The step of organizing the front-end form components into a page structure according to the layout pattern information in the layout metadata set includes: Based on the layout pattern information in the layout metadata set, the current layout pattern is determined, and the layout pattern includes at least two of the following: grid layout, tab layout, step bar layout, and card grouping layout. Based on the grouping information in the layout metadata set, determine the group to which each field belongs; According to the determined layout pattern, the front-end form components in each group are organized into corresponding page structure units. In the grid layout, each group is represented as a card group; in the tab layout, each group is represented as a tab; and in the step bar layout, each group is represented as a step.

4. The method according to claim 3, characterized in that, When the layout mode is a grid layout, the step of organizing the front-end form components within each group into corresponding page structure units according to the determined layout mode specifically includes: Obtain the column count and cross-column count information from the layout metadata set; Obtain the viewport width of the current terminal, and determine the terminal type of the current terminal based on the viewport width; The number of grid columns is determined based on the terminal type and the column number information; Based on the column span information, determine the column span number of each field under the grid column number; Based on the number of grid columns and the number of columns spanned by each field, the front-end form components within each group are filled into the grid to generate the page structure unit corresponding to each group.

5. The method according to claim 4, characterized in that, The process of filling the front-end form components within each group into the grid based on the number of grid columns and the number of columns spanned by each field, thereby generating the page structure unit corresponding to each group, includes: Based on the width information in the layout metadata set, determine the width configuration information of each field in the page structure unit; According to the grid column number, the number of columns spanned by each field, and the width configuration information of each field, the front-end form components in each group are filled into the grid to generate the page structure unit corresponding to each group.

6. The method according to any one of claims 1 to 5, characterized in that, The step of validating the input data of the interactive form according to the validation rule information in the field metadata set includes: The current layout mode is determined based on the layout mode information in the layout metadata set; When the determined layout mode is a step bar layout, obtain the field subset corresponding to the current step, and perform validation on the input data of the field subset based on the validation rule information; When the determined layout mode is a tab layout, obtain the field subset corresponding to the current tab. When a tab switching instruction is received, perform validation on the input data of the field subset based on the validation rule information. If the input data fails the validation, prevent tab switching and highlight the fields that failed the validation.

7. The method according to claim 6, characterized in that, The method further includes: Obtain the field dependency information in the first configuration information. The field dependency information is used to characterize the activation condition or execution trigger condition of the verification rule of at least one first field, which depends on the current value of at least one second field. A field dependency graph is constructed based on the field dependency information. The nodes of the field dependency graph represent form fields, and the directed edges represent the dependency directions between fields. The validation of the input data for the subset of fields includes: Based on the field dependency graph, determine the dependency relationships between the fields in the field subset; According to the dependency order determined by the field dependency graph, each field in the field subset is validated. Fields in the field subset that are dependency sources are validated first. If the validation of a dependency source field fails, the validation of the target field that depends on the dependency source field is delayed or skipped, and a prompt message indicating that the dependency validation failed is generated.

8. The method according to any one of claims 1 to 5, characterized in that, The process of obtaining the first configuration information and the second configuration information includes: Receive natural language descriptions; Input the natural language description into the large language model, and obtain the first configuration information and the second configuration information output by the large language model; Save the first configuration information and the second configuration information as a form template.

9. A dynamic form rendering system based on dual-protocol separation, characterized in that, include: The protocol layer is used to store first configuration information and second configuration information. The first configuration information is used to define the data type and validation rules of the form fields, and the second configuration information is independent of the first configuration information and is used to define the component type and layout mode of the form fields. The core processing layer is used to: parse the first configuration information and the second configuration information respectively, so as to generate a set of field metadata based on the first configuration information and a set of layout metadata based on the second configuration information; Based on the data type information in the field metadata set and the component type information in the layout metadata set, each field is mapped to a corresponding front-end form component; based on the layout mode information in the layout metadata set, the front-end form components are organized into a page structure according to the layout mode; an interactive form is generated based on the page structure, and the input data of the interactive form is validated according to the validation rules information in the field metadata set; The data layer is used to store the form data of the interactive form in a structured format defined by the first configuration information.

10. The system according to claim 9, characterized in that, The core processing layer includes: A pattern parsing engine is used to parse the first configuration information and the second configuration information respectively, generate a set of field metadata based on the first configuration information, and generate a set of layout metadata based on the second configuration information. A component mapper is used to map each field to a corresponding front-end form component based on the data type information in the field metadata set and the component type information in the layout metadata set. A layout renderer is used to organize the front-end form components into a page structure according to the layout pattern information in the layout metadata set. A form engine is used to render and generate interactive forms based on the page structure. The validation engine is used to validate the input data of the interactive form according to the validation rules information in the field metadata set.

11. The system according to claim 9 or 10, characterized in that, The data layer stores the form data in JSON format and establishes a general inverted index to support retrieving the form data by any field.

Images