A low-code platform form generation system supporting complex cascading relationships

Abstract

The application relates to the technical field of software development, and discloses a low-code platform form generation system supporting complex cascade relations, which comprises an analysis and detection module, a timing control module, a weight arbitration module and a difference rendering module. The analysis and detection module constructs a directed acyclic graph in a design state and performs topological sorting to complete static loop detection; the timing control module generates a life cycle token for field changes in a running state and registers the token to a global active state, while truncating a stock asynchronous request link; the weight arbitration module performs a depth-first traversal based on the acyclic graph, and performs multi-source state weight arbitration calculation on controlled fields by using a Boolean algebra model; and the difference rendering module calculates a difference mapping set of new and old virtual state trees, and then performs page local redrawing. The application effectively intercepts form nesting dead loops, blocks interference of expired asynchronous network data, eliminates multi-source rule state conflicts, and significantly improves the running stability and rendering performance of complex forms.

Description

Technical Field

[0001] This invention relates to the field of software development technology, specifically to a low-code platform form generation system that supports complex cascading relationships. Background Technology

[0002] With the evolution of software development models, low-code platforms have gained widespread adoption due to their ability to quickly build applications through visual configuration. Forms, as a core component for data collection and interaction within low-code platforms, directly determine the system's applicability to various business scenarios through their configuration capabilities. In real-world enterprise applications, forms typically contain numerous fields with complex inter-field relationships and cascading connections. This means that the visibility, required attributes, or data source of a form field needs to dynamically change based on the values ​​of one or more other fields.

[0003] Existing low-code platform form generation systems have significant limitations in handling such complex cascading relationships. During the form design and rule parsing phases, existing systems lack a global validation mechanism for dependencies between fields, making it easy for business users to create implicit closed-loop connections when configuring multi-level linkages. When this circular dependency is triggered in the system runtime, it can cause the engine to enter a recursive infinite loop, leading to front-end memory overflows and browser crashes. When handling asynchronous cascading involving external interface calls, existing systems lack effective timing control over network communication. When users perform frequent interactive operations, due to uncontrollable latency differences in network transmission, earlier asynchronous requests may arrive at the client later than later requests, causing older data to overwrite the latest state, resulting in serious component state corruption and dirty data issues.

[0004] Furthermore, when multiple rules converge within a form—that is, when a controlled field is simultaneously influenced by the logic of multiple different source fields—existing systems often lack standardized state calculation and conflict arbitration models. This can easily lead to frequent state transitions of UI components and distorted logical judgments. When implementing UI updates, traditional form rendering engines typically lack the ability to accurately track cascading changes, often triggering a full reload of the entire form interface when local data changes. This coarse update approach generates a large number of invalid underlying document object model operations, severely consuming system computing resources and causing noticeable lag and delays when users interact with long forms with complex cascading logic. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a low-code platform form generation system that supports complex cascading relationships. It solves the problems that existing low-code platform forms are prone to when handling complex nested cascading relationships, such as infinite loops of rule dependencies, disordered asynchronous data request timing, conflicts of multi-source logical states, and poor rendering performance caused by full page reload.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a low-code platform form generation system supporting complex cascading relationships, comprising: The parsing and detection module is used to extract the cascading rules between form fields in the system design state, construct a directed acyclic graph between form fields, perform topological sorting on the directed acyclic graph to complete static loop detection, and generate a standardized data structure after passing the static loop detection. The timing control module is used to intercept change events of form field values ​​in the system runtime state, generate lifecycle tokens for the change events and register them to the global active state, and update the lifecycle tokens in the global active state and cut off the existing asynchronous request links when concurrent change events occur. The weight arbitration module is used to respond to the change event, perform depth-first traversal calculation based on the directed acyclic graph, extract multiple input state instruction vectors when the traversal reaches the controlled form field, perform multi-source state weight arbitration calculation, and output the final state vector of the controlled form field. The differential rendering module is used to receive the final state vector and the asynchronous dataset verified by the timing control module, update the virtual state tree maintained in the system memory according to the received data, calculate the differential mapping set of the virtual state tree before and after the update, and perform a local redraw operation in the user interface according to the differential mapping set.

[0007] Preferably, the step of constructing a directed acyclic graph (DAG) between form fields and performing topological sorting on the DAG to complete static loop detection specifically includes: Instantiate form fields as vertices in a graph structure, and establish directed edges from the source field vertex to the target controlled field vertex according to conditional logic rules to generate an initial cascaded dependency graph; Traverse the initial cascaded dependency graph and count the in-degree of all vertices, then push vertices with an in-degree of zero into the processing queue. When the processing queue is not empty, a vertex is taken out from the processing queue and moved into the sorted sequence, all directed edges from the vertex are destroyed, the in-degree value of the target vertex pointed to by the destroyed edge is deducted simultaneously, and the new vertex with an in-degree value of zero is pushed into the processing queue until the processing queue is empty. Based on the comparison between the total number of vertices in the sorted sequence and the total number of fields in the form, it is determined whether there is a closed loop in the initial cascade dependency graph.

[0008] Preferably, the step of generating a lifecycle token for the change event and registering it to the globally active state specifically includes: Obtain the current millisecond-level timestamp of the system kernel and concatenate it with the identifier of the source field that generated the change event to form an initial string; The initial string is processed using a hash algorithm to calculate and output a hash value; The current millisecond-level timestamp is concatenated with the hash value to form a lifecycle token; An in-situ update strategy is adopted to write the lifecycle token into the global activation token register to overwrite the original record.

[0009] Preferably, updating the global activation token and truncating existing asynchronous request links when a concurrent change event occurs specifically includes: Filter existing asynchronous network requests that are currently in a suspended state and whose bound tokens are inconsistent with the newly registered global activation token; Send an interrupt signal to the selected existing asynchronous network requests to forcibly close the underlying transmission connection; The system receives an asynchronous response data packet containing a pass-through token from an external server system. If the pass-through token matches the current global activation token value, the system determines that the asynchronous dataset contained in the asynchronous response data packet has passed the verification and allows it to pass through the differential rendering module; otherwise, it performs a silent discard operation at the underlying level.

[0010] Preferably, the step of performing a depth-first traversal calculation based on the directed acyclic graph specifically includes: Extract the vertex identifier corresponding to the source field that generated the change event, use it as the root node of the traversal algorithm, and start the depth-first traversal operation to the controlled lower branch along the directed edge. Initialize the path memory set used to record the vertex identifiers traversed on a single depth-first traversal branch; Before accessing the new vertex corresponding to the next level of controlled form field, if the identifier of the new vertex already exists in the path memory set, an implicit loop logic is triggered, and a dynamic circuit breaker operation is performed to block the subsequent node tracing of the current calculation branch; if the identifier of the new vertex does not exist in the path memory set, the identifier of the new vertex is stored in the path memory set and access to the new vertex continues.

[0011] Preferably, the step of performing multi-source state weight arbitration calculation and outputting the final state vector of the controlled form field specifically includes: When the number of incoming edges pointing to the vertex corresponding to the controlled form field and in an active state is greater than one, the vertex is determined to be a multi-source control node; Tracing back each active incident edge, the input state command vector transmitted by the previous trigger node is extracted; the input state command vector includes visibility parameters, required parameters, and read-only parameters. Based on the established Boolean algebra model, logical operations are performed on the extracted multiple input state instruction vectors to obtain the final state vector containing visible state results, required state results, and read-only state results.

[0012] Preferably, the step of performing logical operations on the extracted multiple input state instruction vectors based on the set Boolean algebra model specifically includes: For the numerical calculation of the visibility dimension, the logical AND multiplication operation of the veto rule is performed. When the visibility parameter in any of the extracted input state instruction vectors requires the node to be hidden, the visibility state result of the controlled form field is forced to converge to hidden. For both mandatory and read-only status results, a one-vote approval rule is applied. When the mandatory parameter in any of the extracted input status instruction vectors requires a node to be mandatory, the mandatory status result of the controlled form field converges to mandatory. When the read-only parameter in any of the extracted input status instruction vectors requires a node to be read-only, the read-only status result of the controlled form field converges to read-only.

[0013] Preferably, updating the virtual state tree maintained in system memory based on the received data specifically includes: The virtual state tree currently maintained in system memory is cloned and backed up to an older version of the state tree; Extract the control parameters of each dimension from the final state vector, and write them together with the verified asynchronous dataset into the target node attribute data corresponding to the original virtual state tree to generate a new version of the state tree.

[0014] Preferably, the difference mapping set of the virtual state tree before and after the calculation update specifically includes: The node data of the old version state tree and the new version state tree are compared using a same-level traversal strategy; When a discrepancy is detected between the old version state tree and the new version state tree in the state parameter or asynchronous dataset of the target node, the unique identifier of the target node and the specific parameters that have changed are extracted and assembled and recorded into an independent data object. After completing the same-level traversal of the global tree structure, the independent data objects are used as the difference mapping set to record the changes in the nodes.

[0015] Preferably, the step of performing a local redraw operation in the user interface based on the difference mapping set specifically includes: Parse the difference mapping set and read the unique identifier of each record one by one; Based on the read unique identifier, an address matching is performed in the document object model tree of the front-end browser to uniquely locate the real component node that has caused the state change or data change. The specific parameters that have changed are unidirectionally overwritten into the native attribute data of the real component node, triggering the execution of the real component node's own lifecycle function to perform a partial redraw of the object model.

[0016] This invention provides a low-code platform form generation system that supports complex cascading relationships. It has the following beneficial effects: 1. This invention achieves static loop detection by constructing a directed acyclic graph between form fields in the system design phase and performing topological sorting. This is combined with dynamic circuit breaking judgment using a path memory set during depth-first traversal in the system runtime phase. This mechanism can intercept closed-loop logic in form cascading rules from both the design and runtime stages, preventing program infinite loops and memory overflows when processing complex nested rules, thus improving the overall stability of the form engine.

[0017] 2. This invention uses a timing control module to generate lifecycle tokens for field change events and registers them in a globally active state. When concurrent requests occur, it truncates old asynchronous request links and compares the transparent tokens in the response data packets. This design eliminates the impact of expired network responses on the current system state, solves the problem of asynchronous data overlap and timing discrepancies caused by network latency or high-frequency user input, and ensures the accuracy and consistency of the data presented in the form interface.

[0018] 3. This invention utilizes a weighted arbitration module and a Boolean algebra model to perform logical calculations on the input instructions of multi-source control nodes to output a final state vector. A difference rendering module then compares the old and new virtual state trees to generate a difference mapping set for local redrawing. This scheme clarifies the state attribution of the same form field when it is affected by multiple logical rules, eliminates multi-source state conflicts, and replaces global page reloading with local component updates based on difference comparison, reducing the resource overhead of underlying DOM operations and improving the page response speed of complex forms. Attached Figure Description

[0019] Figure 1 This is a system module architecture diagram of the present invention.

[0020] Among them, 100 is the parsing and detection module; 200 is the timing control module; 300 is the weight arbitration module; and 400 is the difference rendering module. Detailed Implementation

[0021] The technical solutions in 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.

[0022] Please see the appendix Figure 1 This invention provides a low-code platform form generation system that supports complex cascading relationships, comprising: The system includes a parsing and detection module 100, a timing control module 200, a weight arbitration module 300, and a difference rendering module 400.

[0023] The parsing and detection module 100 is configured to receive form view configuration data in the system design state and extract the cascading rules between form fields.

[0024] The parsing and detection module 100 constructs a directed acyclic graph between form fields based on the extracted cascading rules, and performs topological sorting on the directed acyclic graph to complete static loop detection.

[0025] After loop detection is performed on the graph structure, the parsing and detection module 100 generates a standardized data structure for runtime calls.

[0026] The timing control module 200 is configured to intercept change events of form field values ​​during system runtime.

[0027] The timing control module 200 generates a lifecycle token for a single change event and registers the lifecycle token to the global active state.

[0028] When a concurrent change event occurs, the timing control module 200 updates the global activation token and sends a signal to truncate the existing asynchronous request chain.

[0029] The weighted arbitration module 300 is configured to perform a depth-first traversal calculation based on the aforementioned directed acyclic graph in response to change events.

[0030] When the weighted arbitration module 300 reaches a controlled form field during traversal, it extracts multiple input state instruction vectors that act on the controlled form field.

[0031] The weight arbitration module 300 performs multi-source state weight arbitration calculation and outputs the final state vector after the controlled form field converges.

[0032] The differential rendering module 400 is configured to receive the final state vector output by the weight arbitration module 300 and the asynchronous dataset verified by the timing control module 200.

[0033] The differential rendering module 400 updates the virtual state tree maintained in the system memory based on the received data parameters.

[0034] The difference rendering module 400 calculates the difference mapping set of the virtual state tree before and after the update, and performs local redrawing operations in the user interface based on the difference mapping set.

[0035] The operation of the above system modules specifically includes the following steps: S10, within the system design state environment, the system obtains form view configuration information containing basic component information and cascading rules between fields through the front-end interactive interface; S20, the parsing and detection module 100 converts the received form view configuration information into structured data and establishes the relationship between vertices and directed edges to construct an initial cascade dependency graph; S30, the parsing and detection module 100 performs topology sequence stripping calculation on the established initial cascade dependency graph; S40, when the calculation results verify that there is no closed loop in the graph structure, the analytical detection module 100 completes the shaping of the directed acyclic graph and persistently stores it in the system memory; S50, after the system enters the runtime environment, the form interface receives external input operations and generates source field value change events; S60, the timing control module 200 intercepts the change event at the underlying level, generates a unique lifecycle token based on the system timestamp and random hash value, and performs the token activation and registration operation; S70, the weighted arbitration module 300 takes the source field that caused the change as the starting point of traversal and traces the controlled lower-level node branches along the directed acyclic graph in memory; S80, during the traversal of graph nodes, the weight arbitration module 300 records the access path through a set structure and performs dynamic circuit breaking judgment based on path comparison to avoid loop logic during runtime. S90, when the weight arbitration module 300 traverses to a multi-rule intersection node with multiple incident directed edges, it reads the state instructions passed by each trigger source; S100, the weighted arbitration module 300 uses the set Boolean algebra model to process the read state instruction set and calculate the absolute multidimensional state vector of the node. S110, if the cascading operation link involves remote asynchronous data acquisition, the timing control module 200 sends the currently generated lifecycle token to the external system in the network request context; S120, when receiving the response data packet and transparent token sent by the external server, the timing control module 200 performs a comparison and verification between the local activation token and the transparent token. S130, the timing control module 200 discards the data flow that fails the verification at the bottom layer, blocks the impact of expired data on the system state, and allows valid data that has been verified to be passed to the differential rendering module 400; S140, the differential rendering module 400 integrates the final state vector output by the weight arbitration module 300 with the valid data released by the timing control module 200, and updates the underlying state model data of the system. S150, the difference rendering module 400 performs data difference calculations on the state model before and after the update and extracts the set of node changes; S160, the differential rendering module 400 locates the user interface components that have generated state changes or data changes based on the extracted set of node changes and performs targeted rendering.

[0036] To further illustrate the generation and verification principles of the underlying graph structure, the parsing and detection module 100 is configured to receive form view configuration data in the system design state, extract the cascading rules between form fields, and perform data transformation and security graph structure construction. Its specific processing flow includes the following steps: S201, the parsing and detection module 100 receives the form view configuration data transmitted from the front-end interactive interface and performs parameter mapping operations to generate a standardized JSON data structure. Since the front-end form view configuration data typically contains basic descriptive attributes and conditional logic rules for form components, the parsing and detection module 100 extracts the component's unique identifier and maps it to node keys in the JSON data structure, and extracts the component's input constraint attributes and maps them to the node's data type definition. The parsing and detection module 100 reads the conditional logic rules, extracts the configured trigger conditions and execution actions within the rules, and maps them to an independently stored dependency array within the data structure. This achieves the separation of the view display model and the business logic model, reducing coupling for subsequent calculations.

[0037] S202, the parsing and detection module 100 reads and parses the extracted dependency array, abstracting the form fields and the cascading rules between fields to construct an initial cascading dependency graph. The parsing and detection module 100 instantiates each field node in the JSON data structure as a vertex in the graph structure. Let the set of form field vertices be... The parsing and detection module iterates through the dependency array 100 times, and when it identifies a conditional logic rule setting field... Numerical or status change trigger field When the state changes, a path is created in the graph structure from... point to The directed edges. Let all extracted directed edges form a set. This generates the initial cascading dependency graph: ; In the formula, For the set of vertex fields of the form; , , For specific form field vertices; This represents the total number of fields in the form, and its value range is a natural number greater than or equal to 1. The vertex of the triggering field that produces the change; The target controlled field vertex is controlled by the trigger source; The set of directed edges formed by mapping all cascading rules; This is the initial cascading dependency graph to be constructed.

[0038] S203, the parsing and detection module 100 performs topology sequence stripping calculations on the initial cascaded dependency graph to complete static loop detection. The parsing and detection module 100 traverses the initial cascaded dependency graph and counts the sets. The parsing and detection module 100 calculates the in-degree value of all vertices in the array and pushes vertices with an in-degree value of zero into the processing queue. When the processing queue is not empty, the parsing and detection module 100 removes vertices from the processing queue and moves them into the sorted sequence, simultaneously destroying all directed edges originating from that vertex in memory. The parsing and detection module 100 then deducts the in-degree value of the target vertex pointed to by the destroyed edges and pushes the new vertex with an in-degree value of zero into the processing queue. The parsing and detection module 100 repeatedly performs the stripping and deduction operations until the processing queue is empty.

[0039] S204, the parsing and detection module 100 performs design-state logic closed-loop interception or security graph structure determination based on the statistical results of the sorted sequence. Let the total number of vertices stripped and recorded in the sorted sequence be... The analysis and detection module performs a 100-fold comparison. Total number of fields in the form The value. When it exists In the event of a loop, the parsing and detection module 100 determines that the initial cascaded dependency graph contains a closed loop caused by a circular dependency. The parsing and detection module 100 sends an exception interception command to the front-end system to interrupt the form saving action, extracts the set of residual vertices that were not successfully stripped from the graph structure as conflict node identifiers, and returns them to the front-end interface. When a loop exists... In the event of a closed loop, the parsing and detection module 100 determines that there is no closed loop in the initial cascaded dependency graph, completes the construction and shaping of the directed acyclic graph, and converts the shaped directed acyclic graph into persistent data stored in the system memory.

[0040] For the serialization and deserialization of JSON data structures, as well as the physical storage form of the adjacency matrix or adjacency list data of graph structures in system memory, those skilled in the art can directly call the standard function library interface of a general programming language. The specific encoding logic and implementation method are well-known technologies in this field and will not be elaborated here.

[0041] Considering the prevalent data transmission delays in real-world network environments, the timing control module 200 is configured to manage and control the timing of form data flow and network communication during system runtime. Its specific processing flow includes the following steps: S205, the timing control module 200 monitors user interactions on the form interface during system runtime. When the form interface receives an interaction such as text input or dropdown option switching, the input component triggers a value change event at the underlying level. The timing control module 200 captures this change event, extracts the identifier of the form component that caused the value change, and checks whether the component exists in the directed acyclic graph node maintained in memory. If the check confirms its existence, the timing control module 200 identifies the component as the source field that causes cascading effects and initiates the pipeline control flow for this change event.

[0042] S206, the timing control module 200 generates a globally unique lifecycle token for this change event. As a preferred calculation method to ensure absolute collision prevention of the token, the timing control module 200 obtains the current millisecond-level timestamp of the system kernel and concatenates it with the extracted source field identifier to form an initial string. The timing control module processes this initial string using a standard hash algorithm such as SHA-256 to calculate and output a fixed-length hash value. The timing control module 200 concatenates the timestamp and the hash value to form a lifecycle token, and then writes the lifecycle token into the global activation token register in system memory. This write operation uses an in-situ update strategy to overwrite the original record and sets the newly generated lifecycle token as the current globally active state.

[0043] S207, the timing control module 200 performs blocking operations on existing network requests in high-frequency concurrent triggering scenarios. After the lifecycle token completes global activation registration, the timing control module 200 queries the asynchronous request pool maintained in the underlying network communication components of the system. The timing control module 200 filters existing asynchronous network requests that are currently in a suspended state and whose bound tokens are inconsistent with the newly registered global activation token. The timing control module 200 sends an interrupt signal to the filtered existing asynchronous network requests, forcibly closing the underlying transmission connection and canceling the data waiting and reception of suspended network requests, thereby achieving forced alignment in the time dimension and releasing system network transmission resources in advance.

[0044] S208, When the cascading logic involves cross-system data acquisition, the timing control module 200 constructs a network request message. The timing control module 200 reads the active lifecycle token from the global activation token register, injects it as a custom control parameter into the request header structure of the network request message, and then sends the request message to the external server system through the underlying network interface.

[0045] S209, the timing control module 200 receives an asynchronous response data packet from an external server system. The asynchronous response data packet contains the business data payload and the lifecycle token returned by the server as is. The timing control module 200 parses the data packet to extract the pass-through token, synchronously reads the currently stored global activation token in the global activation token register, and performs Boolean discrimination logic to calculate and compare the two.

[0046] S210, the timing control module 200 performs data differentiation processing based on the result of the Boolean discrimination logic. When the values ​​of the pass-through token and the global activation token are completely consistent, the Boolean discrimination logic returns a true value, and the timing control module 200 determines that the current business data payload is valid data in response to the latest interaction, allowing it to pass and transmit it to the next-level rendering link. When the values ​​of the pass-through token and the global activation token differ, the Boolean discrimination logic returns a false value, and the timing control module 200 determines that the current business data payload is expired dirty data left over from historical concurrent operations. The timing control module 200 performs a silent discard operation at the underlying level, directly destroying the memory allocation corresponding to the business data payload, and does not send any state update instructions to the upper-level view model, thereby preventing component state overlay errors caused by network latency.

[0047] The hash algorithm calculation process for the initial string and the specific interface call method of the underlying interrupt signal controller for network requests can be directly implemented by those skilled in the art using standard encryption function libraries and the underlying specifications of the Hypertext Transfer Protocol. The underlying network and encryption operations are well-known technologies in this field and will not be elaborated here.

[0048] To resolve the state conflict issue among multiple control nodes during runtime, the weighted arbitration module 300 is configured to perform the traversal of controlled nodes and the adjudication calculation of multi-source conflict states during system runtime. Its specific processing flow includes the following steps: S211, the weight arbitration module 300 receives the source field change signal transmitted by the timing control module 200 and extracts the vertex identifier in the directed acyclic graph corresponding to the source field. The weight arbitration module 300 uses this vertex as the root node of the traversal algorithm and, based on the directed acyclic graph data structure persistently stored in memory, starts a depth-first traversal operation towards the controlled lower-level branches along the directed edge pointers.

[0049] S212, the weight arbitration module 300 initializes the path memory set in the execution context of the traversal operation. The path memory set is a memory object that stores traversal history nodes and is used to record the vertex identifiers traversed on a single depth-first traversal branch. When traversal starts, the weight arbitration module 300 writes the vertex identifiers of the source field into this path memory set.

[0050] S213, before the weight arbitration module 300 prepares to access the new vertex corresponding to the next level controlled form field based on the directed edge, it extracts the identifier of the new vertex and compares it with the existing data in the path memory set. If the identifier of the new vertex already exists in the path memory set, the weight arbitration module 300 determines that the current calculation branch has triggered implicit loop logic caused by dynamic data in the running state, and then executes a dynamic circuit breaker operation. The dynamic circuit breaker operation manifests as the underlying engine abandoning access to the new vertex, immediately blocking the subsequent node tracing of the calculation branch, and forcing the system to release the stack space of the current traversal depth to avoid the risk of memory overflow. If the identifier of the new vertex does not exist in the path memory set, the weight arbitration module 300 appends the identifier of the new vertex to the path memory set and normally enters the access execution logic of the vertex.

[0051] S214, when the weighted arbitration module 300 traverses to a vertex of a controlled form field, it counts the number of incoming edges pointing to that vertex and currently in an active state. If the number of incoming edges is greater than one, the weighted arbitration module 300 determines that the vertex is a multi-source control node with multiple logical rules intersecting. The weighted arbitration module 300 traces back each active incoming edge, extracting the input state instruction vector passed from the next higher-level triggering node. The input state instruction vector contains three independent control parameters: parameters specifying whether the node is visible, whether it is required, and whether it is read-only.

[0052] S215, the weighted arbitration module 300 substitutes the extracted multiple input state instruction vectors into the underlying Boolean algebra model to perform calculations, thereby solving for the final state vector of the multi-source control node. The final state vector includes the calculated visibility state results, required state results, and read-only state results.

[0053] In general technical principles, the hidden attribute of form fields has the highest security level. For the numerical calculation of the visibility dimension, the weight arbitration module 300 performs a logical AND multiplication operation based on a veto rule. It is set that if any extracted input state instruction vector requires a node to be hidden, then the final visibility state of that node is forcibly converged to hidden. The visibility calculation formula is expressed as: ; In the formula, This represents the final convergence visibility state result for the controlled form field; The total number of incident edges pointing to this multi-source control node and in an active state, its value range is: 0 natural numbers; The index number is used to traverse and extract the input state instruction vector; For the first The visibility control parameters contained in each input state instruction vector have a valid value range of Boolean constant space, where a value of 0 represents hidden and a value of 1 represents visible.

[0054] For the numerical calculation of the required and read-only dimensions, the weight arbitration module 300 performs a one-vote-for-the-right transformation. It is set that if any extracted input state instruction vector requires a node to be either required or read-only, then the final corresponding state of that node converges to either required or read-only. The formulas for calculating the required and read-only states are expressed as follows: ; ; In the formula, This represents the final convergence of the required field status of the controlled form. This represents the read-only state result of the final convergence of the controlled form field; This represents the total number of incident edges pointing to the multi-source control node and in an active state. The index number is used to traverse and extract the input state instruction vector; For the first The input state instruction vector contains mandatory control parameters, where a value of 0 represents a non-mandatory parameter and a value of 1 represents a mandatory parameter. For the first The read-only control parameter contained in each input state instruction vector has a value of 0 indicating editability and a value of 1 indicating read-only.

[0055] For the recursive stack structure allocation and memory maintenance mechanism called at the computer's underlying level for depth-first traversal, those skilled in the art can implement it using standard stack object components of conventional high-level programming languages. The traversal addressing technology of graph structures is a well-known technology in this field and will not be elaborated here.

[0056] The differential rendering module 400 is configured to perform user interface data synchronization and security view updates after completing the underlying data calculations in the system runtime. Its specific processing flow includes the following steps: S216, the differential rendering module 400 receives the final state vector calculated and output by the weight arbitration module 300, and synchronously receives the valid asynchronous dataset released by the timing control module 200 after timing comparison and verification. A virtual state tree is maintained in system memory to map the hierarchical relationships of the current user interface. Before implementing data writing updates, the differential rendering module 400 clones and backs up the virtual state tree in memory, retaining it as the old version of the state tree. Subsequently, the differential rendering module 400 extracts the visibility parameters, required parameters, and read-only parameters from the final state vector, and writes them together with the valid asynchronous dataset into the target node attribute data corresponding to the original virtual state tree, thereby generating a new version of the state tree after data merging and writing.

[0057] S217, the difference rendering module 400 performs a difference comparison calculation between the retained old version of the state tree and the generated new version of the state tree. To improve comparison efficiency, the difference rendering module 400 uses a same-level traversal strategy to compare the node data of the two state trees. During the traversal comparison process, the difference rendering module 400 reads the unique identifier and attribute key-value pair set of the same-level nodes. When it is found that the state parameters of the target node or the attached asynchronous dataset has a numerical inconsistency between the two state trees, the difference rendering module 400 extracts the unique identifier of the target node and the specific parameters that have changed, and assembles and records them into an independent data object. After completing the same-level traversal of the global tree structure, this independent data object constitutes the difference mapping set that records the precise changes in the nodes.

[0058] In S218, the differential rendering module 400 drives the underlying rendering engine to perform targeted updates at the user interface level based on the extracted differential mapping set. The underlying rendering engine parses the differential mapping set, reading the unique identifier of each internal record. Based on this unique identifier, the underlying rendering engine performs address matching in the document object model tree of the front-end browser, uniquely locating the actual component node that has undergone state or data changes. The underlying rendering engine unilaterally overwrites the specific parameters of the changes into the native property configuration of the actual component node, triggering the lifecycle function of the local component itself to perform object model redraw. This redraw operation is only performed on the located local actual component node. The system avoids the structural overload of the global form interface through a physical isolation mechanism, thereby completing the closed loop of view display for safe changes in form cascading states.

[0059] The object cloning algorithm of the virtual state tree in system memory, and the specific application interface call mechanism for the underlying rendering engine to operate the browser document object model node attributes, can be directly implemented by those skilled in the art using the standard difference comparison function library of the existing front-end view framework. The underlying node traversal rules and attribute overriding logic are well-known technologies in the field and will not be elaborated here.

Claims

1. A low-code platform form generation system supporting complex cascading relationships, characterized in that, include: The parsing and detection module (100) is used to extract the cascading rules between form fields in the system design state, construct a directed acyclic graph between form fields, perform topological sorting on the directed acyclic graph to complete static loop detection, and generate a standardized data structure after passing the static loop detection. The timing control module (200) is used to intercept change events of form field values ​​in the system running state, generate lifecycle tokens for the change events and register them to the global active state, and update the lifecycle tokens in the global active state and cut off the existing asynchronous request links when concurrent change events occur. The weight arbitration module (300) is used to respond to the change event, perform depth-first traversal calculation based on the directed acyclic graph, extract multiple input state instruction vectors when the traversal reaches the controlled form field, perform multi-source state weight arbitration calculation, and output the final state vector of the controlled form field. The differential rendering module (400) is used to receive the final state vector and the asynchronous dataset verified by the timing control module (200), update the virtual state tree maintained in the system memory according to the received data, calculate the differential mapping set of the virtual state tree before and after the update, and perform a local redraw operation in the user interface according to the differential mapping set.

2. The low-code platform form generation system supporting complex cascading relationships according to claim 1, characterized in that, The process of constructing a directed acyclic graph (DAG) between form fields and performing topological sorting on the DAG to complete static loop detection specifically includes: Instantiate form fields as vertices in a graph structure, and establish directed edges from the source field vertex to the target controlled field vertex according to conditional logic rules to generate an initial cascaded dependency graph; Traverse the initial cascaded dependency graph and count the in-degree of all vertices, then push vertices with an in-degree of zero into the processing queue. When the processing queue is not empty, a vertex is taken out from the processing queue and moved into the sorted sequence, all directed edges from the vertex are destroyed, the in-degree value of the target vertex pointed to by the destroyed edge is deducted simultaneously, and the new vertex with an in-degree value of zero is pushed into the processing queue until the processing queue is empty. Based on the comparison between the total number of vertices in the sorted sequence and the total number of fields in the form, it is determined whether there is a closed loop in the initial cascade dependency graph.

3. A low-code platform form generation system supporting complex cascading relationships according to claim 1, characterized in that, The process of generating a lifecycle token for the change event and registering it to the globally active state specifically includes: Obtain the current millisecond-level timestamp of the system kernel and concatenate it with the identifier of the source field that generated the change event to form an initial string; The initial string is processed using a hash algorithm to calculate and output a hash value; The current millisecond-level timestamp is concatenated with the hash value to form a lifecycle token; An in-situ update strategy is adopted to write the lifecycle token into the global activation token register to overwrite the original record.

4. A low-code platform form generation system supporting complex cascading relationships according to claim 1, characterized in that, The step of updating the global activation token and truncating the existing asynchronous request chain when a concurrent change event occurs specifically includes: Filter existing asynchronous network requests that are currently in a suspended state and whose bound tokens are inconsistent with the newly registered global activation token; Send an interrupt signal to the selected existing asynchronous network requests to forcibly close the underlying transmission connection; The system receives an asynchronous response data packet containing a pass-through token from an external server system. When the pass-through token matches the current global activation token value, the system determines that the asynchronous dataset contained in the asynchronous response data packet has passed the verification and allows it to pass through the differential rendering module (400); otherwise, it performs a silent discard operation at the underlying level.

5. A low-code platform form generation system supporting complex cascading relationships according to claim 1, characterized in that, The process of performing a depth-first traversal calculation based on the directed acyclic graph specifically includes: Extract the vertex identifier corresponding to the source field that generated the change event, use it as the root node of the traversal algorithm, and start the depth-first traversal operation to the controlled lower branch along the directed edge. Initialize the path memory set used to record the vertex identifiers traversed on a single depth-first traversal branch; Before accessing the new vertex corresponding to the next level of controlled form field, if the identifier of the new vertex already exists in the path memory set, an implicit loop logic is triggered, and a dynamic circuit breaker operation is performed to block the subsequent node tracing of the current calculation branch; if the identifier of the new vertex does not exist in the path memory set, the identifier of the new vertex is stored in the path memory set and access to the new vertex continues.

6. A low-code platform form generation system supporting complex cascading relationships according to claim 1, characterized in that, The step of performing multi-source state weight arbitration calculation and outputting the final state vector of the controlled form field specifically includes: When the number of incoming edges pointing to the vertex corresponding to the controlled form field and in an active state is greater than one, the vertex is determined to be a multi-source control node; Tracing back each active incident edge, the input state command vector transmitted by the previous trigger node is extracted; the input state command vector includes visibility parameters, required parameters, and read-only parameters. Based on the established Boolean algebra model, logical operations are performed on the extracted multiple input state instruction vectors to obtain the final state vector containing visible state results, required state results, and read-only state results.

7. A low-code platform form generation system supporting complex cascading relationships according to claim 6, characterized in that, The logical operations performed on the extracted input state instruction vectors based on the established Boolean algebra model specifically include: For the numerical calculation of the visibility dimension, the logical AND multiplication operation of the veto rule is performed. When the visibility parameter in any of the extracted input state instruction vectors requires the node to be hidden, the visibility state result of the controlled form field is forced to converge to hidden. For both mandatory and read-only status results, a one-vote approval rule is applied. When the mandatory parameter in any of the extracted input status instruction vectors requires a node to be mandatory, the mandatory status result of the controlled form field converges to mandatory. When the read-only parameter in any of the extracted input status instruction vectors requires a node to be read-only, the read-only status result of the controlled form field converges to read-only.

8. A low-code platform form generation system supporting complex cascading relationships according to claim 1, characterized in that, The step of updating the virtual state tree maintained in system memory based on the received data specifically includes: The virtual state tree currently maintained in system memory is cloned and backed up to an older version of the state tree; Extract the control parameters of each dimension from the final state vector, and write them together with the verified asynchronous dataset into the target node attribute data corresponding to the original virtual state tree to generate a new version of the state tree.

9. A low-code platform form generation system supporting complex cascading relationships according to claim 8, characterized in that, The difference mapping set of the virtual state tree before and after the calculation update specifically includes: The node data of the old version state tree and the new version state tree are compared using a same-level traversal strategy; When a discrepancy is detected between the old version state tree and the new version state tree in the state parameter or asynchronous dataset of the target node, the unique identifier of the target node and the specific parameters that have changed are extracted and assembled and recorded into an independent data object. After completing the same-level traversal of the global tree structure, the independent data objects are used as the difference mapping set to record the changes in the nodes.

10. A low-code platform form generation system supporting complex cascading relationships according to claim 9, characterized in that, The step of performing a local redraw operation in the user interface based on the difference mapping set specifically includes: Parse the difference mapping set and read the unique identifier of each record one by one; Based on the read unique identifier, an address matching is performed in the document object model tree of the front-end browser to uniquely locate the real component node that has caused the state change or data change. The specific parameters that have changed are unidirectionally overwritten into the native attribute data of the real component node, triggering the execution of the real component node's own lifecycle function to perform a partial redraw of the object model.

Images