Offline form data dynamic verification method and system

Abstract

The present application provides an offline form data dynamic verification method and system, which relates to the field of data verification technology, including: defining a verification rule file; generating an abstract syntax tree; traversing the abstract syntax tree to generate a logic rule tree; dynamically loading the logic rule tree into a target lightweight application in JSON format; receiving the form data to be verified and passing it into the target lightweight application; connecting the target lightweight application to receive verification feedback information; extracting the root node verification result based on the verification feedback information, if the root node verification result is true, the verification fails, otherwise, it passes. The present application can solve the technical problems in the prior art of high server load and large network delay due to poor flexibility of form data verification, realize flexible and efficient dynamic verification of form data, reduce server load, and improve the response speed and verification accuracy of the application.

Description

Technical Field

[0001] The present application relates to the technical field of data verification, and in particular to an offline form data dynamic verification method and system. Background Art

[0002] Currently, in lightweight applications, form data is usually verified in two ways: one is to use hard-coded verification rules, which requires the application to be republished every time the rules are modified; the other is to verify the form data through the server, and send the data to the back-end server for processing every time the form is submitted.

[0003] However, both methods have certain limitations. The hard-coding method is not flexible enough and increases maintenance costs, while the server-side verification method will put a lot of pressure on the server when there are a large number of users, affecting system performance. Summary of the invention

[0004] The purpose of this application is to provide an offline form data dynamic verification method and system to solve the technical problems of poor flexibility of form data verification, high server load and large network delay in the prior art.

[0005] In view of the above problems, the present application provides an offline form data dynamic verification method and system.

[0006] In a first aspect, the present application provides an offline form data dynamic verification method, which is implemented by an offline form data dynamic verification system, wherein the offline form data dynamic verification method includes: defining a verification rule file; calling a syntax parser to perform rule parsing on the verification rule file to generate an abstract syntax tree; traversing the abstract syntax tree to generate a logical rule tree; dynamically loading the logical rule tree into a target lightweight application in JSON format; receiving the form data to be verified and passing it to the target lightweight application; connecting to the target lightweight application and receiving verification feedback information, wherein the verification feedback information is a node verification result obtained by the target lightweight application performing data verification according to the form data to be verified; extracting a root node verification result based on the verification feedback information, if the root node verification result is true, the verification fails, otherwise, it passes.

[0007] In the second aspect, the present application also provides an offline form data dynamic verification system, which is used to execute an offline form data dynamic verification method as described in the first aspect, wherein the offline form data dynamic verification system includes: a rule definition module, which is used to define a verification rule file; a rule parsing module, which is used to call a syntax parser to perform rule parsing on the verification rule file and generate an abstract syntax tree; a logical rule generation module, which is used to traverse the abstract syntax tree and generate a logical rule tree; a rule tree loading module, which is used to dynamically load the logical rule tree into a target lightweight application in JSON format; a form data receiving module, which is used to receive the form data to be verified and pass it to the target lightweight application; a node verification module, which is used to connect to the target lightweight application and receive verification feedback information, wherein the verification feedback information is a node verification result obtained by the target lightweight application performing data verification according to the form data to be verified; a root node verification analysis module, which is used to extract the root node verification result based on the verification feedback information, if the root node verification result is true, the verification fails, otherwise, it passes.

[0008] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0009] Define a verification rule file; call a syntax parser to perform rule parsing on the verification rule file and generate an abstract syntax tree; traverse the abstract syntax tree to generate a logic rule tree; dynamically load the logic rule tree into a target lightweight application in JSON format; receive the form data to be verified and pass it into the target lightweight application; connect the target lightweight application and receive verification feedback information, wherein the verification feedback information is a node verification result obtained by the target lightweight application performing data verification according to the form data to be verified; extract the root node verification result based on the verification feedback information, if the root node verification result is true, the verification fails, otherwise, it passes. This application can solve the technical problems in the prior art that the server load is high and the network delay is large due to the poor flexibility of form data verification. By defining a verification rule file, generating a logic rule tree, and loading it into the target lightweight application to perform data verification, flexible and efficient dynamic verification of form data is achieved, server load is reduced, and the response speed and verification accuracy of the application are improved.

[0010] The above description is only an overview of the technical solution of the present application. In order to more clearly understand the technical means of the present application, it can be implemented according to the contents of the specification, and in order to make the above and other purposes, features and advantages of the present application more obvious and easy to understand, the specific implementation methods of the present application are specifically cited below. It should be understood that the content described in this section is not intended to identify the key or important features of the embodiments of the present application, nor is it intended to limit the scope of the present application. Other features of the present application will become easy to understand through the following description. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the technical solutions in the present application or the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings in the following description are only exemplary, and for ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying any creative work.

[0012] Figure 1 This is a flowchart of an offline form data dynamic verification method for this application;

[0013] Figure 2 This is a structural diagram of an offline form data dynamic verification system for this application.

[0014] Description of reference numerals:

[0015] A rule definition module 11, a rule parsing module 12, a logic rule generation module 13, a rule tree loading module 14, a form data receiving module 15, a node verification module 16, and a root node verification analysis module 17. DETAILED DESCRIPTION

[0016] The present application provides an offline form data dynamic verification method and system, which solves the technical problem in the prior art that the poor flexibility of form data verification leads to high server load and large network delay. The present application can solve the technical problem in the prior art that the poor flexibility of form data verification leads to high server load and large network delay. By defining a verification rule file, generating a logical rule tree, and loading it into a target lightweight application to perform data verification, a flexible and efficient dynamic verification of form data is achieved, which reduces the server load and improves the response speed of the application and the verification accuracy.

[0017] Below, the technical solutions in the present application will be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all of the embodiments of the present application. It should be understood that the present application is not limited to the example embodiments described herein. Based on the embodiments of the present application, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present application. It should also be noted that, for the convenience of description, only the parts related to the present application are shown in the accompanying drawings, rather than all of them.

[0018] For example, please refer to the attached Figure 1 The present application provides an offline form data dynamic verification method, wherein the offline form data dynamic verification method is applied to an offline form data dynamic verification system, and the offline form data dynamic verification method specifically includes the following steps:

[0019] Step 1: Define the verification rule file.

[0020] Specifically, the definition of the validation rule file is the basic step in the entire form data validation process, and contains specific rules for how to validate the data. The validation rules in the validation rule file are written in a structured form so that they can be recognized and executed by the parser later. The validation rule file usually uses logical expressions to define data validation logic. For example, the comparison operation expression is used to compare a field value in the form data with the expected value. For example, a=1 and b=2. By defining the validation rules, a validation rule file, such as a DSL file, is formed.

[0021] Step 2: Calling a syntax parser to parse the verification rule file and generate an abstract syntax tree.

[0022] Specifically, calling a syntax parser to parse the validation rule file means parsing the logical rules in the validation rule file into a structure that the computer can understand and execute to form an abstract syntax tree. First, the validation rule file is defined in the form of SQL syntax, which contains a variety of logical operations and conditional judgments. In order for the computer to understand these rules, it is first necessary to use a syntax parsing tool (such as Antlr4) to parse the rule file. The function of the syntax parser is to convert complex text (rule file) into a hierarchical structure called an abstract syntax tree. The syntax parser parses the validation rule file, reads the content of the file line by line, and breaks it into smaller logical units, such as conditional expressions, logical operators, fields, etc., and gradually builds an abstract syntax tree. The abstract syntax tree is a tree structure in which each node represents an element in the syntax (for example, an operator, a conditional expression, a function call, etc.). Through this structure, the computer can easily traverse and process the entire rule file.

[0023] Step 3: traverse the abstract syntax tree to generate a logic rule tree.

[0024] Specifically, the abstract syntax tree is a grammatical structure derived from the validation rule file, which represents the hierarchical information after syntax parsing. The logic rule tree is a further processing of the abstract syntax tree to form a logical structure that is more suitable for data validation. In the abstract syntax tree generated by the syntax parser, each node of the tree represents an operator or expression. In order to further process these nodes, the tree is traversed. The traversal method is usually depth-first traversal, which first visits the root node of the tree and then recursively processes each child node. Depth-first traversal means that the deepest node of the tree is visited first, and then returns to the upper node. In this way, it can be ensured that each condition or logical expression is processed. For example, when traversing to an AND node, the conditional expressions in all child nodes will be processed first. When traversing the abstract syntax tree, different types of nodes need to be classified and processed. Generally speaking, the nodes of the abstract syntax tree are divided into two categories: conditional nodes and logical operation nodes. The conditional node is a leaf node that represents a specific conditional judgment. The logical operation node is a non-leaf node that connects multiple conditions or sub-operations.

[0025] In the process of traversing the abstract syntax tree, a corresponding logic rule tree node is generated according to the type of each node (such as AND, OR or conditional expression). Each logic rule tree node has multiple attributes, including node type, field name of the conditional node, operator, field value, etc. Exemplarily, for an AND node, the logic rule tree will create a new AND type node, whose child nodes are all conditional nodes participating in the AND operation.

[0026] Step 4: Dynamically load the logic rule tree into the target lightweight application in JSON format.

[0027] Step 5: Receive the form data to be verified and transfer it to the target lightweight application.

[0028] Step 6: Connect to the target lightweight application and receive verification feedback information, wherein the verification feedback information is a node verification result obtained by the target lightweight application performing data verification based on the form data to be verified.

[0029] Specifically, after the logical rule tree is generated, it needs to be passed to the lightweight application in an appropriate format. The JSON format is used here because JSON is a lightweight data exchange format that is easy to transmit on the network and is supported by most programming languages. Dynamic loading refers to loading data or rules from external files or sources into the program when the program is running, rather than statically defining them at compile time.

[0030] When a user fills out a form in a lightweight application (such as a mini-program), the form data is collected in real time. Then, the form data to be verified is passed to the target lightweight application together with the previously loaded logical rule tree to start the verification. After the form data is passed to the application and compared with the logical rule tree, the verification of each node is performed step by step. Whenever the condition of a node is met or not met, verification feedback information is generated. This feedback information tells us the verification result of each node, and finally generates the verification result of the entire rule tree.

[0031] Step 7: Extract the root node verification result based on the verification feedback information. If the root node verification result is true, the verification fails; otherwise, the verification passes.

[0032] Specifically, extracting the root node verification result based on the verification feedback information is the last step of the form data verification, which determines whether the entire form passes the verification. In the logical rule tree structure, the root node is the highest level of the tree, usually a logical operation node (such as AND or OR), connecting all the conditional nodes. By extracting the verification result of the root node, the system can determine whether the entire rule verification passes. After the verification process is completed, the lightweight application generates the verification results of each node, and these results are summarized into verification feedback information. Finally, the result of the entire verification is determined based on the root node in the logical rule tree. The result of the root node determines the verification status of the entire form. For example: for the AND node, when the verification results of all child nodes are true, the root node returns true. For the OR node, as long as the verification result of one child node is true, the root node returns true.

[0033] If the verification result of the root node is true, the form verification fails; if it is false, the verification passes. This reverse logic is because when the root node is true, it means that at least one condition is not met, resulting in verification failure.

[0034] Furthermore, step one of this application includes:

[0035] The verification rule file writes the verification rules in SQL syntax, and the logical expressions of the verification rules include comparison operation expressions, interval operation expressions, non-interval operation expressions, in-list expressions, non-in-list expressions, pattern matching expressions, non-pattern matching expressions, empty expressions, non-empty expressions, bracket expressions, and expressions, and or expressions.

[0036] Specifically, the writing of validation rule files is the basis of form validation. Its rules use SQL syntax, which makes the rules easy to understand and expand. The logical expressions in the validation rule files verify the form data in a variety of ways, including a variety of different types of expressions, which are used to handle different validation requirements. Through these expressions, it is possible to check whether the data in the form fields meets expectations.

[0037] Comparison operator expressions are the most basic expressions, which are used to compare the value of a form field with a specified target value. The format is: expr comparisonOperator expr; interval operator expressions are used to check whether a field value is within a certain range. The format is: expr BETWEEN expr AND expr; non-interval operator expressions indicate that the value is not within a certain range. The format is: expr NOT BETWEEN expr AND expr; in-list expressions are used to determine whether a field value belongs to a predefined list. The format is: expr IN '(' expr (',' expr)* ')'; non-in-list expressions indicate that a field value cannot be in a certain list. The format is: expr NOT IN '(' expr (',' expr)* ')'; pattern matching expressions are used to check whether a field value conforms to a certain pattern. The format is: expr LIKE expr; non-pattern matching expressions indicate that a field value does not conform to a certain pattern. The format is: expr NOT LIKE expr; null expressions are used to check whether a field is null. The format is: expr IS NULL; non-null expressions indicate that a field cannot be null. The format is: expr IS NOT NULL; Bracket expressions are used to clarify the priority of expressions and process certain logical operations together. Brackets can help the system correctly parse complex logic in the form of leftBracket='(' logicExpression rightBracket=')'; and expression (AND expression), in the form of logicExpression logicalOperator=AND logicExpression; or expression (OR expression), in the form of logicExpression logicalOperator=OR logicExpression.

[0038] Among them, the comparisonOperator in the comparison operation expression, that is, the comparison operator, includes equal to (=), greater than (>), less than (<), greater than or equal to (>=), less than or equal to (<=), and not equal to (<>).

[0039] Furthermore, the present application also includes:

[0040] The form of the logical expression includes field name, function call, constant value, multiplication and division expression, addition and subtraction expression, string connection expression and bracket expression; the logical expression satisfies the preset priority constraint.

[0041] Specifically, there are seven forms of logical expressions, and the priority order, i.e., the preset priority constraints, are as follows: field name, which can be in the form of field name or table name.field name; function call; constant value, which can be a number or a string; multiplication and division expression, in the form of expr ('*'|' / ') expr; addition and subtraction expression, in the form of expr ('+'|'-') expr; string concatenation expression, in the form of expr ('||') expr; bracket expression, in the form of '(' expr ')'.

[0042] Furthermore, the present application also includes:

[0043] The function call forms include average aggregation function, maximum aggregation function, minimum aggregation function, total aggregation function, ordinary function and CAST function.

[0044] Specifically, there are 6 forms of function calls, and the priority order is as follows: average aggregation function, in the form of AVG '('functionArg ')'; maximum aggregation function, in the form of MAX '(' functionArg ')'; minimum aggregation function, in the form of MIN '(' functionArg ')'; total aggregation function, in the form of SUM '(' functionArg ')'; ordinary function, in the form of functionName '(' functionArg ')'; CAST function, in the form of CAST '('functionArg AS typeName ')'; where the function parameter functionArg consists of any multiple expressions separated by commas, in the form of expr (',' expr)*; the name of the ordinary function functionName is a string starting with a letter or Chinese character.

[0045] Further, step three of this application includes:

[0046] Classify the logical expressions of the verification rules to generate conditional expressions and logical operation expressions; use the visitor pattern to traverse the abstract syntax tree, identify the conditional expressions and the logical operation expressions, and generate conditional nodes and logical operation nodes; wherein any node in the conditional node and the logical operation node has any number of child nodes; the logical operation node includes a first logical operation node and a second logical operation node; the first logical operation node is a node corresponding to an and expression, and the second logical operation node is a node corresponding to an or expression; establish the logical rule tree with the conditional nodes and the logical operation nodes.

[0047] Specifically, the logical expressions in the validation rule file can be divided into conditional expressions and logical operation expressions. Conditional expressions include specific comparison operations, interval operations, list judgments, etc., which are used to verify whether the data in the form field meets expectations. For example, the age must be greater than or equal to 18 years old. Logical operation expressions are used to connect multiple conditional expressions and combine multiple conditions through logical operators (such as AND or OR). The visitor pattern is a design pattern used to add new operations without changing the data structure. Here, the abstract syntax tree parsed from the validation rule file is traversed through the visitor pattern to identify and process the conditional expressions and logical operation expressions therein.

[0048] Whenever a node is traversed, it is determined whether it is a conditional expression or a logical operation expression, and corresponding conditional nodes or logical operation nodes are generated according to different types of nodes. The conditional node is a leaf node, which represents a specific verification condition. The logical operation node is a non-leaf node, which represents a logical operator and is used to connect multiple conditional nodes or other logical operation nodes. Each logical operation node can contain any number of child nodes, which can be conditional nodes or other logical operation nodes. The first logical operation node is used to represent an AND expression, that is, an AND node. This type of node requires that all sub-conditions must be true to return true. The second logical operation node is used to represent an OR expression, that is, an OR node. This type of node only needs one sub-condition to be true to return true.

[0049] By traversing the abstract syntax tree and identifying condition nodes and logic operation nodes, a logic rule tree is gradually constructed. The root node of the logic rule tree can be an AND or OR node, while the leaf nodes are usually specific condition nodes. The structure of the logic rule tree enables recursive processing of each condition and logical relationship in the actual verification process.

[0050] Furthermore, step six of this application includes:

[0051] Based on the form data to be verified, the logic rule tree is traversed in pre-order to identify the type of the trigger node; the type of the trigger node is judged, and when the type of the trigger node is the first logic operation node, a first verification result set of all child nodes of the trigger node type is obtained; it is judged whether the first verification result set is all true, a first verification feedback result is generated, and the result is added to the verification feedback information.

[0052] Specifically, the pre-order traversal is used to process each node in the logic rule tree step by step, and determine whether the verification condition is met according to the type of the node. The logic rule tree is traversed in pre-order based on the form data to be verified, that is, starting from the root node of the logic rule tree, each node is traversed in turn, including logic operation nodes and conditional nodes. During the traversal process, the type of each node is identified. Usually, the node types include: first logic operation node, second logic operation node, conditional node. If the trigger node is the first logic operation node (AND), recursively traverse all its child nodes, obtain the verification result of each child node, and generate a first verification result set. If the first verification result set is all true, the first verification feedback result is true, otherwise it is false.

[0053] Furthermore, the present application also includes the following steps:

[0054] When the type of the trigger node is the second logic operation node, obtain the second verification result set of all child nodes of the trigger node type; determine whether the second verification result set is all false, generate a second verification feedback result, and add it to the verification feedback information.

[0055] Specifically, during the form verification process, when traversing to the second logic operation node (ie, OR operation node), the verification results of all child nodes are recursively obtained to form a second verification result set. The second logic operation node indicates that as long as the condition of one child node is met, the entire condition is true. If the verification results of all child nodes are false, the node verification fails. If any sub-condition in the second verification result set is true, the final verification result is true; if the results of all child nodes are false, the verification result is false, thereby generating a second verification feedback result and adding it to the verification feedback information. The feedback information will be used to generate the final form verification result.

[0056] Furthermore, the present application also includes the following steps:

[0057] When the type of the trigger node is the conditional node, field data is extracted from the form data to be verified according to the field of the trigger node; whether the node function has a value is determined based on the field data, and if so, conversion is performed according to a first preset rule to generate first converted field data; the second preset rule is called to judge the first converted field data, generate a third verification feedback result, and add it to the verification feedback information.

[0058] Specifically, during the form verification process, when traversing to the conditional node, it is necessary to extract the corresponding field data from the form data to be verified according to the field of the conditional node, and perform corresponding judgment and processing. If certain functions (such as length functions) are used in the conditional node, the field data is converted and processed based on the function, and the verification result is generated according to the preset rules.

[0059] Specifically, when traversing to the conditional node, first extract the field data corresponding to the conditional node field from the form data to be verified, which usually includes the field name, operator and target value. After extracting the field data, check whether the conditional node contains the function that needs to be processed. The node function refers to a function that performs some calculation or operation on the field data, such as length() for calculating the length, substring() for obtaining a substring, etc. If the conditional node contains a function, it will be determined whether the node function has a value based on the field data. If the node function has a value, the first preset rule will be called to convert the extracted field data. The first preset rule processes the data accordingly according to different node functions. For example: for the length() function, calculate the length of the field data; for the substring() function, extract the string in the field data. For example, for name="Alice", call the length function and calculate that the length of "Alice" is 5. This length is the first converted field data.

[0060] After the conversion is completed, the second preset rule is called to verify the converted first conversion field data. The second preset rule is usually a judgment rule related to the operator of the conditional node, such as comparison operations (>, >=, =). For example, in the length(name) > 3 rule, the length of name (i.e. 5) is compared with the target value 3 to determine whether the condition is met. Since 5 is greater than 3, the condition is met. According to the judgment result of the second preset rule, the third verification feedback result is generated. If the condition is met, the third verification feedback result is true; otherwise, the third verification feedback result is false. The third verification feedback result is added to the verification feedback information, and is finally used to determine whether the form passes the verification.

[0061] In summary, the offline form data dynamic verification method provided by this application has the following technical effects:

[0062] Define a verification rule file; call a syntax parser to perform rule parsing on the verification rule file and generate an abstract syntax tree; traverse the abstract syntax tree to generate a logic rule tree; dynamically load the logic rule tree into a target lightweight application in JSON format; receive the form data to be verified and pass it into the target lightweight application; connect the target lightweight application and receive verification feedback information, wherein the verification feedback information is a node verification result obtained by the target lightweight application performing data verification according to the form data to be verified; extract the root node verification result based on the verification feedback information, if the root node verification result is true, the verification fails, otherwise, it passes. This application can solve the technical problems in the prior art that the server load is high and the network delay is large due to the poor flexibility of form data verification. By defining a verification rule file, generating a logic rule tree, and loading it into the target lightweight application to perform data verification, flexible and efficient dynamic verification of form data is achieved, thereby reducing the server load and improving the response speed of the application and the accuracy of verification.

[0063] Embodiment 2, based on the same inventive concept as the offline form data dynamic verification method in the aforementioned embodiment 1, the present application also provides an offline form data dynamic verification system, please refer to the attached Figure 2 , the offline form data dynamic verification system comprises:

[0064] The rule definition module 11 is used to define the verification rule file.

[0065] The rule parsing module 12 is used to call a syntax parser to perform rule parsing on the verification rule file and generate an abstract syntax tree.

[0066] The logic rule generation module 13 is used to traverse the abstract syntax tree and generate a logic rule tree.

[0067] The rule tree loading module 14 is used to dynamically load the logic rule tree into the target lightweight application in JSON format.

[0068] The form data receiving module 15 is used to receive the form data to be verified and transfer it to the target lightweight application.

[0069] The node verification module 16 is used to connect to the target lightweight application and receive verification feedback information, wherein the verification feedback information is a node verification result obtained by the target lightweight application performing data verification according to the form data to be verified.

[0070] The root node verification analysis module 17 is used to extract the root node verification result based on the verification feedback information. If the root node verification result is true, the verification fails, otherwise, it passes.

[0071] Furthermore, the rule definition module 11 in the offline form data dynamic verification system further includes:

[0072] The verification rule file writes the verification rules in SQL syntax, and the logical expressions of the verification rules include comparison operation expressions, interval operation expressions, non-interval operation expressions, in-list expressions, non-in-list expressions, pattern matching expressions, non-pattern matching expressions, empty expressions, non-empty expressions, bracket expressions, and expressions, and or expressions.

[0073] Furthermore, the rule definition module 11 in the offline form data dynamic verification system further includes:

[0074] The form of the logical expression includes field name, function call, constant value, multiplication and division expression, addition and subtraction expression, string connection expression and bracket expression; the logical expression satisfies the preset priority constraint.

[0075] Furthermore, the rule definition module 11 in the offline form data dynamic verification system further includes:

[0076] The function call forms include average aggregation function, maximum aggregation function, minimum aggregation function, total aggregation function, ordinary function and CAST function.

[0077] Furthermore, the logic rule generation module 13 in the offline form data dynamic verification system is also used for:

[0078] Classify the logical expressions of the verification rules to generate conditional expressions and logical operation expressions; use the visitor pattern to traverse the abstract syntax tree, identify the conditional expressions and the logical operation expressions, and generate conditional nodes and logical operation nodes; wherein any node in the conditional node and the logical operation node has any number of child nodes; the logical operation node includes a first logical operation node and a second logical operation node; the first logical operation node is a node corresponding to an and expression, and the second logical operation node is a node corresponding to an or expression; establish the logical rule tree with the conditional nodes and the logical operation nodes.

[0079] Furthermore, the node verification module 16 in the offline form data dynamic verification system is also used for:

[0080] Based on the form data to be verified, the logic rule tree is traversed in pre-order to identify the type of the trigger node; the type of the trigger node is judged, and when the type of the trigger node is the first logic operation node, a first verification result set of all child nodes of the trigger node type is obtained; it is judged whether the first verification result set is all true, a first verification feedback result is generated, and the result is added to the verification feedback information.

[0081] Furthermore, the node verification module 16 in the offline form data dynamic verification system is also used for:

[0082] When the type of the trigger node is the second logic operation node, obtain the second verification result set of all child nodes of the trigger node type; determine whether the second verification result set is all false, generate a second verification feedback result, and add it to the verification feedback information.

[0083] Furthermore, the node verification module 16 in the offline form data dynamic verification system is also used for:

[0084] When the type of the trigger node is the conditional node, field data is extracted from the form data to be verified according to the field of the trigger node; whether the node function has a value is determined based on the field data, and if so, conversion is performed according to a first preset rule to generate first converted field data; the second preset rule is called to judge the first converted field data, generate a third verification feedback result, and add it to the verification feedback information.

[0085] The various embodiments in this specification are described in a progressive manner, and each embodiment focuses on the differences from other embodiments. Figure 1 The offline form data dynamic verification method and specific examples in the first embodiment are also applicable to the offline form data dynamic verification system of the present embodiment. Through the above detailed description of the offline form data dynamic verification method, those skilled in the art can clearly understand the offline form data dynamic verification system of the present embodiment, so for the sake of brevity of the specification, it will not be described in detail here. For the system disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part description.

[0086] The above description of the disclosed embodiments enables those skilled in the art to implement or use the present application. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present application. Therefore, the present application will not be limited to the embodiments shown herein, but will conform to the widest scope consistent with the principles and novel features disclosed herein.

[0087] Obviously, those skilled in the art can make various changes and modifications to the present application without departing from the spirit and scope of the present application. Thus, if these modifications and variations of the present application belong to the scope of the present application and its equivalent technology, the present application is also intended to include these modifications and variations.

Claims

1. An offline form data dynamic verification method, characterized in that: include: Define the verification rule file; Calling a syntax parser to perform rule parsing on the verification rule file to generate an abstract syntax tree; Traversing the abstract syntax tree to generate a logic rule tree; Dynamically loading the logic rule tree into a target lightweight application in JSON format; Receiving the form data to be verified and transferring it to the target lightweight application; Connecting to the target lightweight application and receiving verification feedback information, wherein the verification feedback information is a node verification result obtained by the target lightweight application performing data verification according to the form data to be verified; Extracting the root node verification result based on the verification feedback information, if the root node verification result is true, the verification fails, otherwise, the verification passes; Wherein, traversing the abstract syntax tree to generate a logic rule tree includes: Classifying the logical expressions of the verification rules to generate conditional expressions and logical operation expressions; Use the visitor pattern to traverse the abstract syntax tree, identify the conditional expression and the logical operation expression, and generate a conditional node and a logical operation node; Among them, any node in the condition node and the logic operation node has any number of child nodes; the logic operation node includes a first logic operation node and a second logic operation node; the first logic operation node is a node corresponding to an and expression, and the second logic operation node is a node corresponding to an or expression; Establishing the logic rule tree with the condition nodes and the logic operation nodes; Wherein, connecting to the target lightweight application and receiving verification feedback information includes: Performing a pre-order traversal on the logic rule tree based on the form data to be verified to identify the type of the trigger node; Determine the type of the trigger node, and when the type of the trigger node is the first logic operation node, obtain a first verification result set of all child nodes of the trigger node type; Determine whether all of the first verification result set are true, generate a first verification feedback result, and add it to the verification feedback information; The step of determining the trigger node type includes: When the type of the trigger node is the second logic operation node, obtaining a second verification result set of all child nodes of the trigger node type; Determine whether all of the second verification result set are false, generate a second verification feedback result, and add it to the verification feedback information; The step of determining the trigger node type includes: When the type of the trigger node is the conditional node, extracting field data from the form data to be verified according to the field of the trigger node; Determine whether the node function has a value based on the field data, and if so, convert it according to a first preset rule to generate first converted field data; A second preset rule is called to judge the first conversion field data, generate a third verification feedback result, and add it to the verification feedback information.

2. The offline form data dynamic verification method according to claim 1, characterized in that: The verification rule file writes the verification rules in SQL syntax, and the logical expressions of the verification rules include comparison operation expressions, interval operation expressions, non-interval operation expressions, in-list expressions, non-in-list expressions, pattern matching expressions, non-pattern matching expressions, empty expressions, non-empty expressions, bracket expressions, and expressions, and or expressions.

3. The offline form data dynamic verification method according to claim 2, characterized in that: The form of the logical expression includes field name, function call, constant value, multiplication and division expression, addition and subtraction expression, string concatenation expression and bracket expression; The logical expression satisfies a preset priority constraint.

4. The offline form data dynamic verification method according to claim 3, characterized in that: The function call forms include average aggregation function, maximum aggregation function, minimum aggregation function, total aggregation function, ordinary function and CAST function.

5. An offline form data dynamic verification system, characterized in that: The steps for implementing the offline form data dynamic verification method according to any one of claims 1 to 4 include: Rule definition module, used to define verification rule files; A rule parsing module, used for calling a syntax parser to perform rule parsing on the verification rule file and generate an abstract syntax tree; A logic rule generation module, used for traversing the abstract syntax tree and generating a logic rule tree; A rule tree loading module, used for dynamically loading the logic rule tree into a target lightweight application in JSON format; A form data receiving module, used for receiving the form data to be verified and transferring it to the target lightweight application; A node verification module, used to connect to the target lightweight application and receive verification feedback information, wherein the verification feedback information is a node verification result obtained by the target lightweight application performing data verification according to the form data to be verified; The root node verification analysis module is used to extract the root node verification result based on the verification feedback information. If the root node verification result is true, the verification fails, otherwise, it passes.

Images