A routing parameter checking method and device

Abstract

The embodiment of the present application discloses a kind of route parameter checking method and device.For solving the problem of low efficiency of route parameter checking in prior art.The method is applied to routing framework, and the routing framework has at least the function of declaring route parameter and checker, and the checker is used to check the route parameter, and the method comprises declaring the route parameter to be checked and the checker, carrying out first checking on the route parameter by the checker before opening functional component, if first checking succeeds, open functional component, and carry out second checking on the route parameter by the checker.In the functional component is opened before, carries out once automatic checking, and after the functional component is opened, again carries out once automatic checking, to improve the efficiency of route parameter checking, and the route parameter can be checked more comprehensively, accurately and without omission.

Description

Technical Field

[0001] This invention relates to the field of parameter verification, and more particularly to a method and apparatus for verifying routing parameters. Background Technology

[0002] With the rapid development of terminal devices, their demands on applications are increasing. To better develop application functionality, routing frameworks are often used to decouple calls between various functional components, such as pages or services. Taking a page as an example, in traditional development, opening a page requires hardcoding the corresponding page object in the code. However, based on a routing framework, pages are replaced with route addresses, which can be flexibly specified to any page. Therefore, during the compilation phase, there is no need to strongly depend on other page functionalities, thus decoupling the various functional components through the routing framework.

[0003] When a functional component is opened or navigated to, a number of routing parameters are typically obtained. Taking a page as an example, when navigating from page A to page B, a number of routing parameters are passed to page B. Page B usually supports automatic injection of routing parameters. Specifically, page B can declare routing parameters through member variables. When page B is opened, the corresponding routing parameter values ​​are automatically read from the passed routing parameters and injected into these variables. However, if the injected routing parameters are invalid, it will cause page B to display abnormally or experience service failures. Therefore, page B needs to validate the obtained routing parameters first.

[0004] In existing technologies, functional components validate acquired routing parameters by manually creating numerous validation templates and then using these templates to verify the format and content of the acquired routing parameters. However, this manual validation method results in low efficiency for routing parameter validation. Summary of the Invention

[0005] This invention provides a routing parameter verification method and apparatus to solve the problem of low efficiency in routing parameter verification in the prior art.

[0006] In a first aspect, embodiments of the present invention provide a routing parameter verification method applied to a routing framework, wherein the routing framework has at least the function of declaring routing parameters and a verifier, the verifier being used to verify the routing parameters, the method comprising: declaring the routing parameters to be verified and the verifier; performing a first verification on the routing parameters through the verifier before opening the functional component; if the first verification is successful, opening the functional component and performing a second verification on the routing parameters through the verifier.

[0007] Based on this scheme, route parameter validation is added to the original route parameter passing, thereby ensuring the validity of the route parameters. Automatic validation is performed once before the functional component is opened and again after it is opened, which improves the efficiency of route parameter validation and allows for more comprehensive, accurate, and complete validation of route parameters. Furthermore, through automatic route parameter injection and automatic route parameter validation, the functional component can guarantee the legality of component calls, thus ensuring that the functional component does not malfunction.

[0008] In one possible implementation, the first validation of the routing parameters by the validator includes: determining the validation rules of the validator; and determining that the routing parameters pass validation if the value of the routing parameters satisfies the validation rules. The validation rules include any of the following: the value of the routing parameter cannot be an empty string or null; the value of the routing parameter belongs to a first range; the string length or set size of the routing parameter is within a second range; the size of the routing parameter value is within a third range; or the value of the routing parameter satisfies a regular expression.

[0009] By defining the verification rules for the verifier, the route can be verified once before the functional components are enabled.

[0010] In one possible implementation, the routing parameter corresponds to a validator, and the syntax rules used by the validator include: validator identifier: parameter list of the validator; or, the routing parameter corresponds to M validators, where M is an integer greater than 1; the syntax rules used by the M validators include: M validator identifiers connected by logical expressions: parameter list of the validator.

[0011] The syntax rules used by the validators defined above are simple and intuitive. Therefore, page definers can define the validation rules that each route parameter needs to meet through simple annotation definitions. Since the routing framework will automatically generate code and determine whether the route parameters are valid, page definers do not need to worry about the validity of the route parameters.

[0012] In one possible implementation, declaring the routing parameters to be verified includes: declaring the routing target corresponding to the routing parameters; opening the functional component and performing a second verification on the routing parameters through the verifier includes: generating a routing constructor class for the routing target corresponding to the routing parameters, the routing constructor class being used to open the routing target; generating a calling method for the routing parameters in the routing constructor class; generating a calling method for the verifier in the calling method for the routing parameters; and calling the verifier through the calling method to perform a second verification on the routing parameters.

[0013] Thus, the name of the routing parameter can be specified by the method name, and the type of the routing parameter can be specified by the method parameter, thereby ensuring that the routing parameter passing is type-safe. Furthermore, since the route constructor class is automatically generated, the proper construction of the route can be guaranteed. In other words, based on the solution provided by this embodiment of the invention, code for opening functional components can be automatically generated, thereby providing a type-safe routing parameter passing method, thus ensuring the validity of the routing parameter name and type during the compilation phase; and also ensuring the proper construction of the route.

[0014] In one possible implementation, the method for generating the validator in the method for invoking the routing parameters includes: for each validator among all declared validators, performing the following steps: parsing the usage syntax rules of the validator; obtaining the identifier of the validator and creating an instance of the validator; invoking the instance of the validator and obtaining the parameters of the validator according to the identifier of the validator; validating the routing parameters according to the parameters of the validator; and obtaining a validation result, the validation result including whether the routing parameters have passed validation or have failed validation.

[0015] By generating classes to load and call methods, compared to the conventional key-value passing method, the solution based on this invention can achieve more accurate and secure verification.

[0016] In one possible implementation, before declaring the routing parameters to be verified and the verifier, the method further includes: creating a correspondence between functional components and routing addresses, wherein the routing parameters are parameters obtained when the functional components are checked in; and creating a correspondence between verifier identifiers and verifier types, wherein different types of verifiers correspond to different verification rules.

[0017] By establishing a relationship between functional components and route addresses, the route addresses corresponding to functional components can be flexibly set, thereby decoupling strong dependencies between functional components. By establishing a mapping between validator identifiers and validator types, it is convenient to subsequently obtain the validator type through the validator identifier, thus determining the validator's validation rules.

[0018] In one possible implementation, if the routing parameter is a constant, a second verification is performed on the routing parameter by the validator corresponding to the routing parameter before calling the parameter assignment method; if the routing parameter is not a constant, the verification rules of the validator corresponding to the routing parameter are notified through method parameter hints, and the routing parameter is then verified according to the hinted verification rules.

[0019] If the route parameter is a constant, a compilation validity check and validity hints for the route parameter can be provided through an Android Studio plugin before calling the parameter assignment method, thus making it easier for the caller to invoke the method.

[0020] Secondly, embodiments of the present invention provide a parameter verification device, the parameter verification device including a routing framework, the routing framework having at least the function of declaring routing parameters and a verifier, the verifier being used to verify the routing parameters, the device including: a declaration module for declaring the routing parameters to be verified and the verifier; a first verification module for performing a first verification on the routing parameters through the verifier; and a second verification module for, if the first verification is successful, opening the functional component and performing a second verification on the routing parameters through the verification.

[0021] In one possible implementation, the apparatus further includes a determining module; the determining module is configured to: determine the verification rules of the verifier; and if the value of the routing parameter satisfies the verification rules, determine that the routing parameter has passed verification. The verification rules include any of the following: the value of the routing parameter cannot be an empty string or null; the value of the routing parameter belongs to a first range; the string length or set size of the routing parameter is within a second range; the size of the routing parameter value is within a third range; and the value of the routing parameter satisfies a regular expression.

[0022] In one possible implementation, the routing parameter corresponds to a validator, and the syntax rules used by the validator include: validator identifier: parameter list of the validator; or, the routing parameter corresponds to M validators, where M is an integer greater than 1; the syntax rules used by the M validators include: M validator identifiers connected by logical expressions: routing parameter list of the validator.

[0023] In one possible implementation, the declaration module is specifically used to: declare the routing target corresponding to the routing parameter; the second verification module is specifically used to: generate a routing constructor class for the routing target corresponding to the routing parameter, the routing constructor class being used to open the routing target; generate a calling method for the routing parameter in the routing constructor class; generate a calling method for the verifier in the calling method for the routing parameter; and call the verifier through the calling method to perform a second verification on the routing parameter.

[0024] In one possible implementation, the second verification module is specifically configured to: for each of the declared verifiers, perform the following steps: parse the usage syntax rules of the verifier; obtain the identifier of the verifier and create an instance of the verifier; call the instance of the verifier and obtain the parameters of the verifier based on the identifier of the verifier; and verify the routing parameters based on the parameters of the verifier. The device further includes an acquisition module configured to: obtain a verification result, the verification result including whether the routing parameter verification passed or failed.

[0025] In one possible implementation, the device further includes a creation module for: creating a correspondence between functional components and routing addresses, wherein the routing parameters are parameters obtained when the functional components are checked in; and creating a correspondence between verifier identifiers and verifier types, wherein different types of verifiers correspond to different verification rules.

[0026] Thirdly, embodiments of the present invention provide a computer-readable storage medium storing a computer program or instructions, which, when executed by a parameter verification device, causes the parameter verification device to perform the first aspect or any possible method described above.

[0027] Fourthly, embodiments of the present invention provide a computer device, including a memory for storing program instructions; and a processor for calling the program instructions stored in the memory and executing the methods described in the first aspect or any possible methods of the first aspect according to the obtained program.

[0028] The beneficial effects that can be achieved by the second to fourth aspects mentioned above can be found in the description of the first aspect mentioned above, and will not be repeated here. Attached Figure Description

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

[0030] Figure 1 A flowchart of a parameter verification method is provided in this embodiment of the invention;

[0031] Figure 2 This is a flowchart illustrating a method for creating a routing framework according to an embodiment of the present invention;

[0032] Figure 3 A schematic diagram of a routing framework provided in an embodiment of the present invention;

[0033] Figure 4 This is a flowchart illustrating a method for invoking a verifier according to an embodiment of the present invention.

[0034] Figure 5 This is a schematic diagram of the parameter verification device provided in an embodiment of the present invention;

[0035] Figure 6 This is a schematic diagram of the parameter verification device provided in an embodiment of the present invention. Detailed Implementation

[0036] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0037] The following explanations cover some of the terms used in the embodiments of the present invention. It should be noted that these explanations are for the convenience of those skilled in the art and are not intended to limit the scope of protection claimed by the embodiments of the present invention.

[0038] I. Functional Components

[0039] Functional components can be applications developed within the local operating system of a terminal device (such as iOS or Android) using supported programming languages ​​and development tools, directly calling the Application Programming Interface (API) provided by the operating system; or they can be applications developed based on a third-party framework. For example, the third-party framework is the Flutter framework. Optionally, the non-native application is an application developed based on the Flutter framework. The Flutter framework is a mobile application development framework, specifically a Software Development Kit (SDK) built using the Dart language. A functional component can refer to a class, and a functional component can include multiple methods; a method can be represented by a function.

[0040] II. Parameter Verification

[0041] Functional components need to determine whether the data they obtain (e.g., the data they receive) is valid; this process can be called parameter validation.

[0042] III. Class

[0043] A class is a user-defined reference data type, also known as a class type. Each class contains data descriptions and a set of functions for manipulating data or passing messages. Instances of a class are called objects. In other words, a class is a definition of a certain type of object, describing what an object can do and the methods it can use. A class consists of member attributes and member methods (data members and member functions). Data members correspond to the attributes of the class; class data members are also a data type and do not require memory allocation. Member functions are used to manipulate the various attributes of the class; they are operations unique to a class, such as "student" being able to "attend class," while "fruit" cannot. The operations through which a class interacts with the outside world are called interfaces.

[0044] IV. Compilation

[0045] Compilation is the process of converting a high-level language into a binary language that a computer can understand.

[0046] As described in the background section, in the prior art, verifying routing parameters requires manually writing a large number of verification templates, which results in low efficiency in verifying routing parameters.

[0047] Therefore, embodiments of the present invention provide a routing parameter verification method. This routing parameter verification method can improve the efficiency of routing parameter verification.

[0048] like Figure 1 The diagram shown is a flowchart of a routing parameter verification method provided by an embodiment of the present invention. This method can be applied to a routing framework, which at least has the functionality to declare routing parameters and a verifier, wherein the verifier is used to verify the routing parameters. For an introduction to routing frameworks, please refer to the following... Figure 3 The relevant descriptions will not be repeated here.

[0049] The method includes the following steps:

[0050] Step 101: Declare the routing parameters to be verified and the verifier.

[0051] In one possible implementation, a route parameter can declare one validator, or a route parameter can declare multiple validators. If a route parameter declares multiple validators, then the route parameter needs to satisfy the logical expressions of the multiple validators.

[0052] For the process of declaring the routing parameters to be verified and the verifier, please refer to the following: Figure 3 Introduction.

[0053] Step 102: Before opening the functional component, perform a first verification on the routing parameters using a verifier; if the verification is successful, proceed to step 103 below; if the verification fails, do not open the functional component.

[0054] In one possible implementation, the verification rules of the verifier are determined. If the value of the routing parameter satisfies the verification rules, the routing parameter verification is determined to be successful; otherwise, the routing parameter verification is determined to be unsuccessful.

[0055] For example, declare a routing parameter a, and declare a numRange validator (numRange:2,4) for the routing parameter a. If the value of the routing parameter a is between [2,4], it means that the routing parameter a is valid, that is, the routing parameter a passes the verification; if the value of the routing parameter a is not between [2,4], it means that the routing parameter a is invalid, that is, the routing parameter a fails the verification.

[0056] In another possible implementation, route parameters can be validated via an Android Studio plugin. If the route parameter is a constant, the corresponding validator can be automatically executed immediately when the user calls the parameter assignment method using RouterBuilder to verify whether the route parameter is valid. This allows route parameter validation to be performed at the code writing stage, eliminating the need to wait until the compilation stage. If the route parameter is not a constant, the validation rules of the validator can be communicated through method parameter hints, such as a pop-up window.

[0057] Step 103: Open the functional component and perform a second verification on the routing parameters through the verifier.

[0058] In one possible implementation, a route constructor class is generated for the route target corresponding to the route parameters, and the route constructor class is used to open the route target; in the route constructor class, a calling method for the route parameters is generated; in the calling method for the route parameters, a calling method for the validator is generated.

[0059] The specific process of generating the parameter verification code in step 103 can be found in the following introduction to generating the corresponding navigation Router class (Compilation 1). The process of performing a second verification of the routing parameters through the verifier can be found in the following... Figure 4 Introduction.

[0060] As can be seen from steps 101 to 103 above, route parameter validation is added to the original route parameter passing process, thereby ensuring the validity of the route parameters. Performing automatic validation before and after the functional component is opened improves the efficiency of route parameter validation and allows for more comprehensive, accurate, and complete validation. Furthermore, through automatic route parameter injection and automatic route parameter validation, the functional component can guarantee legitimate component calls, thus preventing component anomalies.

[0061] Before performing route parameter validation, a routing framework suitable for route parameter validation needs to be created. For example... Figure 2 The diagram shown is a flowchart illustrating a method for creating a routing framework according to an embodiment of the present invention. The method includes the following steps:

[0062] Step 201: Create a mapping between each functional component and its routing address.

[0063] This can also be understood as binding a route address to a functional component instance. The route address can be represented by a string, for example, "test". Taking a page as an example, the route address is bound to the page instance. Specifically, "test" can be bound to "page A (i.e., the page instance)". In other words, "page A" can be opened via the route address "test". Thus, when the routing framework runs, the required page instance can be found through the route address, and then the page corresponding to that page instance can be opened. Furthermore, before opening the page corresponding to that page instance, the page to be opened can be intercepted. After interception, special processing can be performed, such as adding page permission verification, adding logs, or redirecting to other pages.

[0064] In one possible implementation, routing code can be generated for each functional component, and this routing code can be added to the routing framework. This routing code is a subclass of IComponent.

[0065] Step 202: Register at least one verifier.

[0066] In one possible implementation, at least one validator can be pre-registered automatically with the routing framework, and each registered validator is a subclass of IChecker. Each validator can be represented by a unique identifier.

[0067] Specifically, a validator identifier can be bound to a validator type (or a validator instance or a validator parameter). In other words, a mapping is created between validator identifiers and validator types. Thus, when the routing framework is running, the corresponding validator type can be found through the validator identifier.

[0068] In one possible implementation, the validator types include, but are not limited to: non-empty validator (the corresponding validation rule is that the value of the route parameter cannot be an empty string or null), non-null validator (the corresponding validation rule is that the value of the route parameter cannot be null), specified set validator (the corresponding validation rule is that the value of the route parameter belongs to a certain range, which can be called the first range), length validator (the corresponding validation rule is that the string length of the route parameter or the size of the set must be within a certain range, which can be called the second range), numeric range validator (the corresponding validation rule is that the size of the route parameter value must be within a certain range, which can be called the third range), regular expression validator (the corresponding validation rule is that the value of the route parameter must satisfy a regular expression, etc.). It should be understood that different types of validators have different validation rules.

[0069] It should be noted that the routing framework in this embodiment of the invention also supports custom validators. The following details the methods for creating custom validators.

[0070] In one possible implementation, a class can be created that implements the IChecker interface and includes a method to determine validity (isValid). Specifically, this method can take the route parameter object (i.e., the route parameters declared as member variables), the route parameter name (the name of the route parameter declared as a member variable), and the validator's validation rules.

[0071] Furthermore, add the `@Checker` annotation to this class. This annotation allows you to specify a validator identifier. It should be understood that a custom validator can be implemented in email or phone number formats. For example, `@Checker(“phoneNum”)` indicates that the validator identifier specified for this class is a phone number (phoneNum).

[0072] In one possible implementation, a custom validator can be registered with the routing framework, as detailed in step 202 above, which will not be repeated here.

[0073] Based on the routing framework in this embodiment of the invention, it is also necessary to define the syntax rules used by the validator. The syntax rules used by the validator are described in detail below for each scenario.

[0074] Scenario 1: Syntax rules used by a single validator.

[0075] Based on scenario one, the syntax rule can be expressed as: Validator identifier: Validator parameter list. This syntax rule indicates that the values ​​of routing parameters must satisfy the validator's parameter list. Parameters in the validator's parameter list can be separated by commas. If a comma appears in a validator parameter list, a forward slash ( / ,) is added before it. It should be understood that the parameters in the validator's parameter list have a specific order; their positions cannot be interchanged.

[0076] For example, the syntax rule is expressed as: in: a,b,c,d. This syntax rule means that the value of the routing parameter must be limited to the four strings "a", "b", "c", and "d", where in is the validator identifier. It should be understood that the type of validator is predefined for each validator identifier.

[0077] Scenario 2: Syntax rules used by multiple validators.

[0078] In one possible implementation, the validator's validation rules can support logical expressions. For example, it can support parentheses, &&, and ||, where parentheses represent combination, && represents AND, and || represents OR.

[0079] Based on this second scenario, the syntax rules can be expressed as: Validator identifier: Validator parameter list logical expression Validator identifier: Validator parameter list logical expression Validator identifier: Validator parameter list… For example, lengthRange:0,3||lengthRange:empty means that the value of the routing parameter must satisfy the requirement of a length of [0-3] or be empty, where lengthRange is the validator identifier.

[0080] Based on this second scenario, the syntax rule can be interpreted as requiring routing parameters to satisfy the logical expression within the syntax rule. This logical expression can also be understood as a flexible combination of multiple validators.

[0081] The validator defined above uses a simple and intuitive syntax. Therefore, page definers can easily define the validation rules that each route parameter must meet through annotations. Since the routing framework automatically generates code and determines whether the route parameters are valid, page definers do not need to worry about the validity of the route parameters. It should be understood that in existing technologies, the validity of route parameters needs to be determined every time they are obtained.

[0082] like Figure 3The diagram illustrates a routing framework provided in an embodiment of the present invention. This routing framework includes a route definition (@Router) and a route parameter definition (@Param), where the @Param attribute includes Checkers. @Router is used to declare the route address of a functional component. For example, declaring @Router(“test”) for page A means that page A can be opened via the route address “test”. @Param is used to declare route parameters, that is, to declare which route parameters need to be validated; furthermore, the Checkers attribute in @Param is used to declare validators. It should be understood that each functional component supports which parameters are pre-obtainable, and the route parameters declared among these parameters need to be validated by the corresponding declared validators.

[0083] Based on the above Figure 3 The routing framework shown can be used in practice by first declaring the route target using @Router, then declaring the route parameters in the route (opening the page) using @Param, and finally calling the validators to be used in the Checkers property of @Param, i.e., declaring the validators.

[0084] For example, the route target "test" is declared using `@Router`, and the route parameter 'a' is declared in the route (i.e., when the functional component is enabled) using `@Param`. In the `Checkers` property of `@Param`, a validator `numRange` (`numRange:2,4`) is declared for route parameter 'a'. This means that if the value of route parameter 'a' is between [2,4], then route parameter 'a' is valid, i.e., route parameter 'a' passes validation; if the value of route parameter 'a' is not between [2,4], then route parameter 'a' is invalid, i.e., route parameter 'a' fails validation. Here, `numRange` in `numRange:2,4` is the validator identifier, and 2,4 represent the parameter list of the validator.

[0085] The above-mentioned process of verifying routing parameters can also be understood as a verification process before opening functional components.

[0086] It should be noted that during the development phase, after declaring a validator, it can also be checked. One possible implementation is to use an Android Studio plugin to perform syntax checking and code suggestions on the validator, and collect information such as the validator identifier and the length of its parameters to perform simple validation. Code suggestions include, but are not limited to, displaying the validator identifier corresponding to the first letter of the code. For example, entering the first letter 'n' might suggest "numRange".

[0087] In one possible implementation, automatic code generation technology is used to generate corresponding Java call code for the declared route parameters and the validators declared for the route parameters. Using tools such as JavaPoet, during the Android compilation phase, all Java code is intercepted using Java's annotation processor or Kotlin's kapt annotation processor mechanism. Further, all Java classes annotated with `@Router` are located, and their annotation attributes are read. All member variables annotated with `@Param` are found, their `checker` attributes are parsed, and this information is collected. Based on this collected information, the corresponding navigation Router class (compilation 1) and parameter binding Binder class (compilation 2) are generated.

[0088] The following describes how to generate the corresponding navigation Router class (Compilation 1).

[0089] In one possible implementation, automatic code generation technology generates a corresponding route constructor (RouterBuilder) class for each route target declared with `@Router`. This class is used to open the declared route target (i.e., a specific route target). Within the RouterBuilder class, a corresponding calling method is defined for each route parameter (i.e., member variable) declared with `@Param`. Thus, the name of the route parameter can be qualified by the method name, and the type of the route parameter (e.g., string, number, or boolean value) can be qualified by the method parameter, ensuring type-safe route parameter passing. Furthermore, since the route constructor class is automatically generated, the reasonable construction of the route is guaranteed. In other words, based on the solution provided by this embodiment, code for opening functional components can be automatically generated, thereby providing a type-safe route parameter passing method, ensuring the validity of the route parameter name and type during the compilation phase; and ensuring the reasonable construction of the route. It should be understood that existing technologies use a key-value method to validate route parameters, making it easy to misspell the route parameter name and type. It should also be understood that each method has a name, and the method name can qualify the type of the route parameter.

[0090] It should be noted that if the route parameter is a deducible constant, a compilation validity check and validity hint for the route parameter can be provided through an Android Studio plugin, which can facilitate the caller's use.

[0091] After generating the RouteBuilder class, developers can call routes in a type-safe manner and automatically validate each route parameter without having to call it manually.

[0092] Furthermore, within the methods generated for each route parameter declared in `@Param`, a corresponding calling method is generated for each validator. The validator calling methods (i.e., code implementation) can be found below. Figure 4 Introduction.

[0093] like Figure 4 The diagram shown is a flowchart illustrating a method for invoking a verifier according to an embodiment of the present invention. The method includes the following steps:

[0094] Step 401: Traverse all validators.

[0095] Specifically, it is possible to iterate through all validators declared for member variables.

[0096] Perform steps 402 to 405 for each validator.

[0097] Step 402: The parser uses the syntax rules.

[0098] For example, separate the validator identifier and the validator's parameter list, and separate the parameters in the parameter list with commas.

[0099] Step 403: Obtain the identifier of the corresponding verifier and create an instance of the verifier.

[0100] In one possible implementation, a validator class can be created using a validator identifier. It should be understood that only by creating an instance of a validator can the validation of route parameters be performed.

[0101] Step 404: Invoke an instance of the verifier, obtain the verifier's parameters based on the verifier's identifier, and verify the routing parameters.

[0102] The returned result includes a boolean value, which indicates whether the validation passed or failed.

[0103] Furthermore, the returned result may also include a msg string, which describes the reason for the error, making it easier for developers to quickly handle the error.

[0104] In one possible implementation, if the validation fails, an error is added to the RouteBuilder.

[0105] Step 405: Obtain the verification result.

[0106] In one possible implementation, the verification result can be obtained via a callback.

[0107] As can be seen from steps 401 to 405 above, loading and calling methods by generating classes, compared with the conventional key-value passing method, can achieve more accurate and secure verification based on the solution of this embodiment of the invention.

[0108] It should be noted that the above Figure 4 This is for validating routing parameters after enabling the functional components.

[0109] The following describes how to generate the corresponding route parameter binding Binder class (Compilation 2).

[0110] In one possible implementation, a binding class is created for each `@Router` variable routing target. This binding class automatically retrieves the value of each `@Param` variable from the routing parameters and automatically assigns the routing parameter value to the `@Param` variable. Furthermore, validation is performed using validator parameters before injection (i.e., assigning values ​​to member variables). The validation method is described above. Figure 4 The details of that will not be repeated here.

[0111] Based on the above solution, two sets of validation code for routing parameters are automatically generated: validation code before the page is opened and validation code after the page is opened. The code validation is more comprehensive and accurate, and can achieve complete validation without omissions. Even if the caller uses its own written code to open the page, it will still be subject to the parameter validation constraints of the validator.

[0112] Based on the above content and the same concept, embodiments of the present invention also provide a routing parameter verification device. See [link to related document]. Figure 5 This is a schematic diagram of the routing parameter verification device provided in an embodiment of the present invention. The routing parameter verification device 500 can be used to perform the above-described... Figures 1 to 4 The method shown in any embodiment can therefore achieve the beneficial effects of the above-described method embodiments. The routing parameter verification device can be a terminal device, such as a mobile phone or tablet computer. Exemplary embodiments of the terminal device include, but are not limited to, carrying... Or terminal devices using other operating systems. Figure 5 As shown, the routing parameter verification device may include: a declaration module 501, a first verification module 502, and a second verification module 503.

[0113] When the routing parameter verification device 500 is used to implement Figure 1The function of the method example shown is as follows: the declaration module 501 is used to declare the routing parameters to be verified and the verifier; the first verification module 502 is used to perform a first verification on the routing parameters through the verifier before opening the functional component; the second verification module 503 is used to generate parameter verification code according to the declared routing parameters and the verifier; if the first verification is successful, the second verification module 503 is used to open the functional component and perform a second verification on the routing parameters through the verifier.

[0114] In one possible implementation, the apparatus further includes a determining module for: determining the verification rules of the verifier; and determining that the routing parameter verification passes if the value of the routing parameter satisfies the verification rules.

[0115] In one possible implementation, the routing parameter corresponds to a validator, and the syntax rules used by the validator include: validator identifier: parameter list of the validator; or, the routing parameter corresponds to M validators, where M is an integer greater than 1; the syntax rules used by the M validators include: M validator identifiers connected by logical expressions: routing parameter list of the validator.

[0116] In one possible implementation, the declaration module 501 is specifically used to: declare the routing target corresponding to the routing parameters; the second verification module 503 is specifically used to: generate a routing constructor class for the routing target corresponding to the routing parameters, the routing constructor class being used to open the routing target; generate a calling method for the routing parameters in the routing constructor class; generate a calling method for the verifier in the calling method for the routing parameters; and call the verifier through the calling method to perform a second verification on the routing parameters.

[0117] In one possible implementation, the second verification module 503 is specifically configured to: for each of the declared verifiers, perform the following: parse the usage syntax rules of the verifier; obtain the identifier of the verifier and create an instance of the verifier; call the instance of the verifier and obtain the parameters of the verifier according to the identifier of the verifier; and verify the routing parameters according to the parameters of the verifier; the device further includes an acquisition module configured to: obtain a verification result, the verification result including whether the routing parameter verification passes or fails.

[0118] In one possible implementation, the device further includes a creation module for: creating a correspondence between functional components and routing addresses, wherein the routing parameters are parameters obtained when the functional components are checked in; and creating a correspondence between verifier identifiers and verifier types, wherein different types of verifiers correspond to different verification rules.

[0119] Based on the above content and the same concept, embodiments of the present invention also provide a routing parameter verification device. See [link to related document]. Figure 6 This is a schematic diagram of the routing parameter verification device provided in an embodiment of the present invention. The routing parameter verification device 600 can be used to perform the above-described... Figures 1 to 4 The method shown in any embodiment can therefore achieve the beneficial effects of the above-described method embodiments. For example... Figure 6 As shown, the routing parameter verification device may include a processor 601 and a memory 602. The memory 602 is used to store instructions executed by the processor 601, or to store input data required by the processor 601 to execute instructions, or to store data generated after the processor 601 executes instructions.

[0120] When the routing parameter verification device 600 is used to implement Figure 1 When the method is shown, the processor 601 is used to execute the functions of the above-mentioned declaration module 501, first verification module 502, and second verification module 503.

[0121] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software programs, implementation can be entirely or partially in the form of a computer program product. The computer program product includes one or more instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The instructions can be stored in a computer storage medium or transmitted from one computer storage medium to another. For example, the instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer storage medium can be any available medium accessible to a computer or a data storage device such as a server or data center that integrates one or more available media. The usable medium may be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape, magneto-optical disk (MO), etc.), an optical medium (e.g., CD, DVD, BD, HVD, etc.), or a semiconductor medium (e.g., ROM, EPROM, EEPROM, NAND flash memory, solid-state disk (SSD), etc.). Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, embodiments of this application may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, embodiments of this application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0122] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0123] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0124] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0125] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including both the preferred embodiments and all changes and modifications falling within the scope of the invention.

[0126] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A parameter verification method, characterized in that, Applied to a routing framework, the routing framework at least has the functionality to declare routing parameters and a validator, the validator being used to validate the routing parameters, the method comprising: Create a mapping relationship between functional components and route addresses, where the route parameters are the parameters obtained when the functional component is checked in; Create a mapping between validator identifiers and validator types, with different validator types corresponding to different validation rules; Declare the route destination and verifier corresponding to the route parameters; Before activating the functional components, the routing parameters are first verified by the verifier. If the first verification is successful, a route constructor class is generated for the route target corresponding to the route parameters. The route constructor class is used to open the route target. In the route constructor class, a method is created to generate the route parameters. For each validator in the declared list, execute: Parse the syntax rules for using the verifier; Obtain the identifier of the verifier and create an instance of the verifier; Invoke an instance of the verifier and obtain the verifier's parameters based on the verifier's identifier; The routing parameters are validated based on the parameters of the validator. Obtain the verification result, which includes whether the routing parameter verification passed or failed. The verifier is invoked through the aforementioned invocation method to perform a second verification on the routing parameters.

2. The method as described in claim 1, characterized in that, The first verification of the routing parameters by the verifier includes: Determine the verification rules for the verifier; If the value of the routing parameter satisfies the verification rule, the routing parameter verification is deemed successful. The verification rules include any one of the following: The values ​​of the routing parameters cannot be empty strings or null; The values ​​of the routing parameters fall within the first range; The string length or set size of the routing parameters is within the second range; The values ​​of the routing parameters are within the third range; The values ​​of the routing parameters must satisfy a regular expression.

3. The method as described in claim 2, characterized in that, The routing parameters correspond to a validator, and the syntax rules used by the validator include: validator identifier: the parameter list of the validator; or, The routing parameters correspond to M verifiers, where M is an integer greater than 1; The syntax rules used by the M validators include: M validator identifiers connected by logical expressions; and the parameter list of the validator.

4. The method according to any one of claims 1 to 3, characterized in that, If the routing parameter is a constant, before calling the parameter assignment method, the routing parameter is performed a second verification by the validator corresponding to the routing parameter. If the routing parameter is a non-constant, the verification rules of the verifier corresponding to the routing parameter are notified through method parameter prompts, and the routing parameter is verified a second time according to the prompted verification rules.

5. A parameter verification device, characterized in that, The parameter verification device includes a routing framework, which at least has the function of declaring routing parameters and a verifier, wherein the verifier is used to verify the routing parameters, and the device includes: A module is created to establish the mapping between functional components and routing addresses, where the routing parameters are the parameters obtained when the functional component is checked in; a module is also created to establish the mapping between verifier identifiers and verifier types, where different types of verifiers correspond to different verification rules. The declaration module is used to declare the routing target and verifier corresponding to the routing parameters; The first verification module is used to perform a first verification on the routing parameters through the verifier before opening the functional components; The second verification module is used to, if the first verification is successful, generate a route constructor class for the route target corresponding to the route parameters, the route constructor class being used to open the route target; generate a calling method for the route parameters in the route constructor class; for each of the declared verifiers, execute the following: parse the usage syntax rules of the verifier; obtain the identifier of the verifier and create an instance of the verifier; call the instance of the verifier and obtain the parameters of the verifier according to the identifier of the verifier; verify the route parameters according to the parameters of the verifier; obtain the verification result, the verification result including whether the route parameters pass the verification or fail the verification; and call the verifier through the calling method to perform a second verification on the route parameters.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program or instructions that, when executed by the parameter verification device, cause the parameter verification device to perform the method as described in any one of claims 1 to 4.

7. A computer device, characterized in that, include: Memory, used to store program instructions; A processor is configured to invoke program instructions stored in the memory and execute the method as described in any one of claims 1 to 4 according to the obtained program.

Images