A configuration-driven table form data model generation method supporting dynamic array item identification maintenance

Abstract

The application discloses a configuration-driven form data model generation method supporting dynamic array item identification maintenance, and comprises the following steps: obtaining a form configuration item set and generating a running form data model; generating or reserving a running internal row identifier independent of an array subscript and a component reference for each array item of a dynamic array field; when form configuration changes, generating a candidate model based on new configuration, comparing field by field, only supplementing a default value to a missing field in a current model, and reserving user input data; when external business data is backfilled, dynamically detecting and automatically supplementing an internal row identifier for a missing array item; and when data is submitted or exported, accurately traversing and stripping the internal row identifier according to a dynamic array field path marked in the configuration, and outputting pure business data. The application realizes stable identity positioning of dynamic array items, and avoids data loss caused by configuration changes.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a configuration-driven form data model generation method that supports dynamic array item identifier maintenance. Background Technology

[0002] Satellite communication service systems typically require the configuration and management of information such as terminal equipment, ground station resources, link parameters, frequency band resources, beam resources, access policies, task plans, and operational status reporting policies. These configuration items are numerous, and the fields required vary depending on the device model, service type, network environment, access roles, or system version. For example, in scenarios such as terminal network access, link establishment, task assignment, and operation and maintenance policy configuration, form fields may need to be dynamically displayed, hidden, added, or removed based on the service template.

[0003] In existing satellite communication network management platforms or service configuration platforms, form data models typically use fixed field definitions, or the front-end page simply generates initial objects based on configuration items. For ordinary fields, this method can meet basic data entry requirements; however, in scenarios with dynamically repeating subforms, nested fields, hot configuration updates, historical data backfilling, and multi-terminal display, the form configuration and form data model are prone to becoming out of sync.

[0004] For example, when configuring multiple ground stations, multiple terminals, multiple link policies, or multiple departments and job categories with repetitive data, forms often need to dynamically add or delete multiple rows of configuration items. If the system only maintains dynamic row data based on array indices, when users add, delete, sort, or backfill historical data, it may lead to unstable dynamic row identities, resulting in problems such as rendering misalignment, row-level status mismatch, validation status mismatch, or incorrect association of user input content.

[0005] Meanwhile, to ensure stable front-end rendering, the system typically needs to add an internal identifier to dynamic rows. However, this internal identifier belongs to the runtime control field, not the satellite communication service field. If the system cannot distinguish between runtime fields and service fields, it may submit the internal control field to the backend along with the data when submitting or exporting, resulting in non-standard interface data or contaminated service data.

[0006] Furthermore, when form configurations change—for example, by adding fields, adjusting field structures, switching to different service configuration templates, or loading new device model configurations—existing methods often require regenerating the entire form data model. This process may overwrite data already entered or backfilled by the user, leading to configuration interruptions or data loss. For satellite communication service systems, some configuration items involve link policies, terminal parameters, frequency band resources, or mission plans, which incur high input costs for users. If configuration updates cause already entered data to be overwritten, it will affect configuration efficiency and data reliability.

[0007] In scenarios involving historical configuration editing or detail backfilling, external business data needs to be rewritten into the form model. If the backfilling process is not handled according to the form configuration structure, issues such as missing runtime internal identifiers for dynamic array items, incomplete nested structures, and uninitialized dependent fields may occur. Furthermore, during data export or submission, if dynamic array fields cannot be identified and their internal identifiers accurately extracted based on the configuration, business fields may be mistakenly deleted or runtime fields may be omitted. Summary of the Invention

[0008] The purpose of this invention is to provide a configuration-driven form data model generation method that supports dynamic array item identifier maintenance. This method ensures model consistency during form data initialization, configuration changes, data backfilling, and data export while supporting dynamic form configuration, thereby reducing the risks of data misalignment, user input overwriting, and internal field pollution in dynamically repeating subforms.

[0009] A technical solution, a configuration-driven form data model generation method supporting dynamic array item identifier maintenance, includes the following steps:

[0010] Obtain a set of form configuration items, perform field type classification processing on the set of form configuration items, and generate a runtime form data model containing ordinary fields, nested fields, and dynamic array fields;

[0011] For each array item in the dynamic array field, generate or retain the runtime internal row identifier, store the internal row identifier separately from the business data field, and generate dynamic array item data with internal row identifier;

[0012] When a change in form configuration is detected, a candidate data model is generated based on the new configuration. The candidate data model is compared with the current running form data model, and missing fields are filled in non-overwrite to generate an incrementally synchronized running form data model.

[0013] Upon receiving external backfill business data, the external backfill business data is written into the runtime form data model copy according to the structure of the form configuration item set, and internal row identifiers are filled in for array items that are missing internal row identifiers, thereby generating a fully backfilled runtime form data model.

[0014] Upon receiving a data export instruction, the current running form data model is copied as a copy of the data to be output. Based on the dynamic array field path marked in the form configuration item set, the corresponding internal row identifiers in the copy of the data to be output are traversed and stripped to generate pure business submission data that does not contain running internal identifiers.

[0015] The benefits are as follows: First, it can automatically generate a runtime data model based on the field structure of satellite communication service configuration forms, reducing the need for repetitive model initialization logic across different service configuration pages. Second, it can maintain row-level internal identifiers for dynamic array fields, reducing the risk of row data misalignment during the addition, deletion, sorting, backfilling, and rendering of dynamically repeated subforms. Third, it can update the data model using a non-overwrite incremental completion method when form configurations change, avoiding the loss of user-inputted data due to a full model reconstruction. Fourth, it can automatically complete the internal row identifiers required for runtime when backfilling external service data, ensuring the integrity of the model structure after backfilling historical configurations, device templates, or backend data. Fifth, it can accurately remove internal row identifiers based on the configuration path during submission or export, preventing runtime control fields from contaminating satellite communication service data. Attached Figure Description

[0016] Figure 1 This is a flowchart of the overall solution of the present invention. Detailed Implementation

[0017] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0018] like Figure 1 As shown, this embodiment describes in detail the data processing flow of a configuration-driven form data model generation method that supports dynamic array item identifier maintenance, specifically including:

[0019] S1: Obtain the form configuration item set, perform field type classification processing on the form configuration item set, and generate a runtime form data model containing ordinary fields, nested fields, and dynamic array fields.

[0020] According to one aspect of this application, when initiating the generation process of a dynamic form data model, it is first necessary to obtain a set of form configuration items for the target scenario. In this embodiment, the set of form configuration items is typically provided in JSON (JavaScript Object Notation) format or in the form of database configuration records, and it contains at least core elements such as field identifier (fieldKey), field type (fieldType), default value (defaultValue), and dynamic subfield definitions (subFields).

[0021] Furthermore, in the processing flow, the above set of form configuration items needs to be categorized by field type. Specifically, based on the preset field type mapping rules, the configuration items are divided into three basic forms: "ordinary fields," "nested fields," and "dynamic array fields." Ordinary fields correspond to single satellite communication service parameters, such as terminal name or site number; nested fields correspond to structured parameters with parent-child hierarchical relationships, such as frequency band configurations nested in link policies; and dynamic array fields correspond to multiple service configuration items that can be dynamically added or deleted, such as multiple ground station parameter lists.

[0022] After determining the field types, the initial runtime form data model is constructed. During this process, differentiated initialization strategies are adopted for different field types. For ordinary fields, their field identifiers are directly used as the top-level key in the runtime form data model. If a "default value" is set in the configuration, the default value is filled into the corresponding position of the key; if no "default value" is set, a preset null value (such as an empty string, the number 0, or the boolean value False) is written according to the specific type of the field (e.g., string, number, boolean). For nested fields, the parent field identifier is used as the key of the upper-level object, and its child field configurations are traversed, with the child field identifiers used as internal keys, each filled with a corresponding default value or a preset null value, thus constructing a structurally complete nested object.

[0023] For dynamic array fields, during initialization, if an initial array value is set in the configuration options, that initial array value is directly copied as the base data for the field; otherwise, an empty array or an array containing default single-row data is generated. In this application, the initialized runtime data model is a basic data container for front-end interaction and rendering. It is independent of the back-end business data storage structure and provides a reliable data skeleton for subsequent form interactions.

[0024] S2: For each array item in the dynamic array field, generate or retain the running internal row identifier, store the internal row identifier in isolation from the business data field, and generate dynamic array item data with internal row identifier.

[0025] After completing the construction of the basic runtime form data model, the next stage is the fine-grained management of dynamic array fields. For each array item in the dynamic array fields, a runtime internal row identifier, independent of the business field, needs to be generated or retained. This internal row identifier is a control field used only for front-end rendering and row-level state maintenance, and its specific form can be a universally unique identifier (UUID), a timestamp combination value, a hash value, or other data forms that can meet the requirements of unique positioning.

[0026] Specifically, when processing each row of data in a dynamic array field, the system first checks the availability of internal row identifiers. If an internal row identifier already exists in the array item data, it is retained to ensure the continuity of row-level state during front-end / back-end interactions or backfilling operations. If an internal row identifier does not exist in the array item data, a new globally unique internal row identifier is generated in real time and written to that row. It is important to clarify that the mechanism of this internal row identifier is completely different from traditional array indices, display orders, component references, or validation IDs.

[0027] For example, when users perform operations such as adding, deleting, sorting, or refilling dynamic array items on the front-end interface, relying solely on array indices can easily lead to rendering misalignment, state resets, or incorrect association of user input data due to data item position changes. In this solution, by introducing the internal row identifier, each row of data has a stable and unchanging "identity ID." Regardless of how the physical position of the array item changes in the list, the system can accurately locate a specific array item based on this internal row identifier, thereby ensuring the stability of front-end component rendering and accurate matching of row-level states (such as input box content, dropdown menu selected values, and validation error states).

[0028] In a preferred embodiment, the internal row identifier is strictly confined to the scope of the runtime form data model, achieving physical isolation from business data fields at the data structure level. This means that in the runtime data model, the internal row identifier and business fields are distributed in different attribute slots or levels, facilitating identification and differentiation by the data model management module. This isolated storage mechanism avoids the risk of runtime control data and business data being mixed up from the source, laying a structural foundation for the subsequent export and purification process.

[0029] S3: When a change in form configuration is detected, a candidate data model is generated based on the new configuration. The candidate data model is compared with the current running form data model, and missing fields are filled in non-overwrite to generate an incrementally synchronized running form data model.

[0030] During form interaction, business configuration changes are frequently encountered, such as switching device model configuration templates, adjusting network environment configurations, changing the configuration scope corresponding to permission roles, or introducing new business requirements that lead to an expansion of the form structure. According to a further improvement in this embodiment, when such form configuration change instructions are detected, the processing flow does not adopt the aggressive strategy of directly rebuilding the entire data model as in traditional methods. Instead, it initiates a non-overwrite incremental synchronization mechanism.

[0031] First, the processing flow regenerates a corresponding candidate data model based on the latest set of form configuration items. This candidate data model contains the field structure and default values ​​under the new configuration. Next, a field-by-field deep comparison is performed between the candidate data model and the currently existing running form data model. This comparison operation is not limited to top-level fields but also delves into the internal substructures of nested fields and dynamic array fields.

[0032] During the comparison process, there are two branching logics. If it is determined that a certain field already exists in the current running form data model, then the current value of that field is directly retained (this value may be source data filled in externally or business data manually entered by the user), and the default value in the candidate data model is never used to overwrite it. If it is determined that a certain field does not exist in the current running form data model, it indicates that the field is a newly added configuration item in the new configuration. In this case, the corresponding field in the candidate data model and its default value or preset empty value are added to the current running form data model as an increment.

[0033] Furthermore, the synchronization strategy for dynamic array fields is particularly crucial. When the configuration changes, for existing dynamic array fields, the processing flow will completely preserve all existing array items and their corresponding internal row identifiers, and synchronously retain the existing subfield values ​​within each array item. For newly added subfields within the dynamic array item, only the newly added default values ​​or preset null values ​​are inserted into the corresponding positions. For newly appearing dynamic array fields in the configuration, a completely new array structure is generated according to the dynamic array field generation rules, and internal row identifiers are uniformly filled in. Through this non-overwrite incremental synchronization mechanism, not only is zero loss of user historical input data guaranteed, but a smooth transition of data structure to the new configuration is also achieved, improving the continuity and reliability of the business configuration process.

[0034] S4: Upon receiving external backfill business data, write the external backfill business data into the runtime form data model copy according to the structure of the form configuration item set, and fill in the internal row identifiers for array items that are missing internal row identifiers, thereby generating a fully backfilled runtime form data model.

[0035] In application scenarios such as historical configuration editing, task details viewing, or device template loading, it is necessary to rewrite external business data (such as historical configuration records, backend API interface returned data, device configuration template data, or local cached data) into the current form data model, i.e., perform data backfilling. In this application, the aforementioned external business data is regarded as a pure "business data domain," whose data structure typically only contains business parameters (such as terminal name, link strategy parameters) and does not contain runtime control fields (such as internal row identifiers).

[0036] In one optional implementation, the backfill process first writes the values ​​of each field in the external business data to the corresponding positions in the runtime form data model copy, according to the field order in the current form configuration item set. For ordinary fields, key-value pair mapping is performed directly; for nested fields, the data is written to the corresponding nested object properties according to the structural hierarchy of parent and child fields.

[0037] For dynamic array fields, the backfilling process includes a crucial supplementary processing step. When writing array rows from external business data to the runtime form data model copy, it's necessary to traverse each row of data under that dynamic array field. Since external business data typically doesn't contain internal row identifiers, the backfilling process needs to determine whether the row already has an internal row identifier in the runtime model copy. If it's confirmed that the row lacks an internal row identifier, a new one is generated in real-time and written into the row; if it's confirmed that the row already has an internal row identifier, that identifier is used directly to maintain the continuity of row-level state after cache recovery.

[0038] This automatic completion of internal row identifiers during the backfilling phase ensures that even if the original external data originates entirely from a pure business system, the backfilled runtime form data model still possesses the ability to support dynamic front-end rendering and stable row-level state maintenance. For example, when backfilling historical satellite communication link policy configurations, users can continue to add, delete, or sort dynamic array lists in the backfilled form without data corruption due to missing internal identifiers.

[0039] S5: Upon receiving a data export instruction, copy the current running form data model as a copy of the data to be output. Based on the dynamic array field path marked in the form configuration item set, traverse and strip the corresponding internal row identifier in the copy of the data to be output to generate pure business submission data that does not contain running internal identifiers.

[0040] At the end of the form interaction process, when it is necessary to submit the user-configured data to the satellite communication service backend system, or when it is necessary to export the configuration data into a standardized configuration file, a rigorous runtime data purification process must be performed. The core objective of this purification is to accurately remove the internal row identifiers that exist only in the runtime model, ultimately outputting clean business data.

[0041] According to one aspect of this application, when a data export or submission instruction is received, the processing flow first performs a deep copy operation on the currently running form data model to generate an independent copy of the data to be output. This deep copy mechanism ensures that the interactive state (such as the user's current input focus, error prompts, etc.) and internal row identifiers in the original running model are not affected by the export operation, nor does it have a negative impact on subsequent form interactions.

[0042] Subsequently, the processing flow performs a targeted traversal of the copy of the data to be output based on the pre-marked dynamic array field paths in the form configuration item set. Specifically, it locates the position of the dynamic array field and traverses each row of data under that dynamic array field; for each row of data traversed, the internal row identifier attribute field is directly removed from the data structure of that row, retaining only the remaining pure business data fields. It is important to note that for non-dynamic array fields, even if they contain business fields with the same name as the internal row identifier, the stripping operation is absolutely not performed. This strategy of precise stripping based on the "configuration path" effectively avoids the risk of erroneously deleting business fields that might be caused by global string replacement.

[0043] After copying, path positioning, row traversal, and precise stripping, the final output is a pure business submission data set containing all business fields but completely free of any runtime control fields. This pure business submission data can be directly used for standardized interface submissions or file export. Thus, from initial runtime generation, incremental synchronization during intermediate processes, external data backfilling, to final identifier cleanup upon submission, a complete closed-loop data processing flow is formed, ensuring both the stability of front-end interactions and the standardization and purity of back-end business data reception.

[0044] In one embodiment, the present invention is applied to a satellite communication service configuration platform. This platform can be a satellite communication network management platform, a terminal management platform, a link policy configuration platform, or a task scheduling configuration platform. The form configuration items in the platform are used to describe the service parameter input interface, such as terminal name, site number, link policy, frequency band parameters, beam selection, and reporting policy.

[0045] The form configuration item set includes multiple field configuration items. Each field configuration item includes at least a field identifier, field type, default value, and subfield definition. Field types can include ordinary fields, nested fields, and dynamic array fields. Ordinary fields are used to represent single business parameters; nested fields are used to represent business parameters with a parent-child structure; and dynamic array fields are used to represent repeatable business configuration items, such as multiple link policies, multiple terminal configuration items, multiple ground station parameter items, or multiple reporting policy items.

[0046] After receiving the set of form configuration items, the system first iterates through each field configuration item. When a field configuration item is a regular field, the system reads the field identifier from that field configuration item and uses that field identifier as the key in the runtime form data model. If the field configuration item has a default value, the default value is written to the runtime form data model; otherwise, a preset null value is written. The preset null value can be set to an empty string, an empty array, an empty object, a boolean value, or a number, depending on the field type.

[0047] When a field configuration item contains subfield definitions and is not a dynamic array field, the system generates a nested object model. Specifically, the system uses the parent field identifier as the upper-level key and iterates through its subfield configuration items, using each subfield identifier as the key in the nested object, and writes the corresponding default value or preset null value. In this way, satellite communication service parameters with hierarchical relationships can be organized into structured objects.

[0048] When the field configuration item is a dynamic array field, the system generates an array-type data model. If an initial array value is set in the field configuration item, the system copies that initial array value; otherwise, an empty array or an array containing default rows is generated. For each row of data in the dynamic array, the system determines whether the row already has an internal row identifier. If an internal row identifier already exists, it is retained; otherwise, a new internal row identifier is generated and written to the row in the runtime data model. The internal row identifier can be a string, number, hash value, random value, timestamp combination value, or other data format that can uniquely identify a row in the dynamic array.

[0049] The internal row identifier is used only for runtime data location, front-end rendering stability maintenance, row-level status maintenance, and dynamic row tracking, and is not submitted to the back-end system as a satellite communication service field. The internal row identifier differs from array subscripts, display sequence numbers, component instance references, or validation references. When a user performs add, delete, sort, or backfill operations on dynamic array items, the system uses the internal row identifier to maintain the stable identity of the dynamic array items, avoiding data misalignment caused by relying solely on array subscripts.

[0050] For example, in a link policy configuration scenario, a dynamic array field can represent multiple link policies. Each link policy row includes fields such as beam number, frequency band, priority, bandwidth, and uplink rate. The system generates an internal row identifier for each link policy row. When users add, delete, or adjust the order of link policies, the system can still reliably identify the data in each row, avoiding form rendering misalignment, validation status mismatch, or row-level operation object errors caused by changes in array subscripts.

[0051] In one alternative implementation, after the runtime form data model is generated for the first time, the system saves an initial value snapshot. This initial value snapshot is used for subsequent form resets. When a user performs a reset operation, the system restores the runtime form data model based on the initial value snapshot, rather than directly overwriting it from the current configuration items, thereby ensuring the deterministic nature of the reset behavior.

[0052] In another implementation, when the set of form configuration items changes, the system performs incremental synchronization. Configuration changes may include adding fields, switching configuration templates, adjusting service types, loading new satellite communication equipment model configurations, or changing the configuration scope corresponding to permission roles. The system generates a candidate data model based on the new set of form configuration items and compares the candidate data model with the currently running form data model.

[0053] If a field already exists in the current running form data model, the system retains the current field value and does not overwrite it with the default value from the candidate data model. If a field does not exist in the current running form data model, the system adds the field and its default value from the candidate data model to the current running form data model. For existing dynamic array fields, the system retains the current array item, the user input value in the array item, and the internal row identifiers of the array item, and only adds default values ​​or preset empty values ​​to newly added subfields that are missing in the current array item. For newly added dynamic array fields, the system generates the array structure according to the generation rules of dynamic array fields and fills in the internal row identifiers.

[0054] Through the incremental synchronization process described above, even if the form configuration is adjusted due to changes in device model, link type, task type, or permission policy during satellite communication service configuration, the system will not overwrite the service parameters already entered by the user, thereby reducing the risk of configuration data loss. For fields that no longer exist in the new configuration, the system can decide whether to continue to retain them in the runtime cache based on the service policy; when submitting or exporting, the system prioritizes determining the range of output fields based on the current form configuration.

[0055] In another implementation, the system supports backfilling external business data. This external business data can originate from historical configurations, backend interfaces, device configuration templates, task configuration records, or local cache. When backfilling external business data, the system writes the corresponding field values ​​sequentially according to the field order in the form configuration item set. For ordinary fields, the system writes the corresponding business value; for nested fields, the system writes the nested object according to the parent-child field structure; for dynamic array fields, the system iterates through the array rows in the external business data and fills in the missing internal row identifiers for array rows lacking internal row identifiers in the runtime form data model copy.

[0056] If external business data originates from backend interfaces, business systems, or historical configuration records, this data is considered pure business data. The system does not require it to contain internal row identifiers, nor does it consider missing internal row identifiers as business data errors. If external business data originates from runtime cache and already contains internal row identifiers, the system can retain these internal row identifiers to maintain the continuity of row-level state after cache recovery.

[0057] In another implementation, the system supports form data export and submission. During export, the system first copies the currently running form data model to obtain a copy of the data to be output. Then, the system iterates through the set of form configuration items, identifying the dynamic array field paths. For each dynamic array field path, the system locates the corresponding array in the copy of the data to be output, iterates through each row of data in the array, and removes the internal row identifier from each row. For non-dynamic array fields, the system does not perform the internal row identifier stripping operation; even if a non-dynamic array field contains a business field with the same name as an internal row identifier, it will not be mistakenly deleted. After processing, the system outputs pure business data for submission to the satellite communication service backend system or for data export.

[0058] In one optional implementation, the method of the present invention can be jointly executed by a form data model management module, a dynamic array item identifier maintenance module, a configuration incremental synchronization module, a data backfilling module, and a data export purification module. The form data model management module is used to generate an initial running-state data model and an initial value snapshot based on the configuration items; the dynamic array item identifier maintenance module is used to generate, retain, and complete internal row identifiers for dynamic array items; the configuration incremental synchronization module is used to perform non-overwrite field completion when the configuration changes; the data backfilling module is used to write external business data according to the configuration order and complete the internal row identifiers of the dynamic array items; and the data export purification module is used to identify dynamic array fields based on the configuration path and remove internal row identifiers.

[0059] This invention does not limit the specific front-end framework, component library, field name, or data transmission format. The form configuration item set can be provided in the form of JSON, database configuration, interface returned data, or local configuration file, etc. The internal row identifier can be any data format that can satisfy the unique positioning of the dynamic array row. As long as it can generate a runtime form data model based on the field identifier, field type, default value, and dynamic sub-item structure, and complete the maintenance of dynamic array item identifiers, incremental configuration synchronization, data backfilling, and export purification according to the method of this invention, it falls within the scope of this invention.

[0060] The preferred embodiments of the present invention have been described in detail above. However, the present invention is not limited to the specific details in the above embodiments. Within the scope of the technical concept of the present invention, various equivalent transformations can be made to the technical solutions of the present invention, and these equivalent transformations all fall within the protection scope of the present invention.

Claims

1. A configuration-driven form data model generation method supporting dynamic array item identifier maintenance, characterized in that, include: Obtain a set of form configuration items, perform field type classification processing on the set of form configuration items, and generate a runtime form data model containing ordinary fields, nested fields, and dynamic array fields; For each array item in the dynamic array field, generate or retain the runtime internal row identifier, store the internal row identifier separately from the business data field, and generate dynamic array item data with internal row identifier; When a change in form configuration is detected, a candidate data model is generated based on the new configuration. The candidate data model is compared with the current running form data model, and missing fields are filled in non-overwrite to generate an incrementally synchronized running form data model. Upon receiving external backfill business data, the external backfill business data is written into the runtime form data model copy according to the structure of the form configuration item set, and internal row identifiers are filled in for array items that are missing internal row identifiers, thereby generating a fully backfilled runtime form data model. Upon receiving a data export instruction, the current running form data model is copied as a copy of the data to be output. Based on the dynamic array field path marked in the form configuration item set, the corresponding internal row identifiers in the copy of the data to be output are traversed and stripped to generate pure business submission data that does not contain running internal identifiers.

2. The method according to claim 1, characterized in that, The steps for generating or retaining runtime internal line identifiers include: For any array item in the dynamic array field, determine whether an internal row identifier already exists in that array item; If it exists, then retain the internal row identifier directly; If it does not exist, a unique internal row identifier is generated, which is independent of the array item's array index, display sequence number, component instance reference, and validation reference identifier, and written into the array item's data; The internal row identifier is used for the identification and row-level status maintenance of dynamic array items during subsequent addition, deletion, sorting, or backfilling operations.

3. The method according to claim 1, characterized in that, The steps for non-overwrite imputation of missing fields include: The candidate data model is compared field by field with the current running form data model; If a field already exists in the current running form data model, then the current value of that field is directly retained, and the corresponding default value in the candidate data model is not used to overwrite it; If a certain field does not exist in the current running form data model, then the default value or preset empty value of that field is extracted from the candidate data model and added to the current running form data model; When performing non-overwrite padding on dynamic array fields, the current array item and its corresponding internal row identifier are retained, and only the missing new sub-fields in the current array item are padded with default values ​​or preset null values.

4. The method according to claim 1, characterized in that, The steps to generate a fully populated running form data model include: Based on the field order in the form configuration item set, the external backfill business data is sequentially written into the corresponding fields of the running form data model copy; Identify the dynamic array field in the external backfill business data, and traverse each row of backfill data under the dynamic array field; If the backfilled data for a row lacks an internal row identifier in the copy of the running form data model, a new internal row identifier will be generated and supplemented for that row to maintain the identity stability and rendering continuity of the dynamic array items after backfilling.

5. The method according to claim 1, characterized in that, The steps of traversing and stripping the corresponding internal row identifiers from the copy of the data to be output include: Based on the pre-marked dynamic array field paths in the form configuration item set, locate the dynamic array field data in the copy of the data to be output; Iterate through each row of data under the dynamic array field, remove the internal row identifier from the data structure of each row of data, and retain the pure business data field; For non-dynamic array fields, even if there is a field with the same name as the internal row identifier, the stripping operation will not be performed to ensure the integrity of the business fields.

6. The method according to claim 1, characterized in that, After generating the runtime form data model, the method also includes: Save an initial value snapshot; upon receiving a form reset instruction, restore the running form data model based on the initial value snapshot, instead of regenerating it from the current configuration items.

7. The method according to claim 1, characterized in that, The set of form configuration items includes at least: field identifier, field type, default value, and dynamic sub-item definition; the external backfill business data comes from historical configuration records, backend interfaces, device configuration templates, or task configuration records.

8. The method according to claim 3, characterized in that, Before comparing the candidate data model with the currently running form data model field by field, the process also includes: The candidate data model is generated based on the new set of form configuration items, and the old fields in the candidate data model that are missing from the current running state model are marked using prior mapping rules; During the comparison process, for fields that no longer exist in the new configuration, a decision is made on whether to continue to retain them in the runtime cache based on the preset retention policy, and the range of output fields is determined first based on the current form configuration when submitting or exporting.

9. The method according to claim 1, characterized in that, After generating pure business submission data that does not contain runtime internal identifiers, the method also includes: Monitor the structural integrity of data submitted for pure business purposes. When the structural integrity is found to be lower than the preset risk threshold, generate a configuration template verification report. The configuration template validation report is provided to adjust the dynamic array field definitions or default value settings in the form configuration item set.

10. The method according to claim 5, characterized in that, After stripping the corresponding internal row identifier from the copy of data to be output, the steps for determining the validity of pure business submission data include: Based on the pure business data after removing internal row identifiers, construct snapshot data of the current business configuration; By combining the synchronization mapping relationship between the runtime data model and the business submission data, the consistency verification of the pure business submission data is performed to generate the final pure business data for submission to the backend system or for export.

Images