Detailed Description
The technical solutions in the embodiments of the present disclosure will be clearly and completely described below with reference to the drawings in the embodiments of the present disclosure, and it is obvious that the described embodiments are only a part of the embodiments of the present disclosure, and not all of the embodiments. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments in the present specification without any creative effort shall fall within the protection scope of the present specification.
In order to solve the above technical problem, a form generation method according to an embodiment of the present specification is introduced. The form generation method is characterized in that an execution main body is form generation equipment, and the form generation equipment comprises a server, an industrial personal computer, a PC (personal computer) and the like. As shown in fig. 1, the form generation method may include the following implementation steps.
S110: receiving a form generation request; the form generation request comprises form definition information; the form definition information is used for describing a table structure of a form to be generated.
The form generation request is a request generated when a corresponding form needs to be acquired. The form generation request may be generated, for example, by a user when there is a need for a corresponding form, or may be generated by a corresponding computing device when there is a need for a corresponding form by a business processing system. The specific generation mode of the form generation request may be set based on the requirement of the actual application, and is not described herein again.
The form definition information is used to describe a table structure of the form to be generated, and may be, for example, whether the form includes a main table and a corresponding sub-table, a correspondence between the forms, a structure of the form itself, data included in the form, and the like. And in practical application, the form definition information is adjusted according to specific requirements.
S120: an initial template corresponding to the form generation request is obtained.
Upon receiving the form generation request, an initial template corresponding to the form generation request may be obtained. The initial template may be a template in a library of templates corresponding to the current request. The templates of a certain type are preset in the template library, the templates cover the overall requirements for the form, and the required templates can be obtained by adjusting the corresponding initial templates on the basis.
In some embodiments, the initial template comprises at least one sub-template; the sub-templates are used to distinguish different database scripts and/or front end frameworks.
In the system, a JAVA frame is set as a standard to distinguish different template frames, a plurality of sets of subframes are associated in one set of frames, and the subframes are mainly used for distinguishing scripts of different types of databases and different front-end frames.
In some embodiments, the initial template comprises at least one of a database script template, a code template, a page template, and a standard flow template. In connection with the above example, the template frame table is mainly used to record the definitions of different template frames and subframes in the system. The template table is a specific template definition under the template framework, and comprises information such as names, types, sub-types, hierarchical relations among the templates, file paths in an associated template file library and the like of the templates, and the hierarchical relations of the tree structures exist for the templates of the customized types. The file path herein points to a file directory or a single file due to different template types, for example, for a necessary and optional type of function template, only the package name of the service system needs to be updated, so that a corresponding template data points to a directory, and a control template in the customized template corresponds to a template file, so that a specific file is pointed to.
The template library is stored according to the theme of the main frame, and different frames are stored in different packages. As shown in fig. 2, the storage structure of a main frame is a storage structure of a main frame, and only one set of JAVA codes exists for one main frame, a plurality of different sets of front-end WEB codes may exist according to user preferences, and a plurality of different sets of database scripts and initialization codes may be configured according to different types of databases used, but only one set of WEB codes and one set of database scripts may be selected for use according to needs when in use.
The JAVA end code, the WEB page code, and the database script must be used in cooperation, for example, if "basic code + system management" in the JAVA code needs to be generated to simultaneously generate "public style and JS" in the WEB and "system management related page", the database needs to generate "system management related table structure and initialization script" according to the selected database.
For the customized service template, the front-end code and the back-end code need to be generated in a matching manner, for example, a single table template in a JAVA code frame and a single table template in the front-end template must be used in a matching manner at the same time, and the JAVA end codes of two types of multi-table templates in the page template can be realized by using the same code template because of the same back-end implementation manner. Thus, the binding of the collation will be done at design time by the subtype stored in the template table in the database.
The control template is common in the front template, so that the control template is integrally set to be consistent with the hierarchy of the single-table/multi-table template, and the subtype is set as the control. The control template data comprises the name of the control, the occupied page width and the corresponding template address. The control template is stored independently, which is beneficial to the expansion of the control, and the template can be selected more flexibly when the page code is generated.
S130: determining form recommendation parameters according to the form definition information; and the form recommendation parameters are used for constructing the structure and the type of the generated form based on the template.
After the form definition information is obtained, form recommendation parameters used for building and generating the structure and the type of the form based on the template can be determined according to the form definition information. Most of the parameters come from the database design files and the recommended values analyzed and calculated according to the database design files, a small amount of parameters which need to be manually input, such as system names, database information and other data, can be input in a system basic information module, and the information is effective for a certain service system for a long time, so that the effectiveness of form recommended parameters is ensured.
When determining the form recommendation parameters, analyzing the data structure of the form in advance, specifically, determining service module partition information, service table information and service field information according to the form definition information; the service module division information, the service table information and the service field information are used for respectively describing the structures and the association relations of the service module, the service table and the service field.
Specifically, as shown in fig. 3, after the database model file PDM is obtained, the data structure is analyzed to obtain template, table and field data, then the parameters necessary for the code are generated based on parameter recommendation, and the code generation is completed by combining the template library, the process design information and the system basic information, so as to finally obtain a complete code package.
The business module division information is mainly based on development specifications in a team, and for example, a table name may be required to start with "< module name abbreviation > _", and if a sub-module exists, the table name starts with "< module name abbreviation > __< sub-module name abbreviation > _". Based on the above specifications, rough module division can be performed by disassembling the prefix of the read service table name, and the module can be manually adjusted by a user if special conditions exist.
The business table data can obtain the name and annotation (generally, the Chinese name of the table) information of the table by reading the table structure information. And then determining whether the service table has a parent table according to the association relationship among the tables, and if so, recording the id of the parent table in the table. And after all the service table data are analyzed completely, generating a plurality of tree-shaped structure data divided according to the modules according to the conventional table structure condition of the form system.
The service field data is field information defined in each service table, exists in association with the service table, and can read information such as a field name, a comment, a field type, a field length, whether a primary key/a foreign key and the like from the PDM file.
When the acquisition of specific form recommendation parameters is realized, description can be carried out from two hierarchies of fields and tables in order to combine the form structure.
When the form recommendation parameters include field level recommendation parameters, the field level recommendation parameters may include at least one of data parsing data, field control data, field selection data, field query data, and field display data.
The field level parameters required for code generation need to determine the display conditions of the control template to be selected, whether to fill in the control template, whether to inquire conditions, whether to display lists and the like, besides the basic data acquired in the data analysis function. The selection of the control template is difficult to determine the type of the control template by using a fixed rule due to the most selectable range and the most complicated situation. Especially when the control type is a selection box, it is also necessary to determine the acquisition source of the data, which may be a dictionary table, or may be associated data of other functions, such as a selection box of a department, a country, etc.
In order to reduce the coupling degree with the back-end code when the data option is obtained and reduce the complexity of association between the templates, the page control in each set of templates in the automatic code generation system of the embodiment of the present specification all adopts an asynchronous mode if the option data needs to be obtained, that is, the data is obtained in a mode of a page JS script, and only the URL and the parameters of the data obtained by the front-end JS may be different. When the control template type is determined, the control template needs to be divided more finely by considering the above situations.
In the present system, most of the judgment of all options and attributes is the judgment of discrete data, and the conditions and the final results are basically enumerable. The decision tree algorithm in the large algorithms of machine learning is the most convenient and clear algorithm for processing discrete variables, so the system adopts the decision tree algorithm to solve the problem during rule calculation. The character string type in all field types is the most complex type of judgment, the classification to which the field of the character string type is divided is not enough to be distinguished by simply depending on the basic information obtained from the database model file, and the decision tree constructed when the basic information is used for calculating the classification of the control is the type with the highest repetition degree.
Correspondingly, when determining the form recommendation parameters from the field level, the feature attributes corresponding to the field level recommendation parameters may be determined first; the characteristic attributes are used for describing types and structures of field-level recommended parameters, at least one candidate characteristic attribute value corresponding to the characteristic attributes is generated by using a decision tree algorithm, and finally a target characteristic attribute value is selected from the candidate characteristic attribute values based on the application effect of the candidate characteristic attribute values; the target feature attribute values are used for constructing an application template.
Specifically, as shown in fig. 4, a schematic diagram of feature attribute acquisition IS shown, wherein, in order to obtain more accurate control selection, contents of database design files and development specifications of a plurality of previous systems may be compared, and it IS found that there are some similarities in usage scenarios for different TYPEs of controls, for example, most dictionaries are of the same name as a field or are of a table name. While the business requirements of each organization are different, there are many common dictionaries that are needed by all systems to assist in computing features, such as gender, presence, province, academic calendar, academic degree, etc. Therefore, we decided to add feature attributes in a way that splits field names and performs dictionary matching.
Taking the ORACLE database as an example, ORACLE requires that field names may not exceed 30 characters, each field is usually composed of a plurality of words, each word is separated by "_", assuming that the average length of the words composing the field name is 5, the number of words composing a field name is basically unlikely to exceed 6, and the condition that we need to match the calculation as a feature may be one or several words at the beginning or at the end, and the field names need to be arranged in the forward order and the reverse order after being divided by "_". Considering that the number of words composing a field is generally 2-4, and the possibility of a complete field name is too high, there is little possibility of being a feature, then the words that may be a feature are generally only 1-2 words at the beginning and end. Therefore, we need to split the field name by "_" and store 2 words at the beginning and end of the field in order and in reverse order into the history record when generating the code, and the words are used as the characteristic attributes.
For the type of the selection box which is most difficult to judge, the data source of the selection box can be roughly divided into two cases, namely dictionary data reading and business data (or common functions) reading according to the development experience at ordinary times and the project actual conditions. The selection frame for reading the service data can be realized by adding the control template type, and the data reading function is directly written in the template, so that the condition that the URL of the data needs to be obtained through calculation is avoided. Meanwhile, because the business data needs to be read, similar naming rules exist on the field names, and the used control can be confirmed through the split field names.
For a selection box of a dictionary type, a complete match or a partial match between a field name and a type in a dictionary table generally occurs according to development habits, which is an important characteristic that whether the field is a selection box or not can be judged. Therefore, some common dictionaries such as gender, certificate types and the like can be stored in a dictionary table of the code generation system in advance, other service dictionaries such as codes can be acquired before generation, a dictionary import function import system provided by the system can be used for data matching, and if no dictionary value can be automatically generated by using a certain rule. Therefore, the fields for generating the dictionary rules are specially added when the template table is designed, and the generation of the service dictionary is adapted. Considering that dictionary data can provide some auxiliary characteristic attributes for the system in a mode of matching and calculating with field names, an attribute matching with the dictionary data is set for each of the field names and the split forward and reverse order field words and is used as the characteristic attribute to participate in the calculation of the decision tree.
In generating the candidate attribute values using the decision tree, specifically, the implementation of the recommendation value may be implemented using a cart algorithm. The process of generating the corresponding recommendation value using this algorithm is explained below.
The CART algorithm is an algorithm for constructing a binary decision tree by calculating a Gini index, and for multi-value attributes, the CART algorithm constructs a binary attribute in a merging mode and calculates the minimum Gain value to split. For the attributes of the first two words of the positive order and the negative order of the field, which may have dozens of or hundreds of different possibilities, if the attributes are calculated in a random combination mode, the possibility that an attribute with n values has a binary combination type of + + … … + (if n is a base number, and n/2 is replaced by a median value) is provided, and the calculation process is rapidly increased along with the increase of the values of the attributes.
Since the Gini index itself is an index calculated by purity, while for the word attributes of the positive and negative order of the field, there is a high probability that the hit rate of some words is 0 and the hit rate of some words is 100%, the Gini index for both types of data is 0, but if they are mixed, the Gini index is made higher instead. Therefore, the data with high hit probability are put together more reasonably during classification, and the Gini indexes calculated according to two attribute values with the same probability are sorted under the condition that the probabilities are the same. For these values with a hit probability of 0 or 1, a classification can be considered by default.
Therefore, when the attribute A has n possible values, m values have hit probability of 0, and k values have hit probability of 1, the number of times of comparing the binary calculated Gain values is only n-m-k times, which is far lower than the number of times of randomly dividing the n values.
In addition, because the decision tree is a single output model, the final output result is actually two possibilities of yes and no, and for the requirement of the system, the output result is required to be mostly more than two possibilities of yes and no, so that the final result label can be calculated only in sequence and singly. And for a specific label value, the condition that the value is equal to the value required by the user is considered as 'yes', otherwise, the condition is considered as 'no'. The generation steps of the CART decision tree are shown in the single-label CART decision tree generation step diagram of FIG. 5. For each label value, a default priority and a conventional priority are set, only one label is set in the default level, a text box is set in the default value of the page control, and if all decision trees output a 'no' result or the decision trees cannot match any branch, a recommended value given by the system is a 'text box'. For other conventional label values, we calculate the number of the labels in turn from large to small.
The following describes selection of target feature attributes with reference to fig. 6, where fig. 6 is a decision tree model diagram generated according to control types, and according to a calculation result, it is found that a result generated by a decision tree is not performed according to an order in which the decision tree is originally classified manually, but rather, attributes of words split by name added to distinguish a selection box from a text box without special marks are changed into main attributes of the classification, and even a decision tree generated by a part of types of controls may complete classification of the control type only by reversing the attribute of the first word. And finally, splicing the decision tree generation results according to the same characteristic attributes to obtain a multi-classification decision tree model. Here, the "text box" mentioned earlier is not in the category of the decision tree, and is a default option, so when a new sample is input to find the corresponding template tag, if any classification is not met, the "text box" is output.
The model of fig. 6 is a modified model structure, and when the history generation data is modified, it is possible to generate new modification according to the actual situation of the data. However, because the main classification of the model is not the field type in imagination but the word in the field naming, the model is established on the basis that the data structure is designed to have a sufficiently consistent naming format and habit, and the more similar naming habit, the higher the accuracy of generating parameters of the system is, so that the system can have better application effect when the system is used for a long time and accumulates enough data. Once the data structure design adopts some unconventional naming modes, especially nonsensical naming modes, such as "COL _ 1", "COL _ 2", etc., the accuracy of the system may be extremely reduced, which is the situation that the system should avoid when in use.
For other attributes such as whether to fill in, whether to inquire conditions, whether to display lists, etc., the decision tree corresponding to these attributes is also constructed in a manner similar to the above decision tree generation manner, but different settings are provided according to circumstances when setting default values. For the case of having to fill the tag, we consider most of the fields to be necessarily filled and less to be the unnecessary data, so we consider the value to be "yes" if the field in the validation data does not match any branch of the decision tree construction result. And whether the query condition is opposite to whether the list is displayed, its default value should be "no".
When the form recommendation parameter includes a form-level recommendation parameter, the tag recommendation parameter may include a template type of the form, where the form recommendation parameter corresponds to at least one attribute of a parent form of the same module, a child form of the same module, a number of fields displayed, and a business system to which the form recommendation parameter belongs.
When parameter determination is realized based on the table-level recommended parameters, the table-level recommended parameters can be determined based on the existence condition of the foreign key of the data table; and the existence condition of the foreign key is used for determining the association relationship between the business table and the foreign key of the table of the public template.
Specifically, the mode of generating the code can be divided into a single table and a multi-table mode according to the use condition of the code template, but since the template of the single table mode can be actually regarded as a main table template without sub-tables, all table-level templates can be divided into two types, namely a main table template and a sub-table template.
In a manually differentiated manner, the master table template is well-defined, as long as the table does not have a parent table, and the actual data determination condition should be that no foreign key exists for the table. However, since the business table may have an association relationship with some public data tables, and this association relationship is also an important characteristic attribute when the field-level parameters are generated, this foreign key association relationship must be recorded in the data model file. Also because of this, the table-level feature attribute setting is "whether a parent table of the same module exists" and "whether a child table of the same module exists", and the setting of the "same module" is to distinguish the external key association relationship between the service table and the table of the common module.
For the sub-table template, as long as a parent table of the same module exists, the sub-table template is considered to be a sub-table, only the sub-table template has multiple types, and the type to be taken needs to be judged according to the attributes of the table. According to the condition description of the sub-table template type in the requirement, three page display conditions of several sub-tables are commonly found in the form system at present, and the type of the sub-table template is determined according to whether the sub-table exists and the number of the display fields of the sub-table. The same system needs to ensure the uniformity of page styles in the system, so the main judgment standard of the system changes along with the change of the system, the business system which the same system belongs to is also used as one of the characteristic attributes to calculate during calculation, but the business system does not participate in the construction of a decision tree, and the significance of the decision tree is to determine the value range of historical data during the calculation of a parameter recommendation rule.
S140: combining the form recommendation parameters with the initial template to obtain an application template; the application template includes a program for generating a form.
And after the form recommendation parameters are obtained, combining the form recommendation parameters with the initial template to obtain an application template. The application template is the template meeting the current form generation requirement. The program in the template, i.e., the corresponding executable code, can complete the generation of the final form.
Specifically, the program included in the application template includes at least one of an underlying framework, a common function, a service code, and a database initialization script. The bottom layer frame is used for describing a frame set by a program, the public function is used for adjusting the function realized by the program, the service code can complete the execution of the corresponding service, and the database initialization script is used for realizing the initialization function of the database. The actual application can be set according to specific requirements, which is not limited to this.
As shown in FIG. 7, different code generation modes implemented based on the application template include a complete mode, a module (table) generation mode and a field generation mode.
The complete mode refers to that the code generation system completely generates a whole set of system service codes according to the existing parameters, the complete mode refers to that the code generation system comprises a bottom layer framework, a public function, service codes, corresponding database initialization scripts and the like, the complete mode refers to that a newly-built system is suitable, and a set of operable code environment can be quickly built by using the generated codes.
The module (table) generation mode is a mode generated according to a module or a table selected by a user, is suitable for being used when a new module is built, and is suitable for being used when a field is adjusted by an existing module under a specific condition.
The field generation mode is to generate only the fragment code file related to the field, such as BO class definition code of JAVA, control of the front end, code of JS, and the like.
Although the system provides a plurality of different generation modes, the generation mode of the system adopts a template nesting mode to generate codes due to the consideration of the setting of the templates and the parameters, so the generation mode of the system adopts a top-down mode, and taking a complete mode as an example, the system generates a necessary frame code and a function code of system management firstly, then generates an optional function code, and then generates corresponding codes in sequence from a main table to a sub-table and from the table to a field according to a service module.
In some embodiments, in order to ensure the generating effect of the form, the form generating process can be adjusted artificially. In the process of obtaining the application template, a managed user can input manual adjustment parameters for specifying the effect of manually desiring to adjust the form, and after receiving the manual adjustment parameters, the application template can be obtained by combining the manual adjustment parameters, the form recommendation parameters and the initial template. The specific process of setting the manual adjustment parameters may be set based on the requirements of practical applications, and is not described herein again.
S150: and generating a target form corresponding to the form generation request based on the application template.
After the application template is obtained, the target form can be generated by using the application template, wherein the form frame can be generated by using the application template, the main form data corresponding to the form frame is obtained, and finally the main form data is filled into the form frame to obtain the target form.
The above steps are further explained with reference to the flowchart of the form page generation in fig. 8, when the form page is generated, a main form data is obtained first, a main form template is obtained from a template library, a frame of the form page is generated, then all field data under the form are traversed, a field-level page control is generated, and the generated control is written back to the frame of the main form page. And field controls are generated according to the field sequence, if the field control type is not 'no display' or 'hidden frame', the field controls generate the < field name > according to the control length set in the control template: < controls > "format code. Because the existing framework basically adopts a self-adaptive mode, both Bootstrap and Vue adopt a split mode to control the display of the control, a mode of one row of 3 columns of data is adopted by default to generate the page code when the code is generated, and if the control needs a long space, the number of columns which need to be occupied is recorded in the control template to control the page layout. In order to control the beautiful layout, the length of the current control is set to be a single column or a whole row.
When the target form is obtained, a main table may be generated based on the form frame and the main table data, and then the sub table is generated by using the application template under the condition that the main table corresponds to the sub table.
And after the main table part codes are generated, determining whether the codes related to the sub-tables need to be generated according to whether the main table has the sub-tables or not.
When the list page is generated, the list page is generated according to the conditions in the field parameters of the main table and whether the two parameters are displayed in a list or not, and the list page is generated according to the field sequence. And the control in the condition is acquired from the template library according to the control type corresponding to the condition field and backfilled to the corresponding position of the list page.
If the main table selects the binding process parameter, a submit button and a corresponding page submit function should be generated at the same time. At the moment, whether a submission page needs to be generated or not can be judged according to whether the first task node in the process is submitted to a person or a user group, if so, the page is displayed after a submission button in the list is clicked, the user option can be selected and the process configuration setting content pointing to the first task node is pointed, otherwise, the submission button in the direct list directly submits data to a background starting process.
In the framework template, a monitoring mode is adopted for data synchronization between the flow module function and the service function, the monitoring program mainly realizes the functions of state switching and the like in the flow circulation process, the monitoring program needs to be set for each node during flow configuration, and then the service data synchronization is carried out according to the configured monitoring program during flow circulation.
The system can generate basic process configuration data through analysis according to the BPMN process design file acquired in the process definition function. The system generates a workflow node configuration table data for each task node, and generates an audit result configuration table data for each branch according to the outflow branch condition of the task node. Meanwhile, the system prepares a standard monitor template for the process module, and can download the standard monitors from the system and put the standard monitors into codes of the service system for use after the process configuration is finished. If the flow to be generated is selected before the code is generated, the standard monitoring program is generated together with the module code.
The binding of the workflow and the service data mainly needs two aspects, namely, the binding service form is displayed for a user to use and the service data is correspondingly modified in the process of flow circulation. Different monitoring programs are bound according to different modules of the bound business table during process design, and the process configuration function is to distribute the business table for each task node of the process, set an audit interface option and confirm the state of the business data when different operation results are selected.
Therefore, while the target form is generated, the form can be configured for the convenience of utilization of the form in the subsequent steps. In some embodiments, configuration parameters corresponding to the target form may be determined; the configuration parameters are used for determining the display content and the operation authority of the target form.
The configuration process is further described below with reference to fig. 9, wherein the main task of the form configuration step is to determine what forms need to be displayed for this task and what the operation authority should be.
Because the service codes in the system are all generated by the code automatic generation system, all form pages in the same service system must have the same URL construction mode. In the existing framework, a complete URL of a service form is composed of a form standard path, primary key information, and an operation type, where the operation type may only include three conditions of modification, viewing, and auditing in a process of a flow, and the auditing at this time indicates that a user of the task node may have a data modification permission higher than a modification permission.
Therefore, the operation type is a parameter which needs to be specified by a user in the process configuration function and is also a parameter which needs to be automatically recommended in the system.
In other embodiments, an operation type corresponding to the target form may be determined; the operation type is used for representing the type of the operation of the target form for the user; and setting an operation control in the target form based on the operation type.
Still referring to fig. 9, the configuration of the operation result is to set the control required for auditing corresponding to the operation result and the state of the process according to the branch situation defined by the flowchart.
There are three options for the user selection box type: none, radio boxes, and multiple boxes. Generally, no corresponding next link is the case of specifying a user group, and therefore, it is not necessary to specify who the next operation user is. The next link corresponding to the radio box is a case of a designated user, the designated user generally needs to be screened by a user group, in some cases, the screening may need to increase the conditions of the department to which the user belongs (for example, it is necessary to say that selecting a foreign secretary in the process of visiting and reporting is a foreign secretary belonging to the group reporting department), and in this case, the designated department needs to obtain the value of which field of the business form. And the multi-selection box indicates that the next link is a node to be signed, the user multi-selection box can be selected only if the operation result is the sign-meeting condition, and the user screening rule of the multi-selection box is the same as that of the radio box.
The process state is modified by the monitoring program after the user submits the process when selecting the result, which is an important configuration for the user to feel that the service data and the process are an integral whole. This parameter can be associated by the name of the task node because the data in the same task node should have the same current state no matter what the task node is. Therefore, the names of the task nodes can be considered to exist in the same state as the business data, after the task nodes of the process are read, the corresponding state dictionary is found according to the associated table names, and the task node names existing in the process are merged into the state dictionary of the table. The state that needs to be set at this time is the ID of the next task node to which the branch flows.
The implementation process of the above method is further supplemented with an automatic code generation system, which is specifically implemented in conjunction with fig. 10, wherein, as shown in fig. 10, the automatic code generation system mainly includes a basic function module and a code analysis and generation module.
The basic function module mainly comprises three parts of template management, data dictionary management and rule management.
Template management is the most important part of the underlying functionality and is also the basis for the code generation functionality. The template management function is mainly used for maintaining code templates (including database scripts, JAVA code templates, page templates and standard process templates) extracted by users, including information such as the content of the templates, the relationship among the templates, the types of the templates and the like. Template types are very important parameters in the automatic code generation system designed by the method, and a multi-level classification structure is arranged in the system to distinguish different types of templates, and the classifications play an important role in the subsequent code generation process.
Data dictionary management is mainly to provide auxiliary features for subsequent template parameter calculation recommendations. And the data management function provides standard dictionary template downloading for the demand personnel to inquire the service dictionary required by the system for the service user. Meanwhile, dictionary content recorded by a standard template can be imported, and a user is allowed to upload a dictionary conversion script in template management, and the dictionary content in the code automatic generation system is imported into dictionary tables of different service databases through the script.
Rule management is mainly used to make some adjustments in computational parameters to automatically generated parameter rules. After the system stably operates, no manual intervention is needed.
The code analysis and generation module is divided into three parts of service system management, code generation and process management.
The service system management is mainly used for registering basic information of the service system, such as system name, project name, database information, selected template theme, selected optional functions and the like. The code automatic generation system designed by the text is a system capable of connecting multiple data sources, can be connected with development environment databases of various systems through database information set by a service system, directly runs generated database scripts, and can be opened according to needs.
The code generation module is divided into three submodules of data structure analysis, parameter recommendation and service code generation. The data structure analysis is mainly realized by reading a database definition file uploaded by a user, identifying a table structure in the file, classifying a service table into a plurality of modules by table name prefixes according to a development standard convention, and recording specific information in the service table and fields thereof. And the parameter recommendation function compares the data recorded by the data structure analysis with the historical generation data to generate corresponding recommendation parameters according to rules calculated by a decision tree algorithm. The service code generating function calls the template selected by the service system according to the parameters and the data structure, and generates the required service code according to a certain rule.
The process management module is divided into three submodules of process definition, process configuration generation and process migration. The flow definition function provides a visual flow editing interface associated with the business module for a user, when the flow is created, the flow is generated according to a standard flow template selected by the system, and the user can automatically adjust or directly upload the existing flow definition file (BPMN2.0 file) on the basis. The process generation function comprises the generation of process approval interface configuration data and the generation function of standard process monitoring codes. The process migration function is used for migrating the edited process definition and configuration data to a test or production environment for use.
In this example, the system data is stored in a manner of combining a file directory and a database, and the template file is stored in the file directory of the template library according to the hierarchical structure of the template, so that the template generation effect required to be debugged in the system debugging and using processes can be conveniently used.
Based on the above description of the embodiment and the scenario example, it can be seen that, in the above method, after receiving a form generation request, an initial template corresponding to the form generation request is obtained first, then, a form recommendation parameter corresponding to the form generation request is determined according to form definition information included in the request, and after obtaining an application template by combining the form recommendation parameter and the initial template, a target form corresponding to the form generation request is generated by using a program for generating a form included in the application template. According to the method, on the basis of the initial template, the corresponding form recommendation parameters are generated according to the requirements of the form, so that the required target form can be generated by combining the form recommendation parameters with the template, the diversified requirements for the form are met, the user can timely and effectively acquire the required form, the execution of the service is facilitated, and the use experience of the user is improved.
A form generation apparatus according to an embodiment of the present specification is introduced based on the form generation method corresponding to fig. 1. The form generation device is arranged on the form generation equipment. As shown in fig. 11, the form generation apparatus includes the following modules.
A form generationrequest receiving module 1110, configured to receive a form generation request; the form generation request comprises form definition information; the form definition information is used for describing a table structure of a form to be generated.
An initialtemplate obtaining module 1120, configured to obtain an initial template corresponding to the form generation request.
The form recommendationparameter determining module 1130 is configured to determine a form recommendation parameter according to the form definition information; and the form recommendation parameters are used for constructing the structure and the type of the generated form based on the template.
An applicationtemplate obtaining module 1140, configured to combine the form recommendation parameter with the initial template to obtain an application template; the application template includes a program for generating a form.
A targetform generation module 1150 for generating a target form corresponding to the form generation request based on the application template.
Based on the form generation method corresponding to fig. 1, an embodiment of the present specification provides a form generation device. As shown in fig. 12, the form generation apparatus may include a memory and a processor.
In this embodiment, the memory may be implemented in any suitable manner. For example, the memory may be a read-only memory, a mechanical hard disk, a solid state disk, a U disk, or the like. The memory may be used to store computer program instructions.
In this embodiment, the processor may be implemented in any suitable manner. For example, the processor may take the form of, for example, a microprocessor or processor and a computer-readable medium that stores computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, an embedded microcontroller, and so forth. The processor may execute the computer program instructions to perform the steps of: receiving a form generation request; the form generation request comprises form definition information; the form definition information is used for describing a form structure of a form to be generated; acquiring an initial template corresponding to the form generation request; determining form recommendation parameters according to the form definition information; the form recommendation parameters are used for constructing and generating the structure and the type of the form based on the template; combining the form recommendation parameters with the initial template to obtain an application template; the application template includes a program for generating a form; and generating a target form corresponding to the form generation request based on the application template.
It should be noted that the form generation method, apparatus and device may be applied to the technical field of artificial intelligence, and may also be applied to other technical fields except the technical field of artificial intelligence, which is not limited to this.
In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry that implements the logical method flows can be readily obtained by merely slightly programming the method flows into an integrated circuit using the hardware description languages described above.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.
From the above description of the embodiments, it is clear to those skilled in the art that the present specification can be implemented by software plus the necessary first hardware platform. Based on such understanding, the technical solutions of the present specification may be essentially or partially implemented in the form of software products, which may be stored in a storage medium, such as ROM/RAM, magnetic disk, optical disk, etc., and include instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to execute the methods described in the embodiments or some parts of the embodiments of the present specification.
The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to the partial description of the method embodiment.
The description is operational with numerous first or special purpose computing system environments or configurations. For example: personal computers, server computers, hand-held or portable devices, tablet-type devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
This description may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
While the specification has been described with examples, those skilled in the art will appreciate that there are numerous variations and permutations of the specification that do not depart from the spirit of the specification, and it is intended that the appended claims include such variations and modifications that do not depart from the spirit of the specification.