Form core engine system based on model driving and life cycle management

Abstract

The invention relates to the technical field of front-end development, and discloses a form core engine system based on model driving and life cycle management, which comprises the following steps of: firstly, analyzing a form structure and a rule through a model configuration analysis module to establish field mapping and a life cycle registry; and a dependency graph and a consumer registry are generated by using a dependency building module. On the basis, the service logic dynamic mounting module injects specific logic into the field model according to the service identifier to realize decoupling; and when user interaction triggers change, the state change propagation module cooperates with the cascade update module to automatically trigger cascade calculation and update of consumer fields based on the dependency graph, and finally a form state snapshot is output. In this way, thorough separation of core business logic and UI display is effectively achieved, and automatic management and state consistency of data flow in a complex form scene are guaranteed.

Description

Technical Field

[0001] This application relates to the field of front-end development technology, and more specifically, to a form core engine system based on model-driven and lifecycle management. Background Technology

[0002] In modern enterprise-level web application development, form systems have become the core carrier of data interaction in complex business scenarios such as ERP and CRM. Existing form development solutions are usually deeply bound to front-end UI frameworks such as React and Vue, mainly relying on the internal state of components or dedicated libraries within the framework ecosystem for data management and validation.

[0003] However, this architecture, tightly coupled with the UI presentation layer, reveals numerous drawbacks when facing highly dynamic business requirements. First, the core business model, validation rules, and UI rendering logic are intertwined, making code difficult to reuse across platforms and incurring significant refactoring costs during UI framework upgrades or migrations, thus failing to achieve true model-driven development. Second, when handling complex field relationships, existing technologies lack automated dependency building and cascading update mechanisms. Developers are forced to write extensive imperative listener and callback code to maintain state synchronization between fields. This non-declarative approach not only leads to logical redundancy but is also highly susceptible to data flow disruptions or state inconsistencies due to human error. Furthermore, due to the lack of a unified and refined lifecycle management bus, the logic for form initialization, mounting, and state changes is scattered across the lifecycle hooks of various UI components, making it difficult to dynamically inject business logic (Side Effects) in a decoupled manner at specific stages.

[0004] Therefore, the industry urgently needs a form core engine system that is independent of the UI framework. By establishing a standardized field model and dependency graph, and introducing a unified lifecycle management mechanism, it can achieve complete decoupling of business logic and UI and automated control of complex states. Summary of the Invention

[0005] This application proposes a form core engine system based on model-driven and lifecycle management to address the problems of high logical coupling, chaotic dependency management, and insufficient lifecycle control in existing technologies when dealing with complex enterprise-level form scenarios. By combining model-driven and lifecycle management, an automated and standardized data processing bus is constructed, thereby reducing development costs, improving system stability, and providing underlying technical support for building highly dynamic and configurable enterprise-level applications.

[0006] According to one aspect of this application, a form core engine system based on model-driven and lifecycle management is provided, comprising: a model configuration parsing module, used to initialize and parse the form model based on the form structure definition, initial value data, initial state configuration, validation rule configuration, and side effect function definition to obtain the mapping relationship between field paths and field models and the lifecycle event registry; a dependency relationship building module, used to build field dependencies based on the mapping relationship between field paths and field models, formula expressions, and explicitly declared dependency relationship arrays to obtain a dependency graph and a consumer registry; a business logic dynamic mounting module, used to decouple and dynamically mount the obtained current business type identifier ID based on the mapping relationship between field paths and field models and the business logic registry to obtain an enhanced field model set after injecting business logic and an initialized form model instance; a state change propagation module, used to propagate state changes based on user interaction events and field model instances that trigger changes to obtain an updated field model and a state change event queue; and a cascading update module, used to automatically calculate and cascade update dependent fields on the state change event queue, dependency graph, and consumer registry to obtain a set of all automatically updated consumer field models and a snapshot of the final form state.

[0007] In one possible implementation, the model configuration parsing module includes: a structure definition parsing unit, used to parse the form structure definition and instantiate the model to obtain the mapping relationship between field paths and field models; and a lifecycle event construction unit, used to perform value injection, state injection, validation rule association, and side effect registration on initial value data, initial state configuration, validation rule configuration, and side effect function definition based on the mapping relationship between field paths and field models to obtain a lifecycle event registry.

[0008] In one possible implementation, the structure definition parsing unit is further configured to: perform form parsing and field configuration extraction on the form structure definition to obtain an array of all field configuration objects; and perform field model instantiation and basic attribute mapping on the array of all field configuration objects to obtain the mapping relationship between the field path and the field model.

[0009] In one possible implementation, the dependency construction module includes: a consumer information generation unit, used to perform consumer field identification and dependency parsing on the mapping relationship from field path to field model based on formula expressions and explicitly declared dependency arrays to obtain a consumer information list and a set of all field paths; and a dependency graph construction unit, used to construct a dependency graph and register consumers based on the consumer information list and the set of all field paths to obtain a dependency graph and a consumer registry.

[0010] In one possible implementation, the business logic dynamic mounting module includes: a business logic retrieval unit, used to perform hierarchical and context-related retrieval of applicable logic modules based on the mapping relationship from field paths to field models and the business logic registry to obtain a sorted list of applicable modules; a logic fusion injection unit, used to perform conflict-aware logic injection and fusion on the sorted list of applicable modules based on the mapping relationship from field paths to field models to obtain an enhanced field model set after injecting business logic; and a side effect mounting unit, used to update the enhanced field model set after injecting business logic to the form model instance, and to perform global lifecycle registration and initialization event triggering for the side effect functions in the enhanced field model set after injecting business logic to obtain an initialized form model instance.

[0011] In one possible implementation, the business logic retrieval unit includes: a module retrieval aggregation subunit, used to perform initial module retrieval and hierarchical logic aggregation on the current business type identifier ID based on the business logic registry to obtain an unfiltered set of business logic modules; a context filtering subunit, used to perform context condition filtering and applicable module filtering on the unfiltered set of business logic modules based on a set of context information to obtain a list of modules that meet the context conditions; and a priority sorting subunit, used to sort the list of modules that meet the context conditions by priority to obtain a sorted list of applicable modules.

[0012] In one possible implementation, the context information set includes the current business type identifier ID, the mapping relationship between field paths and field models, all data of the current form, and runtime context information.

[0013] Compared to existing technologies, the model-driven and lifecycle management-based form core engine system provided in this application achieves complete decoupling between core business logic and the front-end UI framework through model configuration parsing and dynamic mounting of business logic. This allows the same set of form logic to be seamlessly reused in web, mobile, and even headless server environments, and can flexibly assemble validation and interaction logic according to different business scenarios. Furthermore, by introducing a dependency graph and cascading update mechanism, the system can automatically handle complex field-linked calculations, eliminating code redundancy and logical vulnerabilities caused by manually maintaining dependency chains in traditional development, ensuring the accuracy and real-time performance of data updates in multi-level dependency scenarios. In addition, the standardized state change propagation mechanism transforms unpredictable side effects into an ordered event queue, making the form state change process traceable and debuggable. Attached Figure Description

[0014] The above and other objects, features, and advantages of this application will become more apparent from the more detailed description of the embodiments of this application in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this application and form part of the specification. They are used together with the embodiments of this application to explain this application and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0015] Figure 1 This is a schematic block diagram of a form core engine system based on model-driven and lifecycle management according to an embodiment of this application.

[0016] Figure 2 This is a schematic diagram of the data flow of a form core engine system based on model-driven and lifecycle management according to an embodiment of this application.

[0017] Figure 3 This is a schematic flowchart of the model configuration parsing module in a form core engine system based on model-driven and lifecycle management according to an embodiment of this application.

[0018] Figure 4 This is a schematic flowchart of the dependency building module in a form core engine system based on model-driven and lifecycle management according to an embodiment of this application.

[0019] Figure 5 This is a schematic flowchart of the business logic dynamic mounting module in the form core engine system based on model-driven and lifecycle management according to an embodiment of this application. Detailed Implementation

[0020] Hereinafter, exemplary embodiments according to this application will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this application, and not all embodiments of this application. It should be understood that this application is not limited to the exemplary embodiments described herein.

[0021] Figure 1 This is a schematic block diagram of a form core engine system based on model-driven and lifecycle management according to an embodiment of this application. Figure 2 This is a schematic diagram illustrating the data flow of a form core engine system based on model-driven and lifecycle management according to an embodiment of this application. Figure 1 and Figure 2As shown, this application provides a form core engine system 100 based on model-driven and lifecycle management, including: a model configuration parsing module 110, used to initialize and parse the form model based on the form structure definition, initial value data, initial state configuration, validation rule configuration, and side effect function definition to obtain the mapping relationship between field paths and field models and the lifecycle event registry; a dependency relationship building module 120, used to build field dependency relationships based on the mapping relationship between field paths and field models, formula expressions, and explicitly declared dependency relationship arrays to obtain a dependency relationship graph and a consumer registry; and a business logic dynamic mounting module 130, used to... The system includes a segment path mapping relationship to the field model and a business logic registry. It decouples and dynamically mounts the obtained current business type identifier ID to obtain an enhanced field model set after injecting business logic and an initialized form model instance. The state change propagation module 140 is used to propagate state changes based on user interaction events and the field model instance that triggers the change to obtain the updated field model and state change event queue. The cascading update module 150 is used to automatically calculate and cascade update the dependent fields of the state change event queue, dependency graph and consumer registry to obtain all automatically updated consumer field model sets and the final state snapshot of the form.

[0022] For example, in the model configuration parsing module 110, form model initialization and configuration parsing are performed based on the form structure definition, initial value data, initial state configuration, validation rule configuration, and side effect function definition to obtain the mapping relationship between field paths and field models and the lifecycle event registry. It should be understood that in modern web applications, forms are no longer limited to simple data entry, but are systems involving complex state management, dynamic validation, and lifecycle control. The traditional approach of directly binding logic to UI components leads to high coupling and low reusability. In this step, by standardizing the modeling of the overall form structure and its local units, both are given independent and manageable lifecycles. This not only makes each field a highly cohesive and independently manageable unit, but also establishes a unified control foundation for subsequent automated dependency processing and side effect management through centralized lifecycle event registration. Through this module, static configuration data is transformed into runtime objects with behavioral capabilities, providing the necessary context for subsequent form interaction responses and data flow.

[0023] In one embodiment, such as Figure 3As shown, the model configuration parsing module 110 includes: a structure definition parsing unit 111, used to parse the form structure definition and instantiate the model to obtain the mapping relationship from field path to field model; and a lifecycle event construction unit 112, used to perform value injection, state injection, validation rule association, and side effect registration on the initial value data, initial state configuration, validation rule configuration, and side effect function definition based on the mapping relationship from field path to field model to obtain the lifecycle event registry.

[0024] Specifically, the system first receives the input form structure definition (Schema), which contains metadata descriptions of all fields in the form. The structure definition parsing unit in the model configuration parsing module is responsible for parsing the form structure definition and extracting the configuration information of all fields. The parsing process involves traversing the array of field definitions (usually named schema.fields) in the form structure definition object. For each field definition object (fieldDefinition) in the array, the system dynamically selects the corresponding model class for field model instantiation based on its specified type attribute (type, such as text, number, select, array, etc.). For basic input types, it instantiates the basic field model (FieldModel); for list or nested form structures, it instantiates the array field model (ArrayFieldModel). All field models inherit from a unified base class BaseField, ensuring standardized management of core attributes (such as value, status, and validation rules). Specifically, the array field model, as an extended subclass of the field model, not only inherits the common properties of the base class but also encapsulates specialized operation interfaces for list data, including addRow (add row), removeRow (delete row), and moveRow (move row). When these operations are executed, the array field model automatically triggers its internal reorganization logic, recalculating and updating the path indexes of all its sub-field models (e.g., list.0.name, list.1.name) to ensure that after dynamic addition or deletion of rows, the dependencies and validation rules of all sub-fields still correctly point to the new data paths.

[0025] During instantiation, the system synchronously performs basic attribute mapping. Key attributes parsed from the field definition object, including the name (for field uniqueness), the label (for UI display), the model default value (defaultValue), and the component type identifier (component), are assigned one by one to the newly created model instance. Subsequently, the system constructs or infers the field's unique path in the form tree based on the field name, and uses this path as the key and the newly created model instance as the value to build an initial field path-to-field model mapping relationship (fieldModelSkeletonMap). At this point, the model instance only has a skeletal structure and has not yet been injected with specific runtime data and logic.

[0026] After the skeleton is built, the lifecycle event building unit further processes the initial value data, initial state configuration, verification rule configuration and side effect function definition based on the above mapping relationship.

[0027] First, value injection and state injection are performed. The system iterates through the initial value data (initialValues), locates the specific model instance in the mapping relationship based on the field path corresponding to each data, and assigns the data to the instance's value attribute. Similarly, the system iterates through the initial state configuration (initialState), and merges the display state (display), interaction mode (pattern, such as read-only, disabled), and other configurations into the state attribute of the corresponding model instance.

[0028] Next, validation rules are associated. The system parses the validation rule configuration (validationRules), and for each field defined in the form structure definition, it finds and associates the corresponding validation logic. These rules may include mandatory field checks, regular expression matching, or custom asynchronous validation functions. The associated rules are stored in the validation rule configuration property of the model instance, enabling the fields to have self-validation capabilities.

[0029] In the specific system architecture implementation, the validation logic can be encapsulated into an independent validator module, which is decoupled from the field model. When the field model needs validation, it passes the current value and rule configuration as parameters to the validator module. This module supports synchronous validation logic as well as asynchronous validation logic that returns a Promise object, and returns the validation result (including error information and validity status) to the field model for status update.

[0030] The validation rules support two types of validation logic: synchronous rules (such as required field checks and regular expression matching) and asynchronous rules (functions provided by developers that return Promise objects, used for scenarios such as remote uniqueness checks). Each rule can be configured with its own trigger, including but not limited to onChange (when the value changes), onBlur (when the value is lost in focus), or onSubmit (when the value is submitted). The system will automatically schedule the validation execution according to the triggering strategy.

[0031] Finally, side effect registration is performed. The system calls the side effect function definition (effects), which accepts a subscription interface. Inside the function, specific business logic callback functions are registered in the lifecycle event registry by calling the subscription method (such as subscribe). The registry stores a list of corresponding callback functions indexed by event names (such as onFormInit (form initialization), onFieldValueChange (field value change), onFieldMounted (field mounting), etc.).

[0032] Finally, the system aggregates all configured field models into the top-level form model (FormModel), triggers lifecycle events, publishes the form model instance as payload, activates all side-effect functions registered in the initialization phase, and completes the entire initialization process.

[0033] In one specific implementation, there is a user information entry form with a structure defining two fields: username (text type) and user level (selectable type). The initial value data contains {"username":"Alice","level":1}. During implementation, the module first parses the form structure definition and creates two basic field model instances. The instance named "username" is mapped to the path "root.username", and the instance named "level" is mapped to "root.level". Next, the system injects "Alice" into the value attribute of the "username" instance and injects 1 into the "level" instance. If a side-effect function is defined to "print a log when the user level changes", the system parses this function and registers a callback function under the `onFieldValueChange` event of `lifecycleRegistry`. The callback function's internal logic checks if the changed path is "root.level"; if so, it performs a print operation. The final output includes a mapping table containing these two configured model instances and an event registry containing the printing logic.

[0034] For example, in the dependency construction module 120, field dependency relationships are constructed by mapping relationships from field paths to field models, formula expressions, and explicitly declared dependency arrays to obtain a dependency graph and a consumer registry. It should be understood that in complex business forms, fields often have close dependencies; for example, the value of one field is calculated from the values ​​of several other fields, or the display state of one field depends on the selection of other fields. Traditional development models typically require developers to write a large amount of tedious imperative code to manually monitor field changes and update related fields. This approach is not only labor-intensive but also prone to inconsistencies due to missed dependencies or logical errors. In this module, an automated consumer system is established, which transforms implicit business logic into an explicit data dependency graph structure by parsing formula expressions or explicit declarations. The consumer system refers to a mechanism for automating the handling of dependencies between form fields. It identifies fields that are consumed (such as fields calculated using formulas) and monitors changes to the fields they depend on. When a dependent field changes, the consumer system automatically triggers a recalculation and status update of the consumed field, achieving responsive data linkage. This allows the system to automatically identify the reference relationships between fields, thus accurately and automatically driving updates to affected fields when the source data changes. This frees developers from the complex task of manually maintaining dependencies, improving code robustness and maintainability.

[0035] In one embodiment, such as Figure 4 As shown, the dependency relationship construction module 120 includes: a consumer information generation unit 121, used to perform consumer field identification and dependency parsing on the mapping relationship from field path to field model based on formula expression and explicitly declared dependency relationship array to obtain a consumer information list and a set of all field paths; and a dependency relationship graph construction unit 122, used to construct a dependency relationship graph and register consumers based on the consumer information list and the set of all field paths to obtain a dependency relationship graph and a consumer registry.

[0036] Specifically, the system first traverses the mapping relationship (fieldModelsMap) from the input field paths to the field models, identifying all fields containing formulas or explicitly declared dependency arrays, and defining these fields as "consumer fields." The system uses a consumer information generation unit to parse these fields. If a field model contains a formula attribute (e.g., the expression "field1+field2"), the system performs lexical and syntactic analysis on the string, automatically extracting other field identifiers referenced (such as field1 and field2) to form a dependency list. Simultaneously, the system dynamically generates an executable computation function (referred to as `computationFunction` in the formula below) based on the parsed formula. (Referencing). The core logic of this computation function can be abstractly represented as:

[0037]

[0038] in, This represents the consumer field. This is a context object containing the values ​​of all current dependencies. If the field model only contains an array of dependencies without formulas, the system directly uses that array as the dependency list and may associate it with a default aggregation function. Ultimately, the system generates consumer information data containing field paths, calculation functions, and the dependency list.

[0039] Then, based on the identified consumer information, the dependency topology generation unit is responsible for constructing a global dependency graph and consumer registry. First, the system initializes the consumer registry, storing the paths of consumer fields as keys and their corresponding computed functions and lists of dependencies as values. Next, the system initializes the dependency graph, typically represented as an adjacency list, using the paths of dependent fields as keys and lists of all consumer field paths that depend on those fields as values. The system iterates through each consumer field and its dependency list, adding the path of the current consumer field to the corresponding entry in the dependency graph for each dependency (i.e., the field it depends on). For example, if field A depends on field B, then field A is added to the entry for field B in the graph. This structure allows the system to quickly index field A when field B changes. Simultaneously, the system establishes a field change monitoring mechanism in the consumer system, subscribing to form field change events for all dependent fields.

[0040] Finally, to ensure the logical correctness of dependencies, the system performs integrity verification on the constructed dependency graph. Using graph theory algorithms (such as Depth-First Search (DFS) or topological sorting), the system detects the existence of circular dependencies in the graph. If a cycle is detected (e.g., A depends on B, and B depends on A), the system marks the anomaly and records the relevant path to prevent infinite recursive updates in subsequent runtime. Furthermore, the system verifies whether the dependencies exist in the current set of form fields to ensure that all references are valid.

[0041] In one specific implementation, there is an order form containing three fields: unit price (price), quantity (quantity), and total price (total). The total price field defines the formula "pricequantity". During implementation, the module first identifies the total price as a consumer field. By parsing the formula, it extracts the dependency list [price, quantity] and generates the calculation function (values) = values.price * values.quantity. Next, a dependency graph is constructed, adding "total" under entries with "price" as the key and "total" under entries with "quantity" as the key. Simultaneously, "total" and its calculation function are registered in the consumer registry. Once the unit price changes, the system can find the total price that needs updating through the dependency graph and recalculate its value using the function in the registry.

[0042] In another embodiment, the field "discountEligible" does not depend on a calculation formula, but instead explicitly declares that it depends on an array of field paths ["user.level", "order.amount"]. During initialization, the system directly uses this array as a list of dependencies and triggers a re-evaluation of the discountEligible field (e.g., executing a predefined conditional function) whenever any dependent field changes, without parsing the formula expression.

[0043] For example, in the business logic dynamic mounting module 130, based on the mapping relationship between field paths and field models and the business logic registry, the obtained current business type identifier ID is decoupled from business logic and dynamically mounted to obtain an enhanced field model set after injecting business logic and an initialized form model instance. It should be understood that in enterprise applications, different types of business forms (such as ordinary customer entry and VIP customer management) often share similar basic fields (such as name and phone number), but their business logic (validation rules, linked behaviors) differs and has a hierarchical inheritance relationship. Traditional static logic loading methods cannot effectively handle these complex inheritance relationships and are difficult to provide clear resolution strategies when there are conflicts in multi-module logic, resulting in low code reusability, high maintenance costs, and unpredictable system behavior. This module establishes a context-based dynamic logic injection mechanism. By identifying the inheritance relationship between business logics and combining runtime context for dynamic filtering and conflict resolution, the system can intelligently assemble discrete business logic slices and mount them onto the target field model. This not only achieves complete decoupling of business logic and data model, but also ensures that the form system has a high degree of adaptability and robustness when facing complex and ever-changing business needs.

[0044] In one embodiment, the dynamic mounting of business logic modules employs a simple static matching mechanism. Assume the current business type identifier ID is "TypeA," and the business logic registry only stores independent configurations for each business type, without any hierarchical relationship. When the system obtains the "TypeA" identifier, it directly searches the registry for the logic module with the key "TypeA." If a match is found, the module may contain the following logic: "Field path=customerName is required" and "Display the path=discount field when path=amount is greater than 1000." The system iterates through these logic configurations, directly finding the corresponding field models (customerName, amount, discount), and assigns the validation rule `required: true` and the corresponding side-effect function to the model attributes.

[0045] The dynamic loading mechanism for form business logic described in the above embodiments has a technical problem, the core of which lies in the limitations of its logic loading method. This mechanism typically relies on a single, static business type identifier (currentBusinessType) to perform a direct one-to-one query and match in the business logic registry, loading the corresponding logic module. This static matching and single-point loading design fails to adequately consider the special relationships commonly found in complex business scenarios, leading to several technical weaknesses.

[0046] First, it cannot effectively handle inheritance or hierarchical relationships between business logic. For example, in a VIP customer management form, its business logic should be a superset of general customer management logic, but the existing mechanism cannot automatically identify and load such a combination of parent and child modules, leading to difficulties in logic reuse and increased manual maintenance costs. Second, when multiple logic modules (such as base modules and derived modules) simultaneously affect the same form field, the mechanism lacks a clear conflict resolution strategy, making logic overriding behavior implicit and unpredictable, easily causing program defects that are difficult to troubleshoot. Finally, its logic loading decision-making basis is too crude, relying entirely on business type identifiers and lacking adaptability to runtime dynamic contexts. For example, it cannot dynamically adjust or filter the business logic to be loaded based on specific data values ​​already filled in the form or the current user's role, resulting in insufficient system flexibility and intelligence.

[0047] To address the aforementioned technical issues, this application further proposes an intelligent context-driven adaptive business logic injection method. By introducing hierarchical business logic registration, context-based dynamic filtering and priority sorting, and an intelligent conflict resolution mechanism, it achieves a more flexible, robust, and innovative business logic management process.

[0048] In a preferred embodiment, such as Figure 5 As shown, the business logic dynamic mounting module 130 includes: a business logic retrieval unit 131, used to perform hierarchical and context-related retrieval of applicable logic modules based on the mapping relationship from field path to field model and the business logic registry to obtain a sorted list of applicable modules; a logic fusion injection unit 132, used to perform conflict-aware logic injection and fusion on the sorted list of applicable modules based on the mapping relationship from field path to field model to obtain an enhanced field model set after injecting business logic; and a side effect mounting unit 133, used to update the enhanced field model set after injecting business logic to the form model instance, and to perform global lifecycle registration and initialization event triggering for the side effect functions in the enhanced field model set after injecting business logic to obtain an initialized form model instance.

[0049] First, based on the mapping relationship from field paths to field models and the business logic registry, the business logic retrieval unit performs hierarchical and context-dependent retrieval of applicable logic modules for the current business type identifier ID to obtain a sorted list of applicable modules. This unit aims to address the drawbacks of static, single-point loading in traditional mechanisms; that is, it needs to identify and integrate all hierarchical logic modules related to the current business scenario, rather than just directly matching a single module. In one embodiment, the business logic retrieval unit 131 includes: a module retrieval aggregation subunit 1311, a context filtering subunit 1312, and a priority sorting subunit 1313.

[0050] Specifically, the module retrieval aggregation subunit 1311 performs initial module retrieval and hierarchical logic aggregation based on the business logic registry, using the current business type identifier ID, to obtain an unfiltered set of business logic modules. That is, it first uses the current business type identifier (currentBusinessType) to perform an initial query in the hierarchical business logic registry that supports inheritance relationships and metadata definitions to locate the basic business logic module. Subsequently, the system recursively traverses all ancestor modules of this basic module until the root module, thereby collecting a set of unfiltered modules containing a complete inheritance chain.

[0051] Correspondingly, for a VIP customer follow-up form, this process not only identifies the VIP customer's own logic module but also automatically traces and includes related logic such as its parent module (general customer) and higher-level basic CRM objects, laying the foundation for subsequent logic combinations. Next, the context filtering subunit 1312, based on the context information set, performs context condition filtering and applicable module selection on the unfiltered business logic module set to obtain a list of modules that meet the context conditions. The context information set includes the current business type identifier ID, the mapping relationship between field paths and field models, all data in the current form, and runtime context information (i.e., dynamic parameters reflecting the current execution environment, including but not limited to the current user's role permissions, client device type, current system time, or geographical location), ensuring that only modules truly applicable to the current specific scenario are retained. Finally, the priority sorting subunit 1313 sorts the filtered applicable module list in descending order according to their inherent priority (e.g., sub-modules have higher priority than parent modules), forming an ordered list of logic modules to be injected. In this way, the static logic loading is transformed into a dynamic and adaptive logic recipe combination process, ensuring that the system can intelligently and accurately gather all the business logic that should be activated based on rich context information, which greatly improves the efficiency of logic reuse and the flexibility of the system.

[0052] The core calculation formula for this process is shown below:

[0053]

[0054] in, A list of applicable business logic modules in the final output, ordered by priority; This represents an operation that sorts the data in descending order based on the value of a priority function. Represents an instance of a business logic module; It represents the set of all related modules traced along the inheritance chain from the current business type identifier ID; This represents a Boolean activation condition function used to determine the module. In a given context Does this apply? This represents a complete context object that includes the current business type identifier ID, the mapping relationship between field paths and field models, all data of the current form, and runtime context information.

[0055] Secondly, the logic fusion injection unit performs conflict-aware logic injection and fusion on the sorted list of applicable modules to obtain an enhanced field model set after injecting business logic. That is, multiple logic modules retrieved by the previous unit may have defined conflicting logic (such as different validation rules) for the same field. A deterministic mechanism must be established to resolve these conflicts in order to avoid unpredictable system behavior.

[0056] Specifically, each applicable logic module is processed sequentially according to the priority order generated by the previous unit. For the currently processed module, the system extracts its contained field-level logic definitions and identifies the target fields affected by them. Before injecting new logic into the target field, the system checks whether the field already contains logic from a higher-priority module. If a conflict is detected, the system will enable a predefined conflict resolution strategy, which can be: direct overriding based on priority, intelligent fusion of mergeable logic (such as a list of validation rules), or invoking a custom conflict resolution function explicitly defined on a module or field.

[0057] It's understandable that when the general customer module requires a credit rating field as mandatory, while the VIP customer module requires it to be either A or B, the system can deterministically apply the stricter or more appropriate rule through a priority strategy or a custom function, rather than creating confusion. After conflict resolution, the finalized logic is injected into the corresponding field model, and the entire resolution process is logged in detail for traceability. This step aims to establish a predictable, traceable, and robust logic composition mechanism. Its effect is to ensure that even under complex intertwined business logic, the final behavior of each field is unique and as expected, thereby significantly improving the system's stability and maintainability.

[0058] Its core conflict resolution logic can be formally expressed as:

[0059]

[0060] in, Representative field The final set of logic that takes effect; Representative field Logic that already exists in the module and originates from a higher-priority module; This represents the logical AND operation, meaning that only when... The corresponding operation will only be executed when both conditions on both sides are met. For example, in the first equation, the operation will only be executed if there is a conflict. And the strategy chosen is ( The operation will only be executed if both conditions (true and false) are met. The corresponding operation; This represents the new logic that is currently to be injected; It is a Boolean function used to detect whether there is a conflict between the two. It is a preset conflict resolution strategy identifier; and These represent the logical fusion function and the custom conflict resolution function, respectively. This represents a logical set merging operation in the absence of conflicts. This is a conflict resolution strategy identifier, indicating that when a conflict is detected, the existing (higher priority) logic will be used directly. Ignoring the new logic .

[0061] Finally, the side effect mounting unit executes the dynamic side effect mounting and initialization triggering steps. It should be understood that it is necessary to ensure that all business logic that has been dynamically loaded, parsed, and merged is activated and executed at the correct stage of the form's lifecycle.

[0062] Specifically, the side effect mounting unit updates the enhanced field model, which has already undergone logic injection and fusion in the previous unit, to the top-level form model instance. Subsequently, the system traverses all field models, extracts all the finally determined side effect functions, and registers them in the global lifecycle registry based on their associated lifecycle events (such as onFormInit).

[0063] This ensures that when the form is initialized, both the address-linked side effects defined in the general customer module and the welcome message side effects injected from the VIP customer module can be accurately mounted and triggered. After registration, the system publishes a form initialization event (onFormInit), which activates all registered initialization-related side effects, allowing the form to complete its final state adjustment and behavior preparation based on all injected business logic. This step, as the closing and activation stage of the entire dynamic logic injection process, ensures that abstract logical definitions can be transformed into concrete runtime behaviors, so that the initialized form model instance, when finally presented to the user, is a fully configured, behaviorally defined, and dynamic entity that embodies all applicable business intelligence.

[0064] Its core execution process can be abstractly described as follows:

[0065]

[0066] in, This represents the final state of the form after all initialization side effects have been executed; This represents the execution of the entire chain of side effect functions; This represents the merged and sorted set of all side effect functions registered for the initialization event. Represents the initial state of the form; Indicates the first Side effect function In the previous state Execute on the basis of, and generate a new state. The process.

[0067] In summary, the aforementioned technical methods have enabled the construction of a core form management approach capable of intelligently adapting to complex business scenarios. This method departs from the static and rigid logic loading model of traditional mechanisms, achieving dynamic logic discovery, combination, and activation based on business logic hierarchy, runtime context, and preset strategies. This results in a highly flexible and scalable form system. Its core technical effects are: First, by supporting business logic inheritance relationships, it significantly improves the reusability of logic modules and reduces development and maintenance costs in complex business scenarios. Second, by introducing a deterministic conflict perception and resolution mechanism, it ensures the predictability and robustness of system behavior under multiple logical influences, significantly improving system stability. Third, by incorporating runtime context into logic loading decisions, forms can dynamically adapt to specific data and scenarios, achieving deeper levels of intelligence and personalization. Ultimately, this technical approach aims to create a form engine capable of autonomous evolution and self-adjustment, easily handling ever-changing and growing business needs without requiring intrusive modifications to the core architecture.

[0068] Finally, the system updates these enhanced field model sets into the core form model. For all side effects identified during the integration process, the system registers them in the global lifecycleRegistry based on their associated lifecycle events (such as onFormInit and onFieldMounted). After registration, the system publishes the onFormInit event, triggering all mounted initialization side effects, completing the final activation of the business logic, and bringing the form instance into a ready state. It is important to note that the registration of side effect functions relies on the underlying Subscribable event subscription system. Developers bind callback functions to specific lifecycle events through declarative APIs (such as onFieldValueChange(fieldName, callback)), and the system internally uses a publish-subscribe pattern to decouple and distribute events. When a field value changes, the field model automatically publishes the onFieldValueChange event, triggering the execution of all subscribers, ensuring that the side effect functions are not directly coupled to the core model.

[0069] In a specific embodiment, assume the system has a general customer module (ID: 100) and a VIP customer module (ID: 101) that inherits from it. The general module defines the "Credit Rating" field as optional; while the VIP module requires this field to be mandatory and can only be "Level A". When currentBusinessType is 101, the retrieval unit first finds the VIP module and its parent general module. After context filtering, both modules are applicable. Because the VIP module has higher priority, during the conflict injection phase, the system detects a conflict in the validation rules for the "Credit Rating" field. According to the priority strategy, the VIP module's "mandatory and Level A" rule overrides the general module's rule. Ultimately, the field model is injected with strict validation logic, and the relevant VIP-specific side effects (such as "displaying a special badge upon reaching Level A") are also registered in the lifecycle.

[0070] For example, in the state change propagation module 140, state change propagation is performed based on user interaction events and the field model instances that trigger the changes to obtain the updated field models and state change event queues. It should be understood that during the interaction between a web application and a user, every input, click, or selection by the user triggers a change in the form state. These changes are not merely simple numerical updates; they are often accompanied by data validation, state linkage (such as showing / hiding), and the triggering of side-effect functions. Without a unified propagation mechanism, the processing logic for state changes will be scattered across various UI components, leading to chaotic data flow, inconsistent state updates, and difficulty in tracking. Based on this, this module establishes a standardized state change propagation channel. By transforming originally discrete user interaction events into ordered, subscribed internal state change events, the system can ensure that each data update undergoes unified model layer processing (including assignment and validation) and accurately broadcasts the change information to all listeners interested in the change (including side-effect functions and dependent update modules), thereby achieving controllability, consistency, and predictability of the data flow.

[0071] Specifically, the system first listens for and receives user interaction events (userInputEvent) from the UI layer. This event contains the target field path (targetFieldPath) that triggered the operation and the new value entered by the user (newValue). The module quickly locates the corresponding field model instance (currentFieldModel) in the field model mapping table (fieldModelsMap) based on the path. Then, it calls the setValue method (or an equivalent state update interface) of that model instance to write newValue into the model's internal value property. This step completes the basic state synchronization from external interaction to the internal data model.

[0072] While field values ​​are being updated, to ensure data validity, the module automatically triggers the validation process based on pre-configured trigger strategies (such as onChange or onBlur) in the field model. The system extracts the validationRules from the field model instance and performs immediate validation on the new value. The validation logic may involve regular expression matching, required field checks, or asynchronous API calls. After validation is complete, the system updates the field model's error information attribute (errors) and validation status indicator (valid / invalid) based on the results. If validation errors exist, the errors attribute will be populated with specific error descriptions, and valid will be marked as false, resulting in an "updated field model" containing the latest value and its validity status.

[0073] Once the field model has been updated and validated, the module immediately constructs a state change event object. This object encapsulates key context information, typically including the field path, old value (oldValue), new value (newValue), and trigger type. Subsequently, the field model instance invokes the internal publishing mechanism (or via the global event bus) to formally publish the onFieldValueChange event.

[0074] At this point, all side effect callbacks that had previously subscribed to the field change event through the lifecycle registry will be activated. The system executes these callbacks sequentially according to their registration order. These side effect functions may not only trigger state changes in other fields (such as changing the visibility of another field based on the selected value), but also serve as the source of the "state change event queue," which can be consumed by subsequent cascading update modules. Thus, a single point of user interaction is transformed into a standardized event flow that can be propagated and processed within the system.

[0075] In one specific implementation, a form contains an "Age" input field (path: user.age), configured with a validation rule of "greater than 18 years old," and a side-effect function: when the age changes, it determines whether to display the "Guardian" field based on the age. When the user enters "20" in the input field, the state change propagation module first captures the input event, finds the user.age field model, and updates its value to 20. Next, the system executes the validation rule, confirming that 20 is greater than 18, the validation passes, and the model state is marked as valid. Subsequently, the system publishes an onFieldValueChange event with a payload containing {path:user.age,value:20}. The side-effect function listening for this event is triggered, executes the logic to determine that the age is greater than 18, and then sends a command to hide the "Guardian" field. After this series of actions is completed, the updated age field model and a queue containing this change event are output, awaiting further processing.

[0076] For example, in the cascading update module 150, dependency fields are automatically calculated and cascading updated on the state change event queue, dependency graph, and consumer registry to obtain a set of all automatically updated consumer field models and a snapshot of the final form state. Specifically, this module replaces the traditional manual command-based update logic with an automated dependency tracking and calculation mechanism, thereby ensuring that when the basic data in the form changes, all derived data that directly or indirectly depends on that data can be synchronously updated in real time and accurately, maintaining the eventual consistency of the form data state.

[0077] Specifically, the data processing of this module is an event-driven, breadth-first or depth-first propagation process, mainly comprising four closely linked sub-stages: event capture, dependency resolution, context computation, and state iteration. First, the system listens to or polls the state change event queue in real time, extracting the identifier of the currently changed field, which is recorded as the changed field path. Then, using this changed field path as the index key, the system queries the dependency graph to retrieve the set of all affected fields directly dependent on the changed field, i.e., the consumer field list. For each consumer field in the list, the system retrieves its predefined computation function and complete dependency list from the consumer registry. Next, based on the dependency list, the system collects the real-time values ​​of all dependent fields from the current form state to construct the computation context.

[0078] Based on this, the system executes calculation logic to determine the new value of the consumer field. This calculation process can be abstracted as substituting context values ​​into the calculation function, and its mathematical expression is as follows:

[0079]

[0080] in, This represents the new value calculated from the consumer field. This represents the current value of each field in the dependency list. After obtaining the calculation result, the system calls the value update method (such as setValue) of the consumer field model to update the value. Write the data to the field model. Crucially, this update operation itself is treated as a new state change event by the system and either pushed back into the state change event queue or directly triggered a recursive call, thus initiating the next round of dependency checks and updates. This continues until all related dependency chains have been processed and no new changes have occurred, or a preset recursion depth threshold is reached to prevent infinite loops caused by circular dependencies. Finally, after the cascading updates have quieted down, the system collects all updated consumer field models, forming an automatically updated set of consumer field models, and saves a snapshot of the current values ​​and states of all fields, generating a final form state snapshot as the final output of this interaction.

[0081] In a specific embodiment, a sales order form has three fields: unit price (path is price), quantity (path is quantity), and total price (path is total). During the model configuration phase, the total field is defined as a consumer field, which depends on price and quantity, and the calculation formula is configured as price * quantity. Based on the aforementioned technical solution, after the system initializes the dependency relationship building module, two records will be generated in the dependency relationship graph: one with price as the key pointing to [total], and the other with quantity as the key pointing to [total]; at the same time, the calculation logic of total is recorded in the consumer registry. When the user modifies the value of the price field on the interface (for example, from 10 to 20), the state change propagation module will generate a change event containing path: price, newValue: 20. After entering this step, the cascading update module first captures the event and finds by querying the dependency relationship graph that the change of price is consumed by the total field. Therefore, the module extracts the calculation function of total from the registry and obtains the latest values ​​of the current price (20) and quantity (assuming it is 5). The module calculates 20 × 5 = 100. Then, it automatically updates the model value of the `total` field to 100. If the system also has a `total` field that depends on `total` (path: `totalWithTax`, formula: `total*1.1`), this update of `total` will trigger a new round of cascading updates. The module will continue to calculate 100*1.1 and update `totalWithTax` to 110, ultimately outputting a model set containing the latest states of `total` and `totalWithTax`, thus achieving automatic data linkage.

[0082] In other alternative implementations, the model-driven and lifecycle management-based form core engine system of this application can also achieve the same technical effect through different technical paths. For example, the event bus in the state change propagation module can be implemented using a reactive programming library (such as RxJS), modeling the change flow of field values ​​as Observable objects and processing the stream through operators (such as debounce and distinctUntilChanged), thereby optimizing performance in high-frequency update scenarios. The dependency construction module can also establish dependencies through an explicitly declared array of dependencies fields instead of relying on formula parsing. Furthermore, for complex form scenarios with large-scale field dependencies, the dependency construction module and the cascading update module can use more complex graph data structures and graph traversal algorithms (such as dynamic topological sorting or incremental update algorithms) to replace basic adjacency list traversal, further optimizing the computational performance of cascading updates. In addition, the side effect system can be further extended into a pluggable or middleware architecture, allowing a set of related side effect functions to be encapsulated into pluggable units to improve reusability. The states of fields and forms can also be bidirectionally bound to external state management libraries (such as Redux and MobX) and incorporated into the global state management system. All of the above alternative solutions are within the scope of the technical concept of this application, and aim to achieve the unified goal of decoupling core logic from UI, automating dependencies, and controlling lifecycle.

[0083] In summary, the model-driven and lifecycle management-based form core engine system provided in this application has been elucidated. Firstly, it utilizes a model configuration parsing module to parse the static form structure definition, validation rules, and initial configuration into standardized field model mappings and a lifecycle event registry, thus constructing the form's skeleton. Building upon this, the dependency relationship construction module no longer relies on manual imperative coding by developers. Instead, it automatically constructs a dependency topology graph and consumer registry reflecting the reference relationships between fields by parsing formula expressions and explicit declarations. To address the issue of rigid business logic, a dynamic business logic mounting module introduces a dynamic injection mechanism. Based on the current business type identifier, it can dynamically mount specific business logic slices onto the corresponding field models, achieving on-demand loading and decoupling of logic. When user interaction triggers data changes, the state change propagation module and the cascading update module work together. The former captures the original event and transforms it into a standardized state change stream, while the latter automatically calculates and cascades updates all affected consumer fields based on the pre-built dependency topology graph, ensuring data consistency and convergence during propagation.

[0084] As described above, the model-driven and lifecycle-management-based form core engine system 100 according to embodiments of this application can be implemented in various wireless terminals, such as servers with model-driven and lifecycle-management-based form core engine algorithms. In one possible implementation, the model-driven and lifecycle-management-based form core engine system 100 according to embodiments of this application can be integrated into the wireless terminal as a software module and / or a hardware module. For example, the model-driven and lifecycle-management-based form core engine system 100 can be a software module in the operating system of the wireless terminal, or it can be an application developed for the wireless terminal; of course, the model-driven and lifecycle-management-based form core engine system 100 can also be one of many hardware modules of the wireless terminal.

[0085] Alternatively, in another example, the model-driven and lifecycle management-based form core engine system 100 and the wireless terminal can also be separate devices, and the model-driven and lifecycle management-based form core engine system 100 can connect to the wireless terminal via wired and / or wireless networks and transmit interactive information in accordance with an agreed data format.

[0086] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or improvement of the technology in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A model-driven and lifecycle-managed form core engine system, characterized in that, include: The model configuration parsing module is used to initialize and parse the form model based on the form structure definition, initial value data, initial state configuration, validation rule configuration, and side effect function definition to obtain the mapping relationship between field paths and field models and the lifecycle event registry. The dependency building module is used to build field dependencies from field paths to field models, formula expressions, and explicitly declared dependency arrays to obtain a dependency graph and a consumer registry. The business logic dynamic mounting module is used to decouple and dynamically mount the current business type identifier ID obtained based on the mapping relationship between field paths and field models and the business logic registry, so as to obtain the enhanced field model set after injecting business logic and the initialized form model instance. The state change propagation module is used to propagate state changes based on user interaction events and field model instances that trigger changes in order to obtain the updated field models and state change event queues. The cascading update module is used to automatically calculate and cascade update the dependency fields of the state change event queue, dependency graph, and consumer registry to obtain the set of all automatically updated consumer field models and the final state snapshot of the form.

2. The model driven and lifecycle managed form core engine system according to claim 1, wherein, The model configuration parsing module includes: The structure definition parsing unit is used to parse the form structure definition and instantiate the model to obtain the mapping relationship between field paths and field models; The lifecycle event building unit is used to perform value injection, state injection, validation rule association, and side effect registration on initial value data, initial state configuration, validation rule configuration, and side effect function definition based on the mapping relationship from field path to field model to obtain the lifecycle event registry.

3. The model driven and lifecycle managed form core engine system of claim 2, wherein, The structure definition parsing unit is further used for: The form structure definition is parsed and field configurations are extracted to obtain an array of all field configuration objects. The array of all field configuration objects is instantiated with field models and mapped with basic attributes to obtain the mapping relationship between the field paths and field models.

4. The model driven and lifecycle managed form core engine system of claim 1, wherein, The dependency construction module includes: The consumer information generation unit is used to identify consumer fields and resolve dependencies based on formula expressions and explicitly declared dependency arrays to obtain a list of consumer information and a set of all field paths. The dependency graph construction unit is used to construct the dependency graph and register consumers based on the consumer information list and the set of all field paths to obtain the dependency graph and consumer registry.

5. The model driven and lifecycle managed form core engine system of claim 1, wherein, The business logic dynamic mounting module includes: The business logic retrieval unit is used to perform hierarchical and context-related retrieval of applicable logic modules based on the mapping relationship from field path to field model and the business logic registry to obtain a sorted list of applicable modules. The logic fusion injection unit is used to perform conflict-aware logic injection and fusion on a sorted list of applicable modules based on the mapping relationship between field paths and field models to obtain an enhanced set of field models after injecting business logic. The side effect mounting unit is used to update the enhanced field model set after injecting business logic to the form model instance, and to perform global lifecycle registration and initialization event triggering for the side effect functions in the enhanced field model set after injecting business logic, so as to obtain the initialized form model instance.

6. The form core engine system based on model-driven and lifecycle management according to claim 5, characterized in that, The business logic retrieval unit includes: The module retrieval and aggregation subunit is used to perform initial module retrieval and hierarchical logical aggregation on the current business type identifier ID based on the business logic registry to obtain an unfiltered set of business logic modules. The context filtering subunit is used to perform context condition filtering and applicable module selection on the unfiltered set of business logic modules based on the context information set to obtain a list of modules that meet the context conditions. The priority sorting subunit is used to sort the list of modules that meet the context conditions by priority to obtain a sorted list of applicable modules.

7. The form core engine system based on model-driven and lifecycle management according to claim 6, characterized in that, The context information set includes the current business type identifier ID, the mapping relationship between field paths and field models, all data of the current form, and runtime context information.

Images