Construction method, event processing method, device and equipment of dynamic form engine and medium

Abstract

The application discloses a construction method and an event processing method of a dynamic form engine, an apparatus, a device and a medium, relates to the technical field of front-end development, and comprises the following steps: determining fields in a dynamic form, and constructing state nodes based on orthogonal state dimensions of the fields; defining state transition rules containing source states, trigger events, target states, guard conditions and actions, and constructing a state transition table based on the state transition rules; creating a state context storage container, initializing a history recorder, and constructing a state machine based on the state nodes, the state transition table, the state context storage container and the history recorder; the state machine is a state machine corresponding to each of the orthogonal state dimensions and independently running and containing the state nodes; and the state machine, an adapter interface and a view adapter are used to construct a state machine-driven dynamic form engine. The application can construct a state machine-driven and rendering-free front-end dynamic form core engine.

Description

Technical Field

[0001] This invention relates to the field of front-end development technology, and in particular to a method for constructing a dynamic form engine, an event handling method, an apparatus, a device, and a medium. Background Technology

[0002] Dynamic forms are widely used in enterprise systems such as Manufacturing Execution Systems (MES) and Enterprise Resource Planning (ERP). The mainstream industry solutions fall into two categories: configuration-driven and visual construction, both using JSON Schema (a language for describing JSON data) as the form configuration carrier. However, with the continuous increase in business complexity and the growing demand for high-frequency requirements such as deep field linkage, dynamic lists, and multi-layered conditional controls, the existing dynamic form underlying architecture has significant shortcomings and struggles to support complex business interaction scenarios.

[0003] Existing form engines all employ an integrated architecture that couples state logic with the rendering view, relying on data hijacking and event listening to achieve field linkage. State, validation, and visibility control logic are embedded in framework-specific lifecycle code. Changing the UI (User Interface) framework or component library requires rewriting all business logic, resulting in poor reusability. Furthermore, testing is only possible within a DOM (Document Object Model) environment, leading to weak cross-platform adaptability. Traditional reactive dependency tracking mechanisms are prone to dependency explosion when handling nested structures and dynamic row additions / deletions, causing invalid rendering, ghost updates, or even infinite loops. The source of state changes is difficult to trace, resulting in extremely high debugging costs. Simultaneously, existing technologies do not use formal state machines to model form behavior; field visibility, disabling, and required states are stored merely as scattered attributes. State transition rules are hidden within the code, making it impossible to automatically validate illegal state combinations or support state visualization and time-series replay debugging. Even headless form engines only strip away the rendering layer, failing to standardize state modeling and making it impossible to reuse form logic to drive non-standard rendering environments.

[0004] Therefore, how to construct a state machine-driven, non-rendering front-end dynamic form core engine to avoid strong coupling between state logic and view, uncontrollable state in complex linkage scenarios, and limited reusability due to the lack of rendering-free abstraction are the technical problems that urgently need to be solved. Summary of the Invention

[0005] In view of this, the purpose of this invention is to provide a method for constructing a dynamic form engine, an event handling method, an apparatus, a device, and a medium, capable of constructing a state machine-driven, rendering-free front-end dynamic form core engine. This addresses the pressing technical problems of avoiding strong coupling between state logic and view, uncontrollable state in complex interactive scenarios, and limited reusability due to the lack of rendering-free abstraction. The specific solution is as follows: Firstly, this application provides a method for constructing a state machine-driven dynamic form engine, including: Identify the fields in the dynamic form, and construct state nodes based on the orthogonal state dimensions of the fields; Define state transition rules that include source state, triggering event, target state, guard condition, and action, and construct a state transition table based on the state transition rules; the guard condition is a function that determines whether a state transition is allowed; the action is a function that performs side effect operations related to the state transition. Create a state context storage container, initialize the history recorder, and construct a state machine based on the state nodes, the state transition table, the state context storage container, and the history recorder; the state machine is an independently running state machine containing the state nodes, corresponding to each of the orthogonal state dimensions. A state machine-driven dynamic form engine is built using the state machine, adapter interface, and view adapter.

[0006] Optionally, the configuration information of the state machine is defined using a declarative DSL and a preset parser.

[0007] Optionally, the adapter interface may include an event dispatcher, a subscriber interface, and a status reader.

[0008] Optionally, the definition includes the source state, triggering event, target state, guard condition, and state transition rules for the action, and also includes: The guard condition is registered to the guard condition pool in the form of a first identifier, and the action is registered to the action pool in the form of a second identifier, so that the guard condition and the action can be referenced by the state transition rule; The guard condition is a function that takes the state context as input and a Boolean value as output; The actions include actions before state transition, actions after state transition, actions to exit the source state, and actions to enter the target state.

[0009] Optionally, the view adapter includes a user interface framework adapter, a canvas rendering adapter, a command line output adapter, and a simulation adapter for automated testing.

[0010] Secondly, this application provides an event handling method based on a dynamic form engine, applied to a dynamic form engine; the dynamic form engine is an engine built based on the aforementioned state machine-driven dynamic form engine construction method; wherein, the event handling method includes: Receive target events related to the target dynamic form, parse the event type and target field of the target event, and query the target state transition rule in the state transition table based on the current state of the target field and the event type; Obtain the target guard condition in the target state transition rule. If the target guard condition determines that state transition is allowed based on the state context of the target field, then execute the target action in the target state transition rule and change the current state to the target state, so as to render the preset view layer by utilizing the state difference between the current state and the target state.

[0011] Optionally, after changing the current state to the target state, the method further includes: Record the corresponding state change operation, generate a corresponding change snapshot based on the state change operation, and store the change snapshot in the history recorder of the dynamic form engine; the change snapshot is a snapshot including the data value of the target field, the target state node of the target field, and a copy of the target event.

[0012] Thirdly, this application provides a construction apparatus for a state machine-driven dynamic form engine, comprising: The node construction module is used to determine the fields in the dynamic form and construct state nodes based on the orthogonal state dimensions of the fields; The transition table construction module is used to define state transition rules that include source state, triggering event, target state, guard condition, and action, and to construct a state transition table based on the state transition rules; the guard condition is a function that determines whether a state transition is allowed; the action is a function that performs side effect operations related to the state transition. The state machine construction module is used to create a state context storage container, initialize a history recorder, and construct a state machine based on the state nodes, the state transition table, the state context storage container, and the history recorder; the state machine is an independently running state machine containing the state nodes, corresponding to each of the orthogonal state dimensions. The engine building module is used to build a state machine-driven dynamic form engine using the state machine, adapter interface, and view adapter.

[0013] Fourthly, this application provides an electronic device, comprising: Memory, used to store computer programs; A processor for executing the computer program to implement the aforementioned method.

[0014] Fifthly, this application provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned method.

[0015] In this application, fields in a dynamic form are determined, and state nodes are constructed based on the orthogonal state dimensions of the fields; state transition rules are defined, including source state, triggering event, target state, guard condition, and action, and a state transition table is constructed based on the state transition rules; the guard condition is a function that determines whether a state transition is allowed; the action is a function that performs side effect operations related to the state transition; a state context storage container is created, a history recorder is initialized, and a state machine is constructed based on the state nodes, the state transition table, the state context storage container, and the history recorder; the state machine is an independently running state machine containing the state nodes, corresponding to each of the orthogonal state dimensions; a state machine-driven dynamic form engine is constructed using the state machine, adapter interface, and view adapter. As shown above, this application first constructs state nodes based on the orthogonal state dimensions of the fields. Then, it defines state transition rules using source state, triggering event, target state, guard conditions, and actions as elements, and forms a state transition table accordingly. Guard conditions are used to determine whether a state transition can occur, and actions are used to handle the side effects related to the transition. Subsequently, a state context storage container is set up and a history recorder is initialized. Combined with the state nodes and the state transition table, a state machine is constructed that corresponds to each orthogonal state dimension and operates independently. Finally, using this state machine, along with the adapter interface and view adapter, a state machine-driven dynamic form engine is formed. In this way, the constructed dynamic form engine makes the state description and transition logic of form fields structured and configurable, improving the flexibility and maintainability of dynamic form state management. Attached Figure Description

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

[0017] Figure 1 This application discloses a flowchart of a method for constructing a state machine-driven dynamic form engine. Figure 2 This application discloses a flowchart of an event handling method based on a dynamic form engine. Figure 3 This is a schematic diagram illustrating the principle framework of a dynamic form engine disclosed in this application; Figure 4 This is a schematic diagram of a composite field status disclosed in this application; Figure 5This application discloses a state transition flowchart; Figure 6 This is a timing diagram illustrating a field linkage method disclosed in this application; Figure 7 This is a schematic diagram of a state machine configuration disclosed in this application; Figure 8 This application discloses a flowchart of the execution of guard conditions; Figure 9 This is a schematic diagram of a time travel mechanism disclosed in this application; Figure 10 This is a schematic diagram of the working timing of an adapter disclosed in this application; Figure 11 This is a schematic diagram of the runtime architecture of a dynamic form engine disclosed in this application; Figure 12 This is a schematic diagram of the structure of a state machine-driven dynamic form engine construction device disclosed in this application; Figure 13 This is a schematic diagram of an event handling device based on a dynamic form engine disclosed in this application; Figure 14 This is a structural diagram of an electronic device disclosed in this application. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. 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 are within the scope of protection of the present invention.

[0019] Currently, existing form engines all adopt an integrated architecture that couples state logic with the rendering view, relying on data hijacking and event listening to achieve field linkage. State, validation, and visibility control logic are embedded in framework-specific lifecycle code. When changing UI frameworks or component libraries, all business logic must be rewritten, resulting in poor reusability. Furthermore, testing is only possible within a DOM environment, leading to weak cross-platform adaptability. Traditional reactive dependency tracking mechanisms are prone to dependency explosion when handling nested structures and dynamic row additions / deletions, causing invalid rendering, ghost updates, or even infinite loops. The source of state changes is difficult to trace, resulting in extremely high debugging costs. Simultaneously, existing technologies do not use formal state machines to model form behavior; field visibility, disabling, and required states are only stored as scattered attributes. State transition rules are hidden within the code, making it impossible to automatically validate illegal state combinations or support state visualization and timing replay debugging. Even headless form engines only strip away the rendering layer, failing to standardize state modeling and making it impossible to reuse form logic to drive non-standard rendering environments. To address these issues, this application provides a method for constructing a dynamic form engine, an event handling method, a device, an equipment, and a medium. This method can construct a state machine-driven, non-rendering front-end dynamic form core engine to avoid the current technical problems of strong coupling between state logic and view, uncontrollable state in complex linkage scenarios, and limited reusability due to the lack of rendering-free abstraction.

[0020] See Figure 1 As shown in the figure, this invention discloses a method for constructing a state machine-driven dynamic form engine, including: Step S11: Determine the fields in the dynamic form and construct state nodes based on the orthogonal state dimensions of the fields.

[0021] In this embodiment, each field in the dynamic form often has multiple independent state dimensions that are not causally coupled with each other. Since the state dimensions are orthogonal, meaning that a change in the state of any one dimension does not implicitly determine the state values ​​of other dimensions, constructing a corresponding set of state nodes for each orthogonal state dimension can make the definition and maintenance of subsequent state transition rules highly scalable.

[0022] Step S12: Define state transition rules that include source state, triggering event, target state, guard condition, and action, and construct a state transition table based on the state transition rules; the guard condition is a function that determines whether state transition is allowed; the action is a function that performs side effect operations related to state transition.

[0023] In this embodiment, in order to achieve orderly migration of field states under different triggering conditions, after determining the state nodes, it is necessary to further define the transition rules between state nodes. Therefore, it is necessary to define state transition rules that include source state, triggering event, target state, guarding conditions and actions, and construct a state transition table based on the state transition rules.

[0024] In addition, the guard condition can be registered to the guard condition pool in the form of a first identifier, and the action can be registered to the action pool in the form of a second identifier, so that the guard condition and the action can be referenced by the state transition rule; the guard condition is a function that takes the state context as input and a Boolean value as output; the action includes a pre-state transition action, a post-state transition action, a source state exit action, and a target state entry action.

[0025] By registering guard conditions and actions to their respective pools using addressable identifiers, the state transition rule itself only needs to reference the corresponding guard conditions and actions in the form of identifiers, without directly embedding specific function implementations. This decouples the declarative description of the state transition rule from the specific implementation of guard conditions and actions, making it easier to reuse guard conditions and actions across different fields and forms. It also facilitates serialized storage, version management, and visual editing of the state transition table.

[0026] Step S13: Create a state context storage container, initialize the history recorder, and construct a state machine based on the state node, the state transition table, the state context storage container, and the history recorder; the state machine is an independently running state machine containing the state node, corresponding to each of the orthogonal state dimensions.

[0027] In this embodiment, after defining the state nodes and state transition tables, it is necessary to construct independently runnable state machines for each orthogonal state dimension. This involves creating a state context storage container, initializing a history recorder, and constructing the state machine based on the state nodes, state transition tables, state context storage container, and history recorder. The configuration information for the state machine is defined using a declarative DSL and a preset parser.

[0028] It should be understood that since each orthogonal state dimension corresponds to an independently running state machine, and each state machine only maintains its own state node, state transition table and historical records for its corresponding dimension, there is no mutual interference in state reading and writing. Therefore, when the state transition rules of a certain state dimension change, only the configuration of the state machine corresponding to that dimension needs to be adjusted, without redesigning or re-verifying the state machines corresponding to other dimensions, thereby significantly reducing the maintenance cost of dynamic form state logic.

[0029] Step S14: Construct a state machine-driven dynamic form engine using the state machine, adapter interface, and view adapter.

[0030] In this embodiment, after constructing the state machine corresponding to each orthogonal state dimension, in order for the state machine to interact with specific application scenarios and view layers, it is necessary to further construct a corresponding adaptation layer. That is, to construct a state machine-driven dynamic form engine using the state machine, adapter interface, and view adapter. The adapter interface includes an event dispatcher interface, a subscriber interface, and a state reader interface. The view adapter includes a user interface framework adapter, a canvas rendering adapter, a command line output adapter, and a simulation adapter for automated testing.

[0031] The event dispatcher, subscriber interface, and state reader together constitute the standardized interaction boundary between the state machine and the external environment. Based on the adapter interface, corresponding view adapters are further provided for different rendering scenarios. Because the state machine and each view adapter are decoupled through a unified adapter interface, a dynamic form engine driven by the same state machine can flexibly adapt to various different runtime environments and rendering targets without modifying the state machine's own configuration.

[0032] As can be seen from the above, in this application, because the state of the dynamic form field is split into multiple mutually orthogonal state dimensions, and an independently running state machine is built for each state dimension, the state transition rules of each state dimension can be defined and verified independently, making the state logic of the dynamic form more maintainable and scalable. At the same time, because the guard conditions and actions in the state transition rules are registered in the form of identifiers to the guard condition pool and action pool respectively and then referenced by the state transition rules, the state transition table itself can be declaratively described, stored and reused independently of the specific business logic implementation. Combined with the declarative DSL and the parsing of the state machine configuration information by the preset parser, the state logic of the dynamic form is further made configurable, visualized and maintainable by non-technical personnel. In addition, because the state machine-driven dynamic form engine decouples the state machine from the specific rendering environment through a unified adapter interface and multiple view adapters, the same set of state machine configurations can be reused in different user interface frameworks, canvas rendering scenarios, command line scenarios and automated testing scenarios, thereby improving the portability and testability of the dynamic form engine in different application scenarios.

[0033] Reference Figure 2 As shown, based on the state machine-driven dynamic form engine constructed above, in order to perform corresponding event handling, this application further discloses an event handling method based on the dynamic form engine, applied to the dynamic form engine; wherein, the event handling method includes: Step S21: Receive the target event for the target dynamic form, parse the event type and target field of the target event, and query the target state transition rule in the state transition table based on the current state of the target field and the event type.

[0034] In this embodiment, the target event can originate from user interaction in the view layer or from cascading events triggered by changes in the state of other fields within the form. Upon receiving the target event, it is first parsed to determine the event type and the target field it points to. Then, considering the current state of the target field in the corresponding state machine, a query is performed using the current state and event type to check if a matching state transition rule exists in the state transition table of the state machine. If the search result is empty, it indicates that the event type does not cause a state transition in the current state, and the event processing flow ends. If a matching target state transition rule is found, the subsequent guard condition determination and action execution flow continues, i.e., the subsequent steps.

[0035] Step S22: Obtain the target guard condition in the target state transition rule. If the target guard condition determines that state transition is allowed based on the state context of the target field, then execute the target action in the target state transition rule and change the current state to the target state, so as to use the state difference between the current state and the target state to render the preset view layer.

[0036] In this embodiment, after changing the current state to the target state, the method further includes: recording the corresponding state change operation, generating a corresponding change snapshot based on the state change operation, and storing the change snapshot in the history recorder of the dynamic form engine; the change snapshot is a snapshot including the data value of the target field, the target state node of the target field, and a copy of the target event.

[0037] It should be noted that if the target guard condition determines that state transition is not allowed based on the current state context of the target field, the state transition is blocked, the current state of the target field remains unchanged, and the target action in the target state transition rule is not executed, thus avoiding unexpected state transitions when business constraints are not met. When the target guard condition determines that state transition is allowed, the execution order of the target actions is as follows: source state exit action, pre-transition action, post-transition action, and target state entry action, ensuring that side effects related to state transition are executed at the correct time during the state transition process. After the state change is completed, by comparing the state differences between the current state and the target state, only the changed state dimensions are rendered and updated in the preset view layer, without needing to re-render the entire form view, thereby reducing view rendering overhead.

[0038] As can be seen from the above, the event handling process performs rule queries in the state transition table based on the current state of the target field and the event type. Before executing the state transition, it further determines the state context through target guard conditions. Therefore, it avoids the illegal state transition problem that may be caused by directly executing the state change based solely on the event type, thus improving the controllability and security of the dynamic form state change process. At the same time, since the state change only renders the preset view layer based on the state difference between the current state and the target state, rather than rendering the entire form, it can effectively reduce the computational overhead of view updates and improve the rendering performance of dynamic forms in scenarios with a large number of fields and high-frequency interactions. In addition, since each state change generates a change snapshot containing field data values, target state nodes, and target event copies and stores it in the history recorder, the dynamic form engine has a complete and traceable state change history. This provides a data foundation for extended functions such as state retracing, undoing and redoing, operation auditing, and problem localization, improving the reliability and maintainability of the dynamic form engine in complex business scenarios.

[0039] The following reference Figure 3 The block diagram of the state machine-driven dynamic form core engine shown below provides a detailed explanation of the technical solution of this application embodiment.

[0040] For a state node, the state of each form field is modeled as a node in a finite state machine.

[0041] Furthermore, a field can simultaneously possess multiple orthogonal dimensions (such as visibility, availability, required fields, validation, and touch functionality), with each dimension operating its own state machine. The dimensions included in a field's composite state can be found in [reference needed]. Figure 4 As shown.

[0042] In other words, this invention explicitly models the scattered and implicit field attributes in traditional dynamic forms as independently running orthogonal state machines.

[0043] Specifically, this invention establishes multiple orthogonal state dimensions for each field. Each dimension is an independent finite state machine with its own defined set of state nodes. The visibility dimension contains two mutually exclusive state nodes: "visible" and "hidden"; the availability dimension contains two mutually exclusive state nodes: "enabled" and "disabled"; the mandatory dimension contains two mutually exclusive state nodes: "required" and "optional"; and the validation dimension contains three state nodes: "validation passed," "validation failed," and "validation in progress."

[0044] These orthogonal dimensions operate independently of each other; a state transition in one dimension will not affect the current state of other dimensions, thus avoiding the state combination explosion problem. Since the legal state nodes of each dimension are explicitly defined, the system can automatically detect and prevent fields from entering undefined illegal state combinations. For example, a field cannot be in both "visible" and "hidden" states at the same time.

[0045] Furthermore, the overall processing flow during state transitions can be referenced. Figure 5 As shown. When field linkage occurs, refer to... Figure 6 As shown, taking "when the value of field A is greater than 10, field B becomes visible instead of hidden" as an example, this illustrates the corresponding field linkage process.

[0046] This invention defines all state change rules in a declarative configuration format within a state transition table, rather than through imperative code. The invention employs a declarative state transition table, where each transition rule contains at least three core elements: the source state, the triggering event, and the target state. Guard conditions and actions can also be attached. All rules are centrally stored in a single transition table. Taking the visibility dimension of a field as an example, a typical transition rule can be expressed as: when a field is currently in a "hidden" state, receives a "scroll into visible area" event, and the guard condition "the block to which the field belongs is active" returns true, transitions to the "visible" state.

[0047] Because the transfer table is a centrally stored pure data structure, the system can perform formal verification on it, automatically detecting issues such as unreachable states, circular dependencies, and rule conflicts. The transfer table can also be exported as a visual graph for business personnel to review and confirm the form's behavioral logic.

[0048] Furthermore, all legal state transition paths are explicitly defined in the state transition table beforehand. Any transition not defined in the table will be rejected by the system, so a field cannot enter an undefined state; for example, it cannot be both "visible" and "hidden" simultaneously. Because state transitions are deterministic—given the current state and the received event—there is at most one matching rule in the transition table—the result of state changes is uniquely predictable, with no uncertain behavior. Since the state transition table can be automatically analyzed by the system, it can detect circular dependencies in advance, such as closed loops like transitioning from state A to state B via event X, and from state B to state A via event Y, issuing warnings during the configuration phase to prevent infinite loops at runtime. Because each state transition is recorded in the history queue, and each transition has a specific triggering event, when problems occur, developers can completely trace back the entire path of state changes, precisely knowing when a field changed from what state and what state due to what event.

[0049] For configuration of the state machine, please refer to... Figure 7 As shown, this invention provides a declarative DSL (Domain Specific Language) for defining state machine configurations. Business users use the JSON declarative DSL to write the state transition rules for form fields, which are then parsed and validated by a built-in parser. Finally, a standardized finite state machine instance is generated at runtime on the front end, automatically driving the state switching of form fields based on page events and custom conditions.

[0050] Regarding the guarding conditions, the evaluation of the guarding conditions for state transitions can be referred to... Figure 8 As shown, after triggering a state transition, the guard condition is evaluated. First, the value of the dependent field is obtained and the judgment function is executed. If the result is true, the state transition is allowed; if it is false, the transition is intercepted and a rejection callback can be executed.

[0051] For historical records and time travel mechanisms, please refer to Figure 9 As shown, multiple timestamped snapshots of form states are stored in the history stack. The time travel control module enables undo, redo, and jump to a specified snapshot operation. Finally, the page is re-rendered after difference calculation, thus realizing the backtracking and playback of form states.

[0052] For adapter interfaces without rendering, the definition of the adapter interface can include a unified FormEngineAdapter standard interface, providing general capabilities for state acquisition, event dispatching, subscription listening, and history access. Four types of dedicated adapters—React (a front-end framework), Vue (a front-end reactive development framework), Canvas (the canvas), and testing—each implement exclusive extension methods to adapt to different runtime environments. Furthermore, the adapter's working sequence can be referenced... Figure 10 As shown in the diagram, the application code subscribes to the initial state of the form fields and obtains the reactive object through the React / Vue adapter. When the user input triggers a change event, it is dispatched to the state machine engine by the adapter to complete the state transition. The engine then broadcasts the new state, and the adapter notifies the application code to re-render.

[0053] Reference Figure 11 As shown, when building a dynamic form engine, the first step is to define the state machine configuration, which means declaring a set of state nodes for each field and defining the state transition rules: source state + event → target state + guard condition + action. The second step is to register guard conditions and actions. Guard conditions are functions that return boolean values ​​to determine whether a transition is allowed, and actions are side-effect functions executed before and after a state transition (assignment, validation, API calls, etc.). Finally, the state context is initialized, which means creating a state storage container, setting the initial state of each field, and initializing the history recorder (i.e., a circular queue with a default capacity of 100).

[0054] Specifically, a guard condition is a pure function that only accepts the current state context as input and returns a boolean value indicating whether the state transition is allowed, without producing any side effects. Action functions, on the other hand, are specifically used to perform side-effect operations, including assigning values ​​to fields, triggering validations, resetting fields, calling remote interfaces, and dispatching new events to other fields. Both guard conditions and action functions are registered in their respective pools using unique identifiers and can be referenced by multiple state transition rules.

[0055] The technical effects of this separation mechanism are: the same guard condition logic of "amount greater than threshold" can be reused by the transfer rules of multiple fields; action functions can be unit tested independently without the state machine environment; complex linkage logic can be decomposed into a declarative combination of "condition plus action" rather than nested imperative code.

[0056] Furthermore, since guard conditions are registered in the guard condition pool using unique identifiers, they can be referenced by multiple state transition rules. Therefore, the same condition logic for "whether the amount is greater than the threshold" can be referenced by the transition rules of field A, field B, and field C simultaneously, without needing to be rewritten. Action functions and guard conditions are independent of each other; action functions can be registered and tested independently, without depending on specific condition judgments. Therefore, developers can adjust trigger conditions without modifying the action function and can reuse the same action under multiple different conditions. The dependent fields of guard conditions are known to the system through static analysis or explicit declaration, so the system can automatically implement fine-grained dependency tracking, re-evaluating the guard condition only when the fields it depends on change, avoiding unnecessary calculations.

[0057] When the dynamic form engine runs, it receives events and pushes user input / system events into a FIFO queue; it queries the transition table and matches transition rules based on the current state and event type; if no match is found, it rejects the transition; it evaluates guard conditions, reads dependent field values, executes guard functions, and aborts the transition if it returns false; it performs state updates, executes exit / entry actions, updates the state context, and records historical snapshots; it notifies the view of updates, broadcasts state change differences, and triggers a re-render of the view layer.

[0058] Furthermore, this invention generates a complete snapshot for each state change. The snapshot contains not only the data values ​​of all fields, but also the state node values ​​for all dimensions of all fields, as well as a copy of the event that triggered the change. Therefore, the undo operation can restore not only the data content of the fields, but also the complete state context, including the field's visibility, availability, and validation status. The history recorder maintains a complete snapshot sequence from the initial state to the current state and supports jumping to any intermediate snapshot. This allows developers to implement time travel debugging, sliding the timeline in the development tools to observe the complete state of the form at different times. The snapshot records a copy of the event that triggered the state change, so developers can see the reason for the state change. For example, they can see that "Field B becomes visible from hidden at timestamp T because Field A triggered an input event with an input value of 12." The system provides state export and import interfaces, allowing users to save the complete state of the current form locally or on the server and restore it in the next session, achieving true breakpoint resumption. This significantly improves the user experience for long forms and complex approval processes.

[0059] It should be noted that this invention completely separates the state machine core engine from the view rendering. The engine itself does not contain any user interface-related code and drives any output form through a standardized adapter interface.

[0060] The layered architecture adopted in this invention consists of a core state machine layer at the bottom, which includes state node definitions, state transition tables, state context storage, and a history recorder. This layer is independent of any user interface framework and can run independently in a pure JavaScript environment (a lightweight, interpreted dynamic programming language). The middle layer is the adapter interface layer, which defines unified interfaces for state readers, event dispatchers, and subscribers. Any view layer that needs to interface with the engine only needs to implement these standardized interfaces. The outermost layer contains the specific view adaptation implementations, including React adapters, Vue adapters, Canvas rendering adapters, command-line output adapters, and mock adapters for automated testing.

[0061] Because the engine core is completely decoupled from view rendering, the same state machine configuration and runtime states can be reused seamlessly across multiple view environments. Developers can directly drive the state machine engine in unit tests to verify the correctness of the logic without simulating a document object model environment.

[0062] In other words, the state machine core can run independently, so the same state machine configuration and runtime logic can be reused by different view adapters without rewriting state management code for each framework. Because it can be reused across frameworks, when a project needs to migrate from React to Vue, or needs to maintain implementations for both PC (Personal Computer) and mobile components simultaneously, only the view adapter layer needs to be changed; the state machine core remains completely unchanged, significantly reducing maintenance costs. Since the state machine core does not depend on the Document Object Model environment, developers can directly unit test the state machine logic in the Node.js (JavaScript runtime environment) environment without simulating a browser environment or rendering real user interface components, resulting in faster test execution and more concise test code.

[0063] Accordingly, see Figure 12 As shown, this application embodiment provides a construction apparatus for a state machine-driven dynamic form engine, including: Node building module 11 is used to determine the fields in the dynamic form and build state nodes based on the orthogonal state dimensions of the fields; The transition table construction module 12 is used to define state transition rules that include source state, triggering event, target state, guard condition, and action, and to construct a state transition table based on the state transition rules; the guard condition is a function that determines whether a state transition is allowed; the action is a function that performs side effect operations related to the state transition. The state machine construction module 13 is used to create a state context storage container, initialize a history recorder, and construct a state machine based on the state nodes, the state transition table, the state context storage container, and the history recorder; the state machine is an independently running state machine containing the state nodes, corresponding to each of the orthogonal state dimensions. Engine building module 14 is used to build a state machine-driven dynamic form engine using the state machine, adapter interface, and view adapter.

[0064] In some specific implementations, the configuration information of the state machine is defined using a declarative DSL and a preset parser.

[0065] In some specific implementations, the adapter interface is an adapter interface that includes an event dispatcher, a subscriber interface, and a status reader.

[0066] In some specific embodiments, the transfer table construction module 12 further includes: An information registration unit is used to register the guard condition to the guard condition pool in the form of a first identifier and the action to the action pool in the form of a second identifier, so that the guard condition and the action can be referenced by the state transition rule; The guard condition is a function that takes the state context as input and a Boolean value as output; The actions include actions before state transition, actions after state transition, actions to exit the source state, and actions to enter the target state.

[0067] In some specific implementations, the view adapter includes a user interface framework adapter, a canvas rendering adapter, a command line output adapter, and a simulation adapter for automated testing.

[0068] Reference Figure 13 As shown, this application embodiment provides an event handling device based on a dynamic form engine, applied to the aforementioned dynamic form engine; wherein, the event handling device includes: The rule query module 21 is used to receive target events about the target dynamic form, parse the event type and target field of the target event, and query the target state transition rule in the state transition table based on the current state of the target field and the event type; The view rendering module 22 is used to obtain the target guard condition in the target state transition rule. If the target guard condition determines that the state transition is allowed based on the state context of the target field, the target action in the target state transition rule is executed, and the current state is changed to the target state, so as to render the preset view layer by utilizing the state difference between the current state and the target state.

[0069] In some specific embodiments, the view rendering module 22 further includes: A snapshot storage unit is used to record corresponding state change operations, generate corresponding change snapshots based on the state change operations, and store the change snapshots in the history recorder of the dynamic form engine; the change snapshot is a snapshot including the data value of the target field, the target state node of the target field, and a copy of the target event.

[0070] Furthermore, embodiments of this application also disclose an electronic device, Figure 14 This is a structural diagram of an electronic device 30 according to an exemplary embodiment. The content of the diagram should not be construed as limiting the scope of this application. Specifically, the electronic device 30 may include: at least one processor 31, at least one memory 32, a power supply 33, a communication interface 34, an input / output interface 35, and a communication bus 36. The memory 32 stores a computer program, which is loaded and executed by the processor 31 to implement the relevant steps in the state machine-driven dynamic form engine construction method disclosed in any of the foregoing embodiments. Furthermore, the electronic device 30 in this embodiment may specifically be an electronic computer.

[0071] In this embodiment, the power supply 33 is used to provide operating voltage for each hardware device on the electronic device 30; the communication interface 34 can create a data transmission channel between the electronic device 30 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this application, and is not specifically limited here; the input / output interface 35 is used to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0072] In addition, the memory 32, as a carrier for resource storage, can be a read-only memory, random access memory, disk or optical disk, etc. The resources stored thereon can include operating system 321, computer program 322, etc., and the storage method can be temporary storage or permanent storage.

[0073] The operating system 321 is used to manage and control the various hardware devices on the electronic device 30 and the computer program 322, which may be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program capable of performing the state machine-driven dynamic form engine construction method executed by the electronic device 30 as disclosed in any of the foregoing embodiments, the computer program 322 may further include computer programs capable of performing other specific tasks.

[0074] Furthermore, this application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the aforementioned method for constructing a state machine-driven dynamic form engine. Specific steps of this method can be found in the corresponding content disclosed in the foregoing embodiments, and will not be repeated here.

[0075] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple; relevant parts can be referred to in the method section.

[0076] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0077] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0078] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0079] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this application. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A method for constructing a state machine-driven dynamic form engine, characterized in that, include: Identify the fields in the dynamic form, and construct state nodes based on the orthogonal state dimensions of the fields; Define state transition rules that include source state, triggering event, target state, guard condition, and action, and construct a state transition table based on the state transition rules; the guard condition is a function that determines whether a state transition is allowed. The action is a function that performs side effect operations related to state transitions; Create a state context storage container, initialize the history recorder, and construct a state machine based on the state nodes, the state transition table, the state context storage container, and the history recorder; the state machine is an independently running state machine containing the state nodes, corresponding to each of the orthogonal state dimensions. A state machine-driven dynamic form engine is built using the state machine, adapter interface, and view adapter.

2. The method for constructing a state machine-driven dynamic form engine according to claim 1, characterized in that, The configuration information of the state machine is defined using a declarative DSL and a preset parser.

3. The method for constructing a state machine-driven dynamic form engine according to claim 1, characterized in that, The adapter interface includes an event dispatcher interface, a subscriber interface, and a status reader interface.

4. The method for constructing a state machine-driven dynamic form engine according to claim 1, characterized in that, The definition includes the source state, triggering event, target state, guard conditions, and state transition rules for actions, and also includes: The guard condition is registered to the guard condition pool in the form of a first identifier, and the action is registered to the action pool in the form of a second identifier, so that the guard condition and the action can be referenced by the state transition rule; The guard condition is a function that takes the state context as input and a Boolean value as output; The actions include actions before state transition, actions after state transition, actions to exit the source state, and actions to enter the target state.

5. The method for constructing a state machine-driven dynamic form engine according to claim 1, characterized in that, The view adapters include a user interface framework adapter, a canvas rendering adapter, a command line output adapter, and a simulation adapter for automated testing.

6. An event handling method based on a dynamic form engine, characterized in that, Applied to a dynamic form engine; the dynamic form engine is an engine built based on the state machine-driven dynamic form engine construction method according to any one of claims 1 to 5; wherein, the event handling method includes: Receive target events related to the target dynamic form, parse the event type and target field of the target event, and query the target state transition rule in the state transition table based on the current state of the target field and the event type; Obtain the target guard condition in the target state transition rule. If the target guard condition determines that state transition is allowed based on the state context of the target field, then execute the target action in the target state transition rule and change the current state to the target state, so as to render the preset view layer by utilizing the state difference between the current state and the target state.

7. The event handling method based on a dynamic form engine according to claim 6, characterized in that, After changing the current state to the target state, the process further includes: Record the corresponding state change operation, generate a corresponding change snapshot based on the state change operation, and store the change snapshot in the history recorder of the dynamic form engine; the change snapshot is a snapshot including the data value of the target field, the target state node of the target field, and a copy of the target event.

8. A device for constructing a state machine-driven dynamic form engine, characterized in that, include: The node construction module is used to determine the fields in the dynamic form and construct state nodes based on the orthogonal state dimensions of the fields; The transition table construction module is used to define state transition rules that include source state, triggering event, target state, guard condition, and action, and to construct a state transition table based on the state transition rules; the guard condition is a function that determines whether a state transition is allowed; the action is a function that performs side effect operations related to the state transition. The state machine construction module is used to create a state context storage container, initialize a history recorder, and construct a state machine based on the state nodes, the state transition table, the state context storage container, and the history recorder; the state machine is an independently running state machine containing the state nodes, corresponding to each of the orthogonal state dimensions. The engine building module is used to build a state machine-driven dynamic form engine using the state machine, adapter interface, and view adapter.

9. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, Used to store a computer program; wherein, when the computer program is executed by a processor, it implements the method as described in any one of claims 1 to 7.

Images