Method and system for automatically converting dynamic form page into VUE code

By generating form structure objects, rendering driver objects, and component mounting mapping objects at runtime, the problem of inconsistency between form configuration and front-end page display in enterprise applications is solved. Dynamic form pages are automatically converted into Vue code, meeting the requirements of not needing to modify the front-end code and not needing to recompile the client.

CN121560320APending Publication Date: 2026-02-24南京通达海软件有限公司
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202511788331.0
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-12-01
Publication Date
2026-02-24

AI Technical Summary

Technical Problem

In enterprise-level applications with multiple business modules, existing technologies struggle to achieve stable mapping and loading of configuration data structures to executable front-end page code and component structures without modifying the business front-end code or recompiling the client. This is especially problematic when business form structures and field rules change frequently and client distribution environments are complex and diverse, leading to inconsistencies between form configurations and front-end page displays.

Method used

By loading the target form configuration from the form configuration repository at runtime, generating a form structure object, extracting field rendering fragments and validation script fragments, combining interaction constraints to generate a rendering driver object, and generating a component mounting mapping object in the client-side preset general Vue host container, the final page code for the Vue runtime is generated.

Benefits of technology

The system enables the addition, deletion, and modification of form configurations to be reflected in the component structure and interactive behavior in real time, without requiring changes to the business front-end code or recompiling the client. The configuration data structure and the loaded page maintain a verifiable mapping relationship.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121560320A_ABST
    Figure CN121560320A_ABST
Patent Text Reader

Abstract

The invention relates to the technical field of software deployment, and discloses a method and system for automatically converting a dynamic form page into a VUE code, and the method comprises the steps: loading target form configuration from a form configuration warehouse during operation, generating a form structure object according to field grouping information, layout fragment marks and interaction constraint labels, and generating a VUE code according to the form structure object; a field rendering fragment set and a verification script fragment set are extracted accordingly, a rendering driving object is generated in combination with interaction constraints, so that a display and verification rule has an executable carrier, a universal VUE host container and operation environment description are preset at a client, a component mounting mapping object is generated based on a form structure object and the rendering driving object, and a display and verification result is obtained. According to the method, the assembly relation between the fragment and the container is determined, and finally the VUE page code oriented to VUE operation is generated according to the object, so that a business front-end code does not need to be changed or a client side does not need to be recompiled, and the checkable consistency and immediate effectiveness of a configuration data structure and a loaded page are ensured.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of software deployment technology, and more specifically, to a method and system for automatically converting dynamic form pages into Vue code.js. Background Technology

[0002] In enterprise-level applications with multiple business modules, form pages typically serve as the human-computer interaction platform for collecting business data and driving business processes. They need to adapt to multiple terminal forms and complete page rendering under given computing power and response latency constraints. Existing technologies generally adopt static page development and deployment methods. By pre-configuring page structure, form field mapping relationships, and event handling rules, the form configuration is solidified into the front-end page resources within the client. At runtime, the corresponding page is loaded and displayed according to the pre-configured settings. Under the premise of low page structure change frequency, controllable client version update channels, and relatively slow business adjustment pace, this method can support the correspondence between form configuration and front-end page display to a certain extent.

[0003] In practical applications, on the one hand, the structure and field rules of business forms change frequently due to adjustments in business policies and the splitting or combination of processes; on the other hand, the distribution environment of the client is complex and diverse, the client program update window is limited, and different versions coexist for a long time. Under the influence of the above unstable factors, the existing method that relies on static page resources and pre-defined mapping relationships is difficult to map new form configurations to front-end page structures and interactive behaviors in a timely manner. Changes on the form configuration side and existing page resources in the client are prone to inconsistencies, which in turn affect the correspondence and verifiability between the configuration data structure and the actual loaded page. Therefore, the technical problem that needs to be solved is how to achieve a stable mapping and loading of configuration data structures to executable front-end page code and component structures without modifying the business front-end code or recompiling the client.

[0004] In view of this, the present invention proposes a method and system for automatically converting dynamic form pages into Vue code to solve the above problems. Summary of the Invention

[0005] To overcome the aforementioned deficiencies of the prior art, the present invention provides a method and system for automatically converting dynamic form pages into Vue code.

[0006] To achieve the above objectives, the present invention provides the following technical solution:

[0007] Firstly, a method is provided to automatically convert dynamic form pages into Vue code, including:

[0008] At runtime, the target form configuration is loaded from the form configuration repository, and a form structure object is generated based on the field grouping information, layout fragment tags, and interaction constraint tags in the target form configuration.

[0009] Extract the field rendering fragment set and the validation script fragment set from the form structure object, and generate a rendering driver object based on the field rendering fragment set, the validation script fragment set, and the interaction constraint tags;

[0010] The client pre-defines a general Vue host container and its runtime environment description, and generates a component mounting mapping object based on the rendering driver object, form structure object and runtime environment description.

[0011] Vue page code is generated for the Vue runtime and the general Vue host container based on the form structure object, the render driver object, and the component mount mapping object.

[0012] In some embodiments, a form structure object is generated based on field grouping information, layout fragment tags, and interaction constraint tags in the target form configuration, including:

[0013] Read field grouping information, layout fragment tags, and interaction constraint tags from the target form configuration repository; aggregate information belonging to the same field group into group records; and aggregate information referencing the same layout fragment tag into layout records.

[0014] Based on the hierarchical relationship of each group record in the target form configuration, generate the corresponding group node, and attach the layout record that references the group to the group node to obtain a set of group nodes carrying layout information;

[0015] In the set of grouped nodes carrying layout information, based on the triggering field and controlled field marked by the interaction constraint label, constraint association entries are established between the triggering field nodes and controlled field nodes located in different grouped nodes, generating a cross-group constraint association index;

[0016] The set of group nodes carrying layout information is associated with the cross-group constraint association index according to the group identifier and field identifier to form a graph data structure containing group hierarchy, layout attachment relationship and constraint association entries, and the graph data structure is used as a form structure object.

[0017] In some embodiments, generating a form structure object further includes:

[0018] In the graph data structure corresponding to the form structure object, extract the parent group identifier and layout fragment mark of each group node, combine them according to the parent-child relationship to form group path entries, and summarize them to form a group path index table;

[0019] Based on the group path index table, the group path and field identifier are combined for each field node under the group node to generate a field access path tag, and the field access path tag is written to the corresponding field node attribute;

[0020] In the graph data structure after writing the field access path marker, keep the grouping hierarchy, layout attachment relationship and constraint association items unchanged, and only add the field access path marker field to obtain a form structure object containing field access path information.

[0021] In some embodiments, a set of field rendering fragments and a set of validation script fragments are extracted from the form structure object, and a rendering driver object is generated based on the set of field rendering fragments, the set of validation script fragments, and the interaction constraint tags, including:

[0022] Traverse the field nodes in the form structure object, and generate field rendering fragments for each field node based on the layout fragment tags associated with the field nodes and the field grouping information, and collect them to form a set of field rendering fragments;

[0023] Based on the validation description of the field node in the target form configuration, the value constraint statement, prompt message script and interactive constraint label referenced by the same field node are combined to generate the corresponding validation script fragments, and collected to form a set of validation script fragments.

[0024] Using the field identifier as the key, establish binding entries between the field rendering fragment set and the validation script fragment set, and combine the field rendering fragments and validation script fragments that describe the same field to generate a field fragment binding list;

[0025] Based on the triggering relationships between fields in the field fragment binding list pointed to by interaction constraint tags, the binding entries involving different grouped fields are summarized into several rendering control channels. Each rendering control channel and its associated field fragment binding list are combined into a rendering driver object, and this rendering driver object is used as the rendering driver object generated based on the field rendering fragment set, the validation script fragment set, and the interaction constraint tags.

[0026] In some embodiments, generating a rendering driver object further includes:

[0027] In the field fragment binding list corresponding to the rendering driver object, mark each binding entry with an initialization phase identifier, interaction phase identifier, or submission phase identifier to obtain a field fragment binding list with phase identifiers;

[0028] Based on the field rendering fragment content referenced by each binding entry in the field fragment binding list with stage identifiers, the directive type tag and component attribute tag that need to be applied in the Vue page are parsed out, and the directive type tag and component attribute tag are written into the corresponding binding entries;

[0029] According to the stage identifier, the binding entries with instruction type tags and component attribute tags are divided into initialization control set, interaction control set and submission control set. The above control sets, together with the original rendering control channel information, are reorganized into structured records, and the original rendering driver object content is replaced with the structured records to obtain a rendering driver object containing stage control information.

[0030] In some embodiments, a component mounting mapping object is generated based on the rendering driver object, the form structure object, and the runtime environment description, including:

[0031] Based on the terminal type, view area division method, and available component library identifier recorded in the runtime environment description, generate a set of host container mounting slot descriptions;

[0032] Based on the field grouping information and layout fragment tags in the form structure object, the layout fragments containing each field are matched with the slot identifiers in the host container's mounting slot description set to generate a field layout slot mapping set.

[0033] Based on the set of field rendering fragments and the set of field layout slot mappings in the rendering driver object, determine the component types, attribute binding expressions and validation triggering methods that need to be mounted in each slot, and generate a list of slot component requirements;

[0034] Based on the list of slot component requirements and the set of slot descriptions for the host container, a component mounting mapping object is obtained that records the corresponding relationship between slot identifiers, component types, and attribute bindings.

[0035] In some embodiments, the process of generating a slot component requirement list based on the set of field rendering fragments and the set of field layout slot mappings in the rendering driver object includes:

[0036] Extract the display form, interactive behavior, and validation trigger timing of each field from the field rendering fragment set in the rendering driver object to construct a field rendering feature set;

[0037] Based on the field layout slot mapping set, the field identifiers in the field rendering feature set are merged with the corresponding slot identifiers to obtain the slot rendering feature set;

[0038] Based on the display form and interaction behavior recorded in the slot rendering feature set, select the component type corresponding to the available component library identifier of the host container, and generate the component attribute binding expression according to the verification triggering time to form a slot component requirement record set.

[0039] The slot component requirement record set is summarized according to the slot identifier to obtain a slot component requirement list that records the slot component type and attribute binding expression of each slot component.

[0040] In some embodiments, Vue page code for the Vue runtime and the general Vue host container is generated based on the form structure object, the rendering driver object, and the component mount mapping object, including:

[0041] Based on the field grouping information and layout fragment markers in the form structure object, and combined with the slot identifiers and component type correspondences in the component mounting mapping object, a component tree description object is constructed to record the parent-child relationship and slot hierarchy relationship.

[0042] Based on the set of field rendering fragments in the rendering driver object, each component node in the component tree description object is combined with its corresponding field rendering fragment to form a set of template fragment combinations that record node template placeholder structure and instruction binding expression.

[0043] Based on the instruction binding expressions recorded in the template fragment combination set and the property binding expressions in the component mounting mapping object, a script description object containing data source declarations, event handling functions, and component registration information is generated.

[0044] Based on the component tree description object, the template fragment combination set, and the script description object, Vue page code containing template structure fragments and script fragments is generated.

[0045] In some embodiments, the process of generating a script description object based on the instruction binding expressions recorded in the template fragment combination set and the property binding expressions in the component mounting mapping object includes:

[0046] Extract the instruction binding expressions corresponding to the field rendering fragments from the template fragment combination set, and generate the field instruction binding set;

[0047] Based on the property binding expression in the component mounting mapping object, the field identifiers in the field instruction binding set are mapped to the component property identifiers to obtain the data binding relationship set;

[0048] Based on the field identifiers involved in the data binding relationship set, and combined with the field grouping information in the target form configuration, a data source declaration record set with record field default values, validation trigger methods, and group codes is generated;

[0049] Based on the data source declaration record set and the data binding relationship set, a script description object is generated that includes a data source declaration segment, an event handling function placeholder segment, and a component registration segment.

[0050] Secondly, a system is provided for automatically converting dynamic form pages into Vue code, which implements the aforementioned method for automatically converting dynamic form pages into Vue code, including:

[0051] The structure building module is used to load the target form configuration from the form configuration repository at runtime; and to generate a form structure object based on the field grouping information, layout fragment tags, and interaction constraint tags in the target form configuration.

[0052] Rendering driver module: Used to extract the set of field rendering fragments and the set of validation script fragments from the form structure object, and generate a rendering driver object based on the set of field rendering fragments, the set of validation script fragments, and the interaction constraint tags;

[0053] Mounting mapping module: used to pre-define the general Vue host container and its runtime environment description on the client; and generate component mounting mapping objects based on the rendering driver object, form structure object, and runtime environment description.

[0054] Page generation module: Used to generate Vue page code for the Vue runtime and the general Vue host container based on the form structure object, rendering driver object, and component mounting mapping object.

[0055] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0056] This invention loads the target form configuration from the form configuration repository at runtime, generates a form structure object based on field grouping, layout fragment tags, and interaction constraint tags, presenting the field hierarchy and layout relationships in a unified manner. It then extracts a set of field rendering fragments and a set of validation script fragments from this object, and generates a rendering driver object in conjunction with interaction constraints, solidifying the display and validation rules into executable fragments. A general Vue host container and runtime environment description are preset on the client side. Based on the rendering driver object, the form structure object, and the runtime environment description, a component mounting mapping object is generated, determining the mounting boundaries and dependencies between fragments and the container. Finally, Vue page code for the Vue runtime and the general host container is generated according to the above three types of objects. Since the page code is directly derived from the configuration through the object chain at runtime, changes to the form configuration are immediately reflected in the component structure and interactive behavior without modifying the business front-end code or recompiling the client. The configuration data structure maintains a verifiable mapping relationship with the loaded page. Attached Figure Description

[0057] Figure 1 This is a flowchart illustrating a method for automatically converting a dynamic form page into Vue code according to the present invention.

[0058] Figure 2 This is a schematic diagram of the structure of a system for automatically converting dynamic form pages into Vue code according to the present invention. Detailed Implementation

[0059] To make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below with reference to specific embodiments and the accompanying drawings. In the following detailed description, many specific details are set forth to provide a thorough understanding of the exemplary embodiments described. However, it will be apparent to those skilled in the art that the described embodiments may be practiced without some or all of these specific details. In other exemplary embodiments, well-known structures have not been described in detail to avoid unnecessarily obscuring the concepts of this disclosure. It should be understood that the specific embodiments described herein are merely illustrative of the present invention and are not intended to limit the present invention. Furthermore, the various aspects described in the embodiments may be combined arbitrarily without conflict.

[0060] Example 1

[0061] Please see Figure 1 As shown, this embodiment discloses a method for automatically converting dynamic form pages into Vue code, including:

[0062] S10: Load the target form configuration from the form configuration repository at runtime; generate a form structure object based on the field grouping information, layout fragment tags, and interaction constraint tags in the target form configuration;

[0063] It should be noted that the "form configuration repository" in this embodiment can be a centralized configuration center service, a relational database, a key-value storage system, or a collection of configuration files stored in formats such as JSON and YAML. The key feature is that the runtime environment can obtain a structured target form configuration data from the form configuration repository before the form is displayed, based on query conditions such as form identifier, business function code, and version number, without relying on the repackaging and release of the front-end project code.

[0064] For example, the target form configuration includes at least the following core configuration sections:

[0065] The field grouping information configuration section is used to describe the group to which each business field belongs, the group hierarchy, and the group display order;

[0066] The layout fragment tag configuration section is used to describe the layout information of the form in the page, such as the row and column division, grid width, and container nesting relationship, and is associated with specific groups or fields through the layout fragment tag;

[0067] The interaction constraint label configuration section is used to describe the interaction logic between fields, such as explicit / implicit linkage, editable state linkage, and validation trigger linkage, including the triggering field, the controlled field, and the linkage condition expression.

[0068] In actual operation, when the front-end business page needs to display a certain form, it can request the "target form configuration" from the cloud or local configuration service through business routing, menu encoding or form encoding carried by interface parameters, and temporarily store the configuration in memory as input for subsequent construction of form structure objects.

[0069] Generate a form structure object based on the field grouping information, layout fragment tags, and interaction constraint tags in the target form configuration, including:

[0070] Read field grouping information, layout fragment tags, and interaction constraint tags from the target form configuration repository; aggregate information belonging to the same field group into group records; and aggregate information referencing the same layout fragment tag into layout records.

[0071] Based on the hierarchical relationship of each group record in the target form configuration, generate the corresponding group node, and attach the layout record that references the group to the group node to obtain a set of group nodes carrying layout information;

[0072] In the set of grouped nodes carrying layout information, based on the triggering field and controlled field marked by the interaction constraint label, constraint association entries are established between the triggering field nodes and controlled field nodes located in different grouped nodes, generating a cross-group constraint association index;

[0073] The set of group nodes carrying layout information is associated with the cross-group constraint association index according to the group identifier and field identifier to form a graph data structure containing group hierarchy, layout attachment relationship and constraint association entries, and the graph data structure is used as a form structure object.

[0074] Understandably, after reading the target form configuration from the form configuration repository, the field grouping information in the configuration is first archived, and configuration items with the same group identifier (including group title, display sort, list of sub-fields of the group, etc.) are aggregated into a group record; at the same time, the layout fragment tags appearing in the configuration are archived, and the layout attributes such as row and column information, grid width, and container type that reference the same layout fragment tag are aggregated into a layout record, so that a unified layout description can be attached to the group node later.

[0075] After aggregating the group records and layout records, group nodes are generated in memory for each group according to the parent group identifier recorded in each group record. For group records with an empty parent group identifier, the generated group node is used as the root group node. For group records with a non-empty parent group identifier, the corresponding parent group node is searched in the set of created group nodes, and the current group node is attached as a child node of the parent group node, thereby constructing a group hierarchy tree consistent with the target form configuration.

[0076] Subsequently, using the layout fragment tag stored in each group record as the key, the corresponding layout record is found from the layout record set, and the layout record is attached to the layout attribute field of the corresponding group node to form a "group node set carrying layout information". That is, each group node has both hierarchical information and is bound to a layout fragment description used to guide the front-end layout.

[0077] In the actual implementation, the runtime environment further parses the field definition section in the target form configuration, generates a field node for each field, and attaches the field node to the corresponding group node according to its group identifier, so that a field node list is formed inside each group node. Then, it parses the interaction constraint label, reads the trigger field identifier and controlled field identifier set recorded in it one by one, and locates the trigger field node and all controlled field nodes by searching by field identifier in the group node and its field node set. The linkage control relationship between these nodes is abstracted into constraint association entries.

[0078] Each constraint association entry records at least the following information: trigger field node reference or field identifier, controlled field node reference or field identifier set, linkage constraint type, and trigger condition expression. These are then collected to form a "cross-group constraint association index," which describes the linkage relationship between multiple groups and multiple fields.

[0079] Finally, the set of group nodes carrying layout information and the cross-group constraint association index are assembled in the same data structure. From the perspective of nodes, it includes group nodes and field nodes. From the perspective of edges, it includes group hierarchy edges, group and field belonging edges, group and layout fragment attachment edges, and constraint association edges between trigger fields and controlled fields, thus forming a whole graph data structure.

[0080] Generating form structure objects also includes:

[0081] In the graph data structure corresponding to the form structure object, extract the parent group identifier and layout fragment mark of each group node, combine them according to the parent-child relationship to form group path entries, and summarize them to form a group path index table;

[0082] Based on the group path index table, the group path and field identifier are combined for each field node under the group node to generate a field access path tag, and the field access path tag is written to the corresponding field node attribute;

[0083] In the graph data structure after writing the field access path marker, keep the grouping hierarchy, layout attachment relationship and constraint association items unchanged, and only add the field access path marker field to obtain a form structure object containing field access path information.

[0084] Understandably, based on the graph-like form structure object already formed above, the system will perform a top-down traversal of all group nodes, read the parent group identifier and the layout fragment marker associated with each group node, concatenate the hierarchical links from the root group to the current group into a group path entry (for example, recorded in the form of "root group identifier / intermediate group identifier / current group identifier"), and summarize the correspondence between group identifiers and group path entries into a group path index table.

[0085] Subsequently, based on the group path index table, for each field node under a group node, the group path entry of the group is combined with the field identifier carried by the field node to form a unique field access path mark for that field. For example, it can be encoded in the form of "group path + separator + field identifier". This field access path mark is written into the path attribute field of the field node. For example, the "recipient mobile number" field under a "order information" group may have a group path of "root / orderInfo" and a field identifier of "receiverMobile". The field access path mark can be written as "root / orderInfo.receiverMobile". This mark uniquely points to the field node in the entire form structure object, which facilitates data binding and event binding in the subsequent rendering driver object construction, component mounting mapping and Vue script generation process.

[0086] It should be understood that in the process of adding field access path tags to field nodes, only an attribute field for path addressing is added to the original field node structure. The original grouping hierarchy, layout attachment relationship and constraint association entries remain unchanged. Therefore, the graph data structure after writing field access path tags still maintains the original grouping structure and constraint structure, but carries additional field access path information.

[0087] S20: Extract the set of field rendering fragments and the set of validation script fragments from the form structure object, and generate a rendering driver object based on the set of field rendering fragments, the set of validation script fragments, and the interaction constraint tags;

[0088] It should be noted that the "rendering driver object" in this embodiment is used to centrally describe the display method, validation rules, and interactive relationships between each field and other fields on the page at runtime. It is an intermediate control carrier connecting the "form structure object" and the subsequent "component mounting mapping object and VUE page code generation logic". By building the rendering driver object at runtime, the rendering behavior of the front-end page can be driven entirely by the configuration and runtime parsing results, without relying on the templates and script logic hard-coded in the business front-end source code. This achieves the goal of dynamically loading the form page without modifying the business front-end code or recompiling the client.

[0089] In this embodiment, the "Field Rendering Fragment Set" mainly carries the display form information of the field, such as control type, display label, placeholder hint, default value, option source, and position information related to the layout fragment; the "Validation Script Fragment Set" mainly carries the value constraint rules of the field, error message information, and state switching scripts related to interaction constraints; the two, combined with the triggering relationship described by the interaction constraint label, can generate a structured rendering driver object after being bound to the field fragment and organized by the rendering control channel, providing a complete configuration foundation for the template instruction binding and event handling logic of Vue runtime.

[0090] Extract the field rendering fragment set and validation script fragment set from the form structure object. Generate a rendering driver object based on the field rendering fragment set, validation script fragment set, and interaction constraint tags, including:

[0091] Traverse the field nodes in the form structure object, and generate field rendering fragments for each field node based on the layout fragment tags associated with the field nodes and the field grouping information, and collect them to form a set of field rendering fragments;

[0092] Based on the validation description of the field node in the target form configuration, the value constraint statement, prompt message script and interactive constraint label referenced by the same field node are combined to generate the corresponding validation script fragments, and collected to form a set of validation script fragments.

[0093] Using the field identifier as the key, establish binding entries between the field rendering fragment set and the validation script fragment set, and combine the field rendering fragments and validation script fragments that describe the same field to generate a field fragment binding list;

[0094] Based on the triggering relationships between fields in the field fragment binding list pointed to by interaction constraint tags, the binding entries involving different grouped fields are summarized into several rendering control channels. Each rendering control channel and its associated field fragment binding list are combined into a rendering driver object, and this rendering driver object is used as the rendering driver object generated based on the field rendering fragment set, the validation script fragment set, and the interaction constraint tags.

[0095] Understandably, in the process of "traversing field nodes in the form structure object, generating field rendering fragments for each field node based on the layout fragment tags and field grouping information associated with the field nodes, and collecting them to form a set of field rendering fragments," the runtime environment will access the field nodes in the form structure object one by one, read the field identifier, field access path, group identifier, and layout fragment tag carried in the field node, and combine them with the display parameters in the target form configuration, such as the control type, display label, placeholder hint, default value, option data source, and initial visibility and editable state of the field. The above content will be assembled into a field rendering fragment corresponding to the field. After completing this operation for all field nodes, a set of field rendering fragments will be formed, providing a display description for a single field for subsequent component type selection, template placeholder structure generation, and layout restoration.

[0096] In the process of "combining the value constraint statements, prompt scripts, and state switching scripts referenced by interactive constraint tags associated with the same field node according to the validation description of the field node in the target form configuration, generating corresponding validation script fragments, and collecting them to form a set of validation script fragments", the runtime environment will read the validation configuration related to the field from the target form configuration based on the field identifier, including but not limited to the required field mark, length upper and lower limits, numerical range, regular expression rules, and cross-field consistency constraints, etc., and at the same time read the corresponding error prompt text or prompt scripts; if there is state switching logic in the interactive constraint tag that is triggered or controlled by the field, then the script descriptions of these display to hide, disable to enable, and adjust the validation rules according to the state change will be included in the validation script fragment of the field. Repeating the above operation for all field nodes will obtain the set of validation script fragments, so that the validation logic of each field has an independent and configurable script description.

[0097] In the process of "establishing binding entries between the field rendering fragment set and the validation script fragment set using the field identifier as the key, and combining the field rendering fragment and validation script fragment describing the same field to generate a field fragment binding list", the system does not copy the fragment content. Instead, it uses the field identifier or field access path as an index to summarize the corresponding field rendering fragment reference and validation script fragment reference into a single binding record. Each binding record also reserves a stage identifier and subsequent instruction type and component attribute marker fields to be further refined into control units for different lifecycle stages. All binding records are arranged sequentially to form a field fragment binding list, realizing the aggregation of field display configuration and validation configuration at the data level.

[0098] In the process of "summarizing the binding entries involving different grouped fields into several rendering control channels based on the triggering relationships between fields pointed to by interaction constraint tags in the field fragment binding list, and combining each rendering control channel and its associated field fragment binding list into a rendering driver object", the runtime environment will parse the trigger field identifier and controlled field identifier set recorded in the interaction constraint tag one by one. For each linkage rule, the binding record corresponding to the trigger field and the binding records corresponding to all controlled fields will be located in the field fragment binding list. Based on the linkage relationship, the relevant binding records will be grouped into the same rendering control channel. Each rendering control channel will record at least the trigger field identifier, the controlled field identifier set, the linkage type (e.g., visible-hidden linkage, read-only linkage, reset linkage, etc.) and the linkage condition expression. After summarizing all linkage rules, several rendering control channels will be obtained. These rendering control channels will be encapsulated together with the field fragment binding list to form the initial form of the rendering driver object, providing the basic structure for subsequent stage identifier division and instruction binding parsing.

[0099] Generating render driver objects also includes:

[0100] In the field fragment binding list corresponding to the rendering driver object, mark each binding entry with an initialization phase identifier, interaction phase identifier, or submission phase identifier to obtain a field fragment binding list with phase identifiers;

[0101] Based on the field rendering fragment content referenced by each binding entry in the field fragment binding list with stage identifiers, the directive type tag and component attribute tag that need to be applied in the Vue page are parsed out, and the directive type tag and component attribute tag are written into the corresponding binding entries;

[0102] According to the stage identifier, the binding entries with instruction type tags and component attribute tags are divided into initialization control set, interaction control set and submission control set. The above control sets, together with the original rendering control channel information, are reorganized into structured records, and the original rendering driver object content is replaced with the structured records to obtain a rendering driver object containing stage control information.

[0103] In the above process of "marking each bound entry with an initialization phase identifier, interaction phase identifier, or submission phase identifier," it can be understood that the system will mark logic that is only executed when the page is first loaded (such as default value writing, initial show / hide application, initial disabled state calculation, etc.) as the initialization phase, based on the execution timing of the rendering logic and validation logic referenced in the bound entry; mark logic that is dynamically executed with user input, field value changes, or event triggers (such as real-time validation, linked show / hide, dynamic read-only control, etc.) as the interaction phase; and mark the final state validation and data processing logic that need to be uniformly executed before the entire form is submitted as the submission phase, thereby distinguishing multiple types of script behaviors for the same field in the time dimension.

[0104] In the process of "parse out the directive type markers and component attribute markers that need to be applied in the Vue page based on the field rendering fragment content referenced by each binding entry in the field fragment binding list with stage identifiers, and write the directive type markers and component attribute markers into the corresponding binding entries", the runtime environment performs semantic parsing on the field rendering fragments associated with the binding entries. It maps the display and interaction configurations involved, such as two-way data binding, conditional rendering, loop rendering, and event listening, to data binding directives, conditional directives, list directives, and event directives supported by Vue, respectively. It maps the field value access path, explicit and implicit conditional expressions, option data source identifiers, component attribute names, event handling function placeholders, etc., to component attribute markers and writes them into the binding entries, so that each binding record has complete information of "stage + directive type + attribute binding".

[0105] In the process of "dividing the binding entries with instruction type tags and component attribute tags into initialization control sets, interaction control sets, and submission control sets according to the stage identifier, reorganizing the above control sets together with the original rendering control channel information into a structured record, and replacing the original rendering driver object content with this structured record to obtain a rendering driver object containing stage control information", the system aggregates the binding entries according to the stage identifier to form three independent but combinable control sets, and retains the cross-field linkage relationship described in the aforementioned rendering control channel. The three types of control sets and the rendering control channel are encapsulated together into a structured record as the final form of the rendering driver object. This final rendering driver object not only fully describes the template instruction and attribute binding behavior of each field at different lifecycle stages, but also centrally expresses the linkage constraints between fields. It can be directly consumed by the subsequent component mounting mapping generation module and VUE page code generation module, thereby realizing the automatic conversion of form configuration into executable VUE page code at runtime.

[0106] S30: Pre-define a general Vue host container and its runtime environment description on the client side; generate a component mounting mapping object based on the rendering driver object, form structure object, and runtime environment description;

[0107] It should be noted that the "general Vue host container" in this embodiment refers to a set of reusable Vue page hosting frameworks pre-packaged on the client side. The framework has already defined the basic view areas such as the page root node, header area, body area, and footer area, as well as several slot interfaces for mounting business components (such as main form area slot, sidebar slot, toolbar slot, pop-up slot, etc.). The host container is integrated into the client or web runtime environment once when the front-end project is packaged and released. The subsequent display of different form pages is completed only by dynamically injecting components and binding configurations, without the need to modify and compile the business code again.

[0108] Understandably, the "runtime environment description" is used to logically abstract the capability boundaries and layout constraints of the current client's runtime environment. Its content may include, but is not limited to: terminal type (such as PC browser, tablet device, mobile H5 or embedded WebView), screen width and height range, landscape and portrait orientation, available component library identifiers and component library versions, theme style markers (such as dark / light theme), etc. The runtime environment description is usually obtained through one-time detection and configuration injection when the client starts or the route is switched, and cached as structured data for subsequent steps to reference. By pre-setting a general Vue host container and its runtime environment description on the client, a unified component mounting foundation can be provided for different terminals and different layout capabilities without modifying the business page source code.

[0109] Generate a component mounting mapping object based on the rendering driver object, form structure object, and runtime environment description, including:

[0110] Based on the terminal type, view area division method, and available component library identifier recorded in the runtime environment description, generate a set of host container mounting slot descriptions;

[0111] Based on the field grouping information and layout fragment tags in the form structure object, the layout fragments containing each field are matched with the slot identifiers in the host container's mounting slot description set to generate a field layout slot mapping set.

[0112] Based on the set of field rendering fragments and the set of field layout slot mappings in the rendering driver object, determine the component types, attribute binding expressions and validation triggering methods that need to be mounted in each slot, and generate a list of slot component requirements;

[0113] Based on the list of slot component requirements and the set of slot descriptions for the host container, a component mounting mapping object is obtained that records the corresponding relationship between slot identifiers, component types, and attribute bindings.

[0114] It should be noted that when generating the "host container mounting slot description set" based on the runtime environment description, the system first reads the terminal type and view area division method recorded in the runtime environment description. For example, a horizontal split layout may be used on a PC, while a vertical scrolling layout may be used on a mobile device. Then, combined with the available component library identifiers (such as element-plus, ant-design-vue, or internally developed component libraries), a slot description record is generated for each mounting area. Each slot description typically includes at least the slot identifier, the view area to which the slot belongs (such as the main area, sidebar, or header), the order of the slot within the area, the slot size constraints (such as grid width or percentage width), whether scrolling is supported, and whether multiple components are allowed to overlap. The above records together constitute the host container mounting slot description set.

[0115] For example, in a PC environment, the view area can be predefined as "header area + left navigation + right main form area + bottom toolbar". The system will generate corresponding slot identifiers for each row or grid in the "right main form area", such as main_row1_col1, main_row1_col2, etc. In a mobile environment, linear slot identifiers distinguished by sorting number can be generated only for the "main scrolling area", such as mobile_slot_1, mobile_slot_2, etc., to reflect the differences between terminals.

[0116] When generating the "field layout slot mapping set" based on the field grouping information and layout fragment tags in the form structure object, it is understandable that the system will traverse the group nodes and field nodes in the form structure object that already carry layout fragment tags, read the layout fragment tag to which each field belongs (e.g., row1_col1, dialog_body, etc.), and then search for a slot identifier that matches or can be equivalently mapped in the slot description set mounted in the host container. After a successful match, a "field → slot" mapping record is generated, and all field mapping records are summarized to form the field layout slot mapping set. If there is no completely consistent layout fragment tag in the target terminal runtime environment, this embodiment can achieve approximate matching through preset mapping rules (e.g., "dialog box content fragments are uniformly mapped to the main pop-up slot" "two grids in a row are merged into a single column slot in narrow screens", etc.) to ensure the displayability of the same form configuration on different terminals.

[0117] When generating the "slot component requirement list" based on the set of field rendering fragments and the set of field layout slot mappings in the rendering driver object, this embodiment combines the display form (such as input box, selection box, date picker, etc.), interactive behavior (such as click pop-up, drop-down selection, instant validation feedback, etc.) of each field, as well as the slot identifier it is mapped to, to deduce the set of component types and specific attribute binding requirements that the slot needs to support. For example, if a slot contains only a "customer name" text input field, the corresponding component type can be a single-line input component, and its attribute binding includes v-model binding path, placeholder hint, maximum length, required field mark, and corresponding validation triggering time (such as out-of-focus validation or real-time validation). If a slot contains both "start date" and "end date" fields, it can be deduced from the field rendering characteristics that the slot needs to mount a "date range selection" type composite component, and the binding paths and validation rules of the left and right sub-fields can be marked in the component attributes. The "slot component requirement list" is formed by summarizing the component requirement records of all slots.

[0118] It's important to understand that in the final step of generating the "component mounting mapping object," the system uses the slot identifier as the primary key to merge the slot constraint information from the host container's slot description set with the component type and attribute binding expressions from the slot component requirement list. This forms a series of ternary association records: "slot → component type → attribute binding expression." The component mounting mapping object can be stored using key-value pairs, list structures, or graph structures, but they all share the common characteristic of containing the component type to be mounted, the data field path to be bound at runtime, event handling placeholder names, and validation triggering methods for each slot in the general Vue host container. Subsequently, during the Vue page generation and runtime loading phases, it's only necessary to traverse the component mounting mapping object to instantiate and mount the corresponding component to the host container by slot, achieving configuration-driven component rendering.

[0119] The process of generating a list of slot component requirements based on the set of field rendering fragments and the set of field layout slot mappings in the rendering driver object includes:

[0120] Extract the display form, interactive behavior, and validation trigger timing of each field from the field rendering fragment set in the rendering driver object to construct a field rendering feature set;

[0121] Based on the field layout slot mapping set, the field identifiers in the field rendering feature set are merged with the corresponding slot identifiers to obtain the slot rendering feature set;

[0122] Based on the display form and interaction behavior recorded in the slot rendering feature set, select the component type corresponding to the available component library identifier of the host container, and generate the component attribute binding expression according to the verification triggering time to form a slot component requirement record set.

[0123] The slot component requirement record set is summarized according to the slot identifier to obtain a slot component requirement list that records the slot component type and attribute binding expression of each slot component.

[0124] It should be noted that when constructing the "field rendering feature set", the system will extract information closely related to component selection one by one based on the field rendering fragments in the rendering driver object. This includes at least the field display form (e.g., text input, number input, radio button, checkbox, drop-down selection, cascading selection, date selection, time selection, date and time selection, switch, slider, text display label, etc.), interactive behavior (e.g., clicking to expand details, clicking to pop up a selection dialog box, real-time prompts when inputting, displaying instructions when hovering the mouse, etc.), and validation triggering timing (e.g., focus loss trigger, value change trigger, unified trigger before submission). This information, together with the field identifier or field access path, is organized into several field rendering feature records, constituting the field rendering feature set.

[0125] When merging field rendering features with field layout slot mapping to obtain the "slot rendering feature set", it can be understood that the system will use field identifiers as a link to merge the mapping information of "field → slot" with the feature information of "field → display form and interaction behavior". For multiple fields under the same slot identifier, their rendering features will be merged into the same slot rendering feature record, recording the display type combination, interaction requirement combination and access path of all fields in the slot. In this way, the appropriate component type can be selected based on the overall features of the slot, rather than simply stacking multiple simple components field by field.

[0126] For example, if a slot contains both a "province" field and a "city" field, and the field rendering feature set marks that the two have a cascading relationship, then in the merged slot rendering feature set, the slot will be marked as a "cascading selection" display mode, and the interaction behaviors of "the parent field is province and the lower field is city" and "the city list needs to be refreshed when the province is selected" will be recorded. In this case, when selecting the component type, the system will tend to select the "cascading selection component" provided in the component library, rather than two simple separate dropdown components.

[0127] In the process of selecting component types and generating component attribute binding expressions based on the display form and interaction behavior recorded in the slot rendering feature set, this embodiment first refers to the available component library identifier in the runtime environment description, and searches in the corresponding component library for component types that can meet the display form and interaction requirements of the slot. For example, the Input component is selected for simple text input, the DateRangePicker component is selected for date range, and the Cascader component is selected for cascading regions. Then, the field access path, validation triggering time and interaction behavior recorded in the slot rendering features are combined to map this information to specific component attribute configurations, such as: the path bound to v-model, whether to select multiple, dropdown option data source field, validation triggering event name, whether to display validation error information, whether to disable, whether to read-only, etc., and finally forming a series of "slot component requirement records".

[0128] It should be understood that when summarizing the "slot component requirement record set" based on the slot identifier at the end, the system will ensure that each slot corresponds to only one or a limited set of component descriptions that can actually be mounted. When there are multiple components that can be displayed in the same slot (such as a main input component plus an auxiliary icon button), they can also be expressed as a list of sub-components in the same slot component requirement record. The "slot component requirement list" obtained after the summary can be used as the direct input for generating component mounting mapping objects. This allows the subsequent Vue page code generation stage to quickly find the component type that needs to be instantiated and its corresponding attribute binding expression based on the slot identifier, thereby completing the automatic mapping from abstract configuration to specific runtime code.

[0129] S40: Generates VUE page code for the VUE runtime and the general VUE host container based on the form structure object, render driver object, and component mount mapping object.

[0130] It should be noted that the "VUE page code" mentioned in this embodiment mainly includes two parts: template structure fragments and script fragments. The former is used to describe the structural layout of the component tree and the instruction placeholder relationship in the general VUE host container, while the latter is used to describe runtime logic such as data source declaration, event handling functions, and component registration. By deriving the above templates and scripts from the form structure object, rendering driver object, and component mounting mapping object at runtime, instead of pre-writing specific page code in the front-end project, the dynamic loading and rendering of the target form page can be completed without modifying the business front-end source code and without recompiling the client.

[0131] Generate Vue page code for the Vue runtime and the general Vue host container based on the form structure object, render driver object, and component mount mapping object, including:

[0132] Based on the field grouping information and layout fragment markers in the form structure object, and combined with the slot identifiers and component type correspondences in the component mounting mapping object, a component tree description object is constructed to record the parent-child relationship and slot hierarchy relationship.

[0133] Based on the set of field rendering fragments in the rendering driver object, each component node in the component tree description object is combined with its corresponding field rendering fragment to form a set of template fragment combinations that record node template placeholder structure and instruction binding expression.

[0134] Based on the instruction binding expressions recorded in the template fragment combination set and the property binding expressions in the component mounting mapping object, a script description object containing data source declarations, event handling functions, and component registration information is generated.

[0135] Based on the component tree description object, the template fragment combination set, and the script description object, Vue page code containing template structure fragments and script fragments is generated.

[0136] Understandably, in the process of "constructing a component tree description object that records parent-child relationships and slot hierarchy relationships based on the field grouping information and layout fragment tags in the form structure object, combined with the slot identifier and component type correspondence in the component mounting mapping object," the system first reads the hierarchy relationship between each group node, the belonging relationship of field nodes, and the layout fragment tags corresponding to the group from the form structure object. Then, combined with the record of "slot identifier - component type - attribute binding expression" in the component mounting mapping object, it generates a corresponding component node description for each slot. The component node description includes at least the component type, the slot identifier, the parent-child node relationship, the order information in the slot or sibling nodes, and the correspondence with the layout fragment tags. By modeling all slots and their components in sequence, a component tree description object for the general Vue host container is finally obtained. This object can be regarded as a tree-like abstraction of the page structure at the logical level, providing a foundation for the subsequent generation of template structure and script logic.

[0137] In the process of "combining each component node in the component tree description object with its corresponding field rendering fragments based on the field rendering fragment set in the rendering driver object to form a set of template fragment combinations that record node template placeholder structures and instruction binding expressions," it should be understood that the runtime environment uses the component nodes in the component tree description object as the main trunk, searches for the field identifiers (or field access paths) carried by each node, and finds the corresponding field rendering fragments in the field rendering fragment set of the rendering driver object. The display form, instruction type mark, and preliminary binding expression of the field are attached to the component node. Combined with the template writing style of the component type (such as whether to use slots, whether to wrap labels, whether to embed icon buttons, etc.), a template placeholder structure is generated for each component node. Then, the template placeholder structure is combined with the corresponding instruction binding expression to form several "template fragment combination" records. After all the template fragment combination records corresponding to the component nodes are summarized, a template fragment combination set is formed, which lays the foundation for finally piecing together a complete Vue template structure fragment.

[0138] In the process of "generating a script description object containing data source declarations, event handling functions, and component registration information based on the instruction binding expressions recorded in the template fragment combination set and the attribute binding expressions in the component mounting mapping object," it can be understood that the system organizes the instruction binding expressions and attribute binding expressions at the field and component dimensions: on the one hand, it extracts the set of fields related to the data source declaration based on information such as the two-way binding path of the fields, the name of the validation trigger event, and the conditional expressions required for linkage control; on the other hand, it constructs a list of event handling functions and a list of component registrations that need to be placed in the script based on the event callback name, option data source name, and dynamic attribute name involved in the component attribute binding expression. After encapsulating the above information into a script description object, the object will contain: a data source declaration segment for initializing and maintaining form data, an event handling function placeholder segment for responding to user interaction and linkage control, and a component registration segment for registering the business components or general components needed at Vue runtime.

[0139] In the process of "concatenating Vue page code containing template structure fragments and script fragments based on component tree description objects, template fragment combination sets, and script description objects," it's important to understand that the system first performs a depth-first traversal based on the component tree description object. According to parent-child relationships and slot hierarchy, it nests the template fragments in the template fragment combination set according to the tree structure, thus concatenating a complete template structure fragment. Then, it fills the data source declaration segment, event handling function placeholder segment, and component registration segment from the script description object into a predefined Vue script skeleton (e.g., containing default exported component definitions, data functions, methods objects, components objects, etc.) to form a complete script fragment. Finally, the template structure fragment and script fragment are merged according to the organization of Vue single-file components to obtain the complete Vue page code text. This code can be directly mounted and executed at runtime as a subpage of the general Vue host container.

[0140] The process of generating a script description object based on the instruction binding expressions recorded in the template fragment combination set and the property binding expressions in the component mounting mapping object includes:

[0141] Extract the instruction binding expressions corresponding to the field rendering fragments from the template fragment combination set, and generate the field instruction binding set;

[0142] Based on the property binding expression in the component mounting mapping object, the field identifiers in the field instruction binding set are mapped to the component property identifiers to obtain the data binding relationship set;

[0143] Based on the field identifiers involved in the data binding relationship set, and combined with the field grouping information in the target form configuration, a data source declaration record set with record field default values, validation trigger methods, and group codes is generated;

[0144] Based on the data source declaration record set and the data binding relationship set, a script description object is generated that includes a data source declaration segment, an event handling function placeholder segment, and a component registration segment.

[0145] It should be noted that in the process of "extracting instruction binding expressions corresponding to field rendering fragments from the template fragment combination set and generating a field instruction binding set", the system will traverse each record in the template fragment combination set, find the template node that corresponds to a certain field rendering fragment, and extract all instruction binding content related to that field from that node. For example, instructions for two-way data binding, instructions for condition display, instructions for loop rendering options, and event listening instructions related to changes in the field value, etc. The extracted instruction binding information is archived with the field identifier or field access path as the key, thus forming a field instruction binding set, which provides a basis for subsequently building data source declarations and event handling logic according to the field dimension.

[0146] In the process of "matching field identifiers in the field instruction binding set with component attribute identifiers based on the attribute binding expression in the component mounting mapping object to obtain the data binding relationship set," it can be understood that the component mounting mapping object records the attribute binding expression of the component mounted in each slot. For example, the "value" attribute of an input component is bound to a field path, and the "options" attribute of a selection component is bound to a data source identifier. The system will use the field identifier as a link to match the fields in the field instruction binding set with the attribute binding items in the component mounting mapping object, and output the correspondence between "field identifier - component attribute identifier - binding method" to describe the binding link between template instructions, component attributes, and data fields. The set of all correspondences is the data binding relationship set, which will be reflected in the script as the bidirectional or unidirectional binding logic between fields in data, computed, or methods and component attributes.

[0147] In the process of "generating a set of data source declaration records with default values, validation triggering methods, and group codes for record fields based on the field identifiers involved in the data binding relationship set and the field grouping information in the target form configuration," it should be understood that the system first counts all field identifiers that appear in the data binding relationship set, and then looks up the default values, whether they are required, validation triggering methods (such as out-of-focus validation, real-time input validation, or unified validation before submission), and the group or partition code of the field in the target form configuration. These are then summarized into data source declaration records. Each data source declaration record contains at least the field access path, initial value, validation strategy, and group code. By generating a set of data source declaration records for all fields, the script can construct a complete initial data object and validation metadata object, which are used to initialize the form state and drive subsequent linkage control and validation logic at Vue runtime.

[0148] In the process of "combining the data source declaration record set and the data binding relationship set to generate a script description object containing a data source declaration segment, an event handling function placeholder segment, and a component registration segment," it can be understood that the system will use the data source declaration record set as a basis to generate a structured description of the data function or equivalent data declaration area in the script, and transform the default value, grouping code, and validation metadata of each field into a specific field attribute structure. At the same time, based on the data binding relationship set, it will reserve event handling function placeholders for each type of interaction behavior and validation triggering method, such as input value change events, option change events, and pre-submission validation entry events. For component types that need to be referenced in the script, a description of the component registration segment will be generated based on the component type information in the component mounting mapping object, so that the components object or equivalent component registration structure can be filled in when the Vue code is finally generated. After the above three parts are combined, the script description object is formed. Subsequently, it can be simply plugged into the predefined Vue script skeleton to obtain a script fragment that can be directly executed in the general Vue host container.

[0149] Example 2

[0150] Please see Figure 2 As shown, based on the same inventive concept, this embodiment discloses a system that includes, for details not covered in this embodiment, please refer to the relevant parts of Embodiment 1.

[0151] The structure building module is used to load the target form configuration from the form configuration repository at runtime; and to generate a form structure object based on the field grouping information, layout fragment tags, and interaction constraint tags in the target form configuration.

[0152] Rendering driver module: Used to extract the set of field rendering fragments and the set of validation script fragments from the form structure object, and generate a rendering driver object based on the set of field rendering fragments, the set of validation script fragments, and the interaction constraint tags;

[0153] Mounting mapping module: used to pre-define the general Vue host container and its runtime environment description on the client; and generate component mounting mapping objects based on the rendering driver object, form structure object, and runtime environment description.

[0154] Page generation module: Used to generate Vue page code for the Vue runtime and the general Vue host container based on the form structure object, rendering driver object, and component mounting mapping object.

[0155] The detailed description above, in conjunction with the accompanying drawings, describes examples but does not represent all examples that can be implemented or fall within the scope of the claims. The terms “example” and “exemplary” are used in this specification to mean “serving as an example, instance or illustration” and do not mean “superior to or better than other examples”.

[0156] Throughout this specification, the phrase "an embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with that embodiment is included in at least one embodiment of the invention. Therefore, the use of these phrases may refer to more than one embodiment. Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0157] It should also be noted that these embodiments may be described as processes depicted as flowcharts, structural diagrams, or block diagrams. Although a flowchart may describe the operations as sequential processes, many of these operations can be performed in parallel or concurrently, and the order of these operations may be rearranged.

Claims

1. A method for automatically converting dynamic form pages into Vue code, characterized in that, include: At runtime, the target form configuration is loaded from the form configuration repository, and a form structure object is generated based on the field grouping information, layout fragment tags, and interaction constraint tags in the target form configuration. Extract the field rendering fragment set and the validation script fragment set from the form structure object, and generate a rendering driver object based on the field rendering fragment set, the validation script fragment set, and the interaction constraint tags; The client pre-defines a general Vue host container and its runtime environment description, and generates a component mounting mapping object based on the rendering driver object, form structure object and runtime environment description. Vue page code is generated for the Vue runtime and the general Vue host container based on the form structure object, the render driver object, and the component mount mapping object.

2. The method for automatically converting a dynamic form page into Vue code according to claim 1, characterized in that, Generate a form structure object based on the field grouping information, layout fragment tags, and interaction constraint tags in the target form configuration, including: Read field grouping information, layout fragment tags, and interaction constraint tags from the target form configuration repository; aggregate information belonging to the same field group into group records; and aggregate information referencing the same layout fragment tag into layout records. Based on the hierarchical relationship of each group record in the target form configuration, generate the corresponding group node, and attach the layout record that references the group to the group node to obtain a set of group nodes carrying layout information; In the set of grouped nodes carrying layout information, based on the triggering field and controlled field marked by the interaction constraint label, constraint association entries are established between the triggering field nodes and controlled field nodes located in different grouped nodes, generating a cross-group constraint association index; The set of group nodes carrying layout information is associated with the cross-group constraint association index according to the group identifier and field identifier to form a graph data structure containing group hierarchy, layout attachment relationship and constraint association entries, and the graph data structure is used as a form structure object.

3. The method for automatically converting a dynamic form page into Vue code according to claim 2, characterized in that, Generating form structure objects also includes: In the graph data structure corresponding to the form structure object, extract the parent group identifier and layout fragment mark of each group node, combine them according to the parent-child relationship to form group path entries, and summarize them to form a group path index table; Based on the group path index table, the group path and field identifier are combined for each field node under the group node to generate a field access path tag, and the field access path tag is written to the corresponding field node attribute; In the graph data structure after writing the field access path marker, keep the grouping hierarchy, layout attachment relationship and constraint association items unchanged, and only add the field access path marker field to obtain a form structure object containing field access path information.

4. The method for automatically converting a dynamic form page into Vue code according to claim 1, characterized in that, Extract the field rendering fragment set and validation script fragment set from the form structure object. Generate a rendering driver object based on the field rendering fragment set, validation script fragment set, and interaction constraint tags, including: Traverse the field nodes in the form structure object, and generate field rendering fragments for each field node based on the layout fragment tags associated with the field nodes and the field grouping information, and collect them to form a set of field rendering fragments; Based on the validation description of the field node in the target form configuration, the value constraint statement, prompt message script and interactive constraint label referenced by the same field node are combined to generate the corresponding validation script fragments, and collected to form a set of validation script fragments. Using the field identifier as the key, establish binding entries between the field rendering fragment set and the validation script fragment set, and combine the field rendering fragments and validation script fragments that describe the same field to generate a field fragment binding list; Based on the triggering relationships between fields in the field fragment binding list pointed to by interaction constraint tags, the binding entries involving different grouped fields are summarized into several rendering control channels. Each rendering control channel and its associated field fragment binding list are combined into a rendering driver object, and this rendering driver object is used as the rendering driver object generated based on the field rendering fragment set, the validation script fragment set, and the interaction constraint tags.

5. The method for automatically converting a dynamic form page into Vue code according to claim 4, characterized in that, Generating render driver objects also includes: In the field fragment binding list corresponding to the rendering driver object, mark each binding entry with an initialization phase identifier, interaction phase identifier, or submission phase identifier to obtain a field fragment binding list with phase identifiers; Based on the field rendering fragment content referenced by each binding entry in the field fragment binding list with stage identifiers, the directive type tag and component attribute tag that need to be applied in the Vue page are parsed out, and the directive type tag and component attribute tag are written into the corresponding binding entries; According to the stage identifier, the binding entries with instruction type tags and component attribute tags are divided into initialization control set, interaction control set and submission control set. The above control sets, together with the original rendering control channel information, are reorganized into structured records, and the original rendering driver object content is replaced with the structured records to obtain a rendering driver object containing stage control information.

6. The method for automatically converting a dynamic form page into Vue code according to claim 1, characterized in that, Generate a component mounting mapping object based on the rendering driver object, form structure object, and runtime environment description, including: Based on the terminal type, view area division method, and available component library identifier recorded in the runtime environment description, generate a set of host container mounting slot descriptions; Based on the field grouping information and layout fragment tags in the form structure object, the layout fragments containing each field are matched with the slot identifiers in the host container's mounting slot description set to generate a field layout slot mapping set. Based on the set of field rendering fragments and the set of field layout slot mappings in the rendering driver object, determine the component types, attribute binding expressions and validation triggering methods that need to be mounted in each slot, and generate a list of slot component requirements; Based on the list of slot component requirements and the set of slot descriptions for the host container, a component mounting mapping object is obtained that records the corresponding relationship between slot identifiers, component types, and attribute bindings.

7. The method for automatically converting a dynamic form page into Vue code according to claim 6, characterized in that, The process of generating a list of slot component requirements based on the set of field rendering fragments and the set of field layout slot mappings in the rendering driver object includes: Extract the display form, interactive behavior, and validation trigger timing of each field from the field rendering fragment set in the rendering driver object to construct a field rendering feature set; Based on the field layout slot mapping set, the field identifiers in the field rendering feature set are merged with the corresponding slot identifiers to obtain the slot rendering feature set; Based on the display form and interaction behavior recorded in the slot rendering feature set, select the component type corresponding to the available component library identifier of the host container, and generate the component attribute binding expression according to the verification triggering time to form a slot component requirement record set. The slot component requirement record set is summarized according to the slot identifier to obtain a slot component requirement list that records the slot component type and attribute binding expression of each slot component.

8. The method for automatically converting a dynamic form page into Vue code according to claim 1, characterized in that, Generate Vue page code for the Vue runtime and the general Vue host container based on the form structure object, render driver object, and component mount mapping object, including: Based on the field grouping information and layout fragment tags in the form structure object, and combined with the slot identifier and component type correspondence in the component mounting mapping object, a component tree description object is constructed to record the parent-child relationship and slot hierarchy relationship; Based on the set of field rendering fragments in the rendering driver object, each component node in the component tree description object is combined with its corresponding field rendering fragment to form a set of template fragment combinations that record node template placeholder structure and instruction binding expression. Based on the instruction binding expressions recorded in the template fragment combination set and the property binding expressions in the component mounting mapping object, a script description object containing data source declarations, event handling functions, and component registration information is generated. Based on the component tree description object, the template fragment combination set, and the script description object, Vue page code containing template structure fragments and script fragments is generated.

9. The method for automatically converting a dynamic form page into Vue code according to claim 8, characterized in that, The process of generating a script description object based on the instruction binding expressions recorded in the template fragment combination set and the property binding expressions in the component mounting mapping object includes: Extract the instruction binding expressions corresponding to the field rendering fragments from the template fragment combination set, and generate the field instruction binding set; Based on the property binding expression in the component mounting mapping object, the field identifiers in the field instruction binding set are mapped to the component property identifiers to obtain the data binding relationship set; Based on the field identifiers involved in the data binding relationship set, and combined with the field grouping information in the target form configuration, a data source declaration record set with record field default values, validation trigger methods, and group codes is generated; Based on the data source declaration record set and the data binding relationship set, a script description object is generated that includes a data source declaration segment, an event handling function placeholder segment, and a component registration segment.

10. A system for automatically converting dynamic form pages into Vue code, used to implement the method for automatically converting dynamic form pages into Vue code as described in any one of claims 1-9, characterized in that, include: Structure building block: Used to load target form configurations from the form configuration repository at runtime; Generate a form structure object based on the field grouping information, layout fragment tags, and interaction constraint tags in the target form configuration; Rendering driver module: Used to extract the set of field rendering fragments and the set of validation script fragments from the form structure object, and generate a rendering driver object based on the set of field rendering fragments, the set of validation script fragments, and the interaction constraint tags; Mount mapping module: Used to pre-define the general Vue host container and its runtime environment description on the client side; Generate a component mounting mapping object based on the rendering driver object, form structure object, and runtime environment description; Page generation module: Used to generate Vue page code for the Vue runtime and the general Vue host container based on the form structure object, rendering driver object, and component mounting mapping object.