A form generation method, device and equipment

Abstract

This specification provides a form generation method, apparatus, and device, applicable to the field of artificial intelligence technology. The method includes: receiving a form generation request; the form generation request containing form definition information; the form definition information describing the table structure of the form to be generated; obtaining an initial template corresponding to the form generation request; determining recommended form parameters based on the form definition information; the recommended form parameters being used to construct the structure and type of the generated form based on the template; combining the recommended form parameters with the initial template to obtain an application template; the application template including a program for generating the form; and generating a target form corresponding to the form generation request based on the application template. This method meets diverse form requirements, enabling users to obtain the required forms promptly and effectively, facilitating business execution and improving user experience.

Description

Technical Field

[0001] The embodiments in this specification relate to the field of artificial intelligence technology, and in particular to a form generation method, apparatus, and device. Background Technology

[0002] Forms are a crucial module for data collection and display. In practical applications, many systems rely on forms to facilitate data flow. Consequently, the established form formats enable various business processes and meet diverse office needs.

[0003] Currently, when using forms to execute business logic, the process often involves a single form and combining form fields to support the business logic. However, as business complexity increases, the amount of business content executed by the system also gradually increases. The code generated based on the above approach often features multiple business modules with low coupling, which places high demands on the rapid and flexible generation of code. Therefore, the ability to quickly and flexibly obtain the corresponding forms based on current form generation requirements is of great significance. Thus, there is an urgent need for a method that can flexibly and effectively generate corresponding forms based on form requirements. Summary of the Invention

[0004] The purpose of the embodiments in this specification is to provide a form generation method, apparatus, and device to solve the problem of how to flexibly and effectively generate corresponding forms for form requirements.

[0005] To address the aforementioned technical problems, embodiments of this specification provide a form generation method, comprising: receiving a form generation request; the form generation request containing form definition information; the form definition information describing the table structure of the form to be generated; obtaining an initial template corresponding to the form generation request; determining recommended form parameters based on the form definition information; the recommended form parameters being used to construct the structure and type of the generated form based on the template; combining the recommended form parameters with the initial template to obtain an application template; the application template including a program for generating the form; and generating a target form corresponding to the form generation request based on the application template.

[0006] This specification also proposes a form generation device, comprising: a form generation request receiving module for receiving a form generation request; the form generation request includes form definition information; the form definition information describes the table structure of the form to be generated; an initial template acquisition module for acquiring an initial template corresponding to the form generation request; a form recommendation parameter determination module for determining form recommendation parameters based on the form definition information; the form recommendation parameters are used to construct the structure and type of the generated form based on the template; an application template acquisition module for combining the form recommendation parameters with the initial template to obtain an application template; the application template includes a program for generating the form; and a target form generation module for generating a target form corresponding to the form generation request based on the application template.

[0007] This specification also proposes a form generation device, including a memory and a processor; the memory is used to store computer program instructions; the processor is used to execute the computer program instructions to implement the following steps: receiving a form generation request; the form generation request includes form definition information; the form definition information is used to describe the table structure of the form to be generated; obtaining an initial template corresponding to the form generation request; determining recommended form parameters based on the form definition information; the recommended form parameters are used to construct the structure and type of the generated form based on the template; combining the recommended form parameters with the initial template to obtain an application template; the application template includes a program for generating the form; and generating a target form corresponding to the form generation request based on the application template.

[0008] As can be seen from the technical solutions provided in the embodiments of this specification above, after receiving a form generation request, the embodiments of this specification first obtain an initial template corresponding to the form generation request, then determine the corresponding recommended parameters based on the form definition information contained in the request, and obtain an application template by combining the recommended parameters with the initial template. Finally, the application template contains a program for generating forms to generate the target form corresponding to the form generation request. Based on the initial template, the above method generates corresponding recommended parameters according to the form requirements, thereby enabling the generation of the required target form using the recommended parameters combined with the template. This satisfies diverse form requirements, allowing users to obtain the required forms promptly and effectively, facilitating business execution and improving the user experience. Attached Figure Description

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

[0010] Figure 1 This is a flowchart illustrating a form generation method according to an embodiment of this specification;

[0011] Figure 2 This is a schematic diagram of the structure of a form generation system according to an embodiment of this specification;

[0012] Figure 3 This is a schematic diagram of the structure of a template library according to an embodiment of this specification;

[0013] Figure 4 This is a schematic diagram illustrating a code generation process based on form generation, as described in an embodiment of this specification.

[0014] Figure 5 This is a schematic diagram illustrating one embodiment of feature attribute acquisition in this specification.

[0015] Figure 6 This is a schematic diagram of a decision tree generation process according to an embodiment of this specification;

[0016] Figure 7 This is a schematic diagram of the structure of a decision tree model according to an embodiment of this specification;

[0017] Figure 8 This is a schematic diagram of a code generation process according to an embodiment of this specification;

[0018] Figure 9 This is a schematic diagram illustrating a process for generating a form page according to an embodiment of this specification;

[0019] Figure 10 A flowchart illustrating the code generation function for a process configuration feature in an embodiment of this specification;

[0020] Figure 11 This is a block diagram of a form generation device according to an embodiment of this specification;

[0021] Figure 12 This is a structural diagram of a form generation device according to an embodiment of this specification. Detailed Implementation

[0022] The technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0023] To address the aforementioned technical problems, this specification introduces a form generation method according to an embodiment. The execution entity of the form generation method is a form generation device, which includes, but is not limited to, servers, industrial control computers, and PCs. Figure 1 As shown, the form generation method may include the following specific implementation steps.

[0024] S110: Receive a form generation request; the form generation request contains form definition information; the form definition information is used to describe the table structure of the form to be generated.

[0025] A form generation request is a request generated when a form needs to be retrieved. This request can be generated by a user when they require a form, or by a computing device when its business processing system requires a form. The specific method for generating this form generation request can be configured based on the actual application requirements, and will not be elaborated upon here.

[0026] Form definition information describes the table structure of the form to be generated. This includes, for example, whether the form contains a main table and corresponding sub-tables, the relationships between forms, the form's own structure, and the data it contains. In practical applications, this form definition information is adjusted according to specific requirements.

[0027] S120: Obtain the initial template corresponding to the form generation request.

[0028] Upon receiving a form generation request, you can first obtain the initial template corresponding to that request. This initial template can be a template from the template library that corresponds to the current request. The template library contains pre-set templates of certain types that cover the overall requirements for forms. By adjusting the corresponding initial template, you can obtain the desired template.

[0029] In some implementations, the initial template includes at least one sub-template; the sub-template is used to distinguish different database scripts and / or front-end frameworks.

[0030] This system uses the JAVA framework as the standard to distinguish different template frameworks. Each framework is associated with multiple sub-frameworks. The sub-frameworks are mainly used to distinguish scripts for different types of databases and different front-end frameworks.

[0031] In some implementations, the initial template includes at least one of a database script template, a code template, a page template, and a standard process template. Referring to the above example, the template framework table is mainly used to record the definitions of different template frameworks and sub-frameworks in the system. The template table contains the specific template definitions under the template framework, including the template name, type, subtype, hierarchical relationship between templates, and file paths in the associated template file library. Customized templates have a tree-like hierarchical structure. The file path here will point to a directory or a single file depending on the template type. For example, for required and optional function templates, since only the package name of the business system generally needs to be updated, the corresponding template data points to a directory, while the control template in a customized template corresponds to a template file, thus pointing to a specific file.

[0032] The template library is stored according to the main framework theme, and different frameworks are stored in different packages. For example... Figure 2 As shown, this is the storage structure of a main framework. There is only one set of JAVA code for a main framework. Depending on the user's preferences, there may be multiple sets of different front-end WEB code. Depending on the type of database used, multiple sets of different database scripts and initialization code can be configured. However, when using it, only one set of WEB code and database script can be selected according to the requirements.

[0033] The Java code, web page code, and database scripts must be used together. For example, if the Java code generates "basic code + system management", the web page code needs to generate "common styles and JS" and "system management related pages" at the same time. The database needs to generate "system management related table structure and initialization scripts" based on the selected database.

[0034] For customized business templates, there are situations where front-end and back-end code need to be coordinated during generation. For example, a single-table template in the Java code framework and a single-table template in the front-end template must be used in pairs. Similarly, two types of multi-table sub-templates in a page template can use the same code template in the Java side because their back-end implementations are the same. Therefore, during the design phase, the binding relationship will be established by using the sub-types stored in the template table in the database.

[0035] Since control templates are common across front-end templates, their overall hierarchy is set to match that of single-table / multi-table templates, with the subtype set to "control". The control template data includes the control's name, page width occupied, and the corresponding template address. Storing control templates separately facilitates control expansion and allows for more flexible template selection when generating page code.

[0036] S130: Determine recommended form parameters based on the form definition information; the recommended form parameters are used to construct the structure and type of the generated form based on the template.

[0037] After obtaining the form definition information, recommended form parameters can be determined based on this information. These recommended parameters are used to construct the structure and type of the generated form based on the template. Most of these parameters come from the database design file and recommended values ​​calculated based on the database design file. A small number of parameters that must be manually entered, such as the system name and database information, can be entered in the system's basic information module. This information is valid for a long time for a specific business system, thus ensuring the validity of the recommended form parameters.

[0038] When determining the recommended parameters for a form, the data structure of the form can be parsed in advance. Specifically, the business module division information, business table information, and business field information can be determined based on the form definition information. The business module division information, business table information, and business field information are used to describe the structure and relationship of the business modules, business tables, and business fields, respectively.

[0039] Specifically, such as Figure 3 As shown, after obtaining the database model file PDM, the template, table and field data are obtained by parsing the data structure. Then, based on parameter recommendations, the necessary parameters for the code are generated. Combining the template library, process design information and system basic information, the code is generated and finally a complete code package is obtained.

[0040] The business module division information is mainly based on the team's development specifications. For example, table names can be required to begin with "<module name abbreviation>_", and if there are submodules, then the table names can begin with "<module name abbreviation>_<submodule name abbreviation>_". Based on these specifications, a rough module division can be performed by breaking down the prefixes of the read business table names. In special cases, the modules can be manually adjusted by the user.

[0041] Business table data can be obtained by reading the table structure information to retrieve the table name and comments (usually the table's Chinese name). Then, based on the relationships between tables, it is determined whether the business table has a parent table; if so, the parent table's ID is recorded in that table. After all business table data has been analyzed, following the standard table structure of form-based systems, multiple tree-structured data points divided by module will be generated.

[0042] Business field data consists of field information defined in each business table. It exists in relation to the business table and can be read from the PDM file, including field name, comments, field type, field length, and whether it is a primary key / foreign key.

[0043] When retrieving specific form recommendation parameters, in order to integrate them with the form structure, they can be described from two levels: fields and tables.

[0044] When the form's recommended parameters include field-level recommended parameters, the field-level recommended parameters may include at least one of the following: data parsing data, field control data, field selection data, field query data, and field display data.

[0045] In addition to the basic data obtained from the data parsing function, the field-level parameters required during code generation also need to determine the appropriate control template, whether it is required, whether it has query conditions, and whether it should be displayed as a list. Among these, the selection of control templates is the most complex and has the widest range of options, making it difficult to determine the type of control template using fixed rules. Especially when the control type is a selection box, it is also necessary to determine the source of the data, which could be a dictionary table or related data from other functions, such as selection boxes for departments or countries.

[0046] To reduce the coupling between the data selection process and the backend code, and to alleviate the complexity of inter-template relationships, in the code automatic generation system of this specification, page controls in each template retrieve option data asynchronously, i.e., through page JavaScript. Only the URL and parameters for data retrieval in the frontend JavaScript may differ. When determining the control template type, the above considerations should be taken into account to further refine the control template classification.

[0047] For this system, most of the options and attribute judgments involve discrete data, and the conditions and final results are generally enumerable. Among the various machine learning algorithms, the decision tree algorithm is the most convenient and clearest for handling discrete variables. Therefore, this system will use the decision tree algorithm to solve this problem during rule calculation. Among all field types, string type is the most complex to judge. Simply relying on the basic information obtained from the database model file is insufficient to distinguish which category string type fields should be classified into. Furthermore, the decision tree constructed when using basic information to calculate control classification also has the highest degree of repetition for this type.

[0048] Accordingly, when determining form recommendation parameters at the field level, the feature attributes corresponding to the field-level recommendation parameters can be determined first. The feature attributes are used to describe the type and structure of the field-level recommendation parameters. Then, a decision tree algorithm is used to generate at least one candidate feature attribute value corresponding to the feature attribute. Finally, the target feature attribute value is selected from the candidate feature attribute values ​​based on the application effect of the candidate feature attribute values. The target feature attribute value is used to construct the application template.

[0049] Specifically, such as Figure 4 The diagram illustrates the feature attribute acquisition process. To achieve more accurate control selection, we compared the database design documents and development specifications of several previous systems and found some similarities in the usage scenarios for different types of controls. For example, most dictionaries have the same name as the fields or follow the format "table_name.field_name". These dictionaries often end with words like "_TYPE" or "_RESULT". Fields of type "yes / no" mostly begin with "IF_" or "IS_", and those requiring year controls mostly end with "_YEAR". While foreign affairs management systems have different business needs across institutions, there are many common dictionaries needed by all systems that can be used to assist in feature calculation, such as gender, yes / no, province, education level, and degree. Therefore, we decided to use a method of splitting field names and performing dictionary matching to increase feature attributes.

[0050] Taking Oracle database as an example, Oracle requires that field names not exceed 30 characters. Each field typically consists of multiple words separated by underscores ("_"). Assuming the average length of a field name is 5 words, it's highly unlikely that a field name will contain more than 6 words. However, the features we need for matching calculations might be the first or last one or a few words. Therefore, we need to split the field name by underscores and sort them in both ascending and descending order for calculation. Considering that the number of words in a field is generally between 2 and 4, a complete field name is almost impossible to use as a feature due to the vast number of possibilities. Therefore, the words that might be used as features are usually only the first and last 1-2 words. Thus, we need to split the field name by underscores and store the first and last two words in both ascending and descending order in the history of the generated code as feature attributes.

[0051] For the most difficult-to-determine select box type, based on usual development experience and the actual situation of the project, the data source of the select box can be roughly divided into two situations: reading dictionary data and reading business data (or common functions). Select boxes that read business data can be implemented by adding a control template type, directly writing the data reading function in the template, avoiding the need to calculate the data retrieval URL. Since they need to read business data, the field names often have similar naming rules; the control used can be identified by the above-mentioned split field names.

[0052] For dictionary-type select boxes, field names and types in the dictionary table typically show either exact or partial matches, which is a key characteristic for determining whether a field is a select box. Therefore, the dictionary table in the code generation system can pre-store commonly used dictionaries such as gender and document type. Other business dictionaries, if available before code generation, can be imported using the system's dictionary import function for data matching; if not, dictionary values ​​can be automatically generated using certain rules. Therefore, a field for dictionary generation rules was specifically added to the template table to accommodate business dictionary generation. Considering that dictionary data might provide auxiliary feature attributes to the system through matching with field names, an attribute indicating the matching status with dictionary data was assigned to each field name and the forward and reverse order words after splitting, serving as feature attributes in the decision tree calculation.

[0053] When using decision trees to generate candidate attribute values, specifically, the CART algorithm can be used to implement the recommendation values. The process of generating the corresponding recommendation values ​​using this algorithm is explained below.

[0054] The CART algorithm is an algorithm that constructs a binary decision tree by calculating the Gini index. For attributes with multiple values, the CART algorithm constructs a binary attribute by merging values ​​and calculates the minimum Gain value for splitting. For attributes such as the first two words in ascending and descending order of a field, which may have dozens or even hundreds of different possibilities, if calculated using a random combination method, an attribute with n values ​​will have ++...+ (if n is the cardinality, n / 2 here is replaced with the median) possible binary combinations. This will be a computational process that grows rapidly as the number of attribute values ​​increases.

[0055] Because the Gini index is calculated based on purity, and for the forward and reverse word attributes of a field, some words may have a hit rate of 0 while others have a hit rate of 100%. Both types of data have a Gini index of 0, but mixing them would actually increase the Gini index. Therefore, it is more reasonable to group data with high hit probabilities together during classification. When probabilities are equal, then sort the data according to the Gini index calculated from the values ​​of the two attributes with the same probability. Values ​​with a hit probability of 0 or 1 can be considered as belonging to the same category.

[0056] Thus, if attribute A has n possible values, and m of these values ​​have a probability of 0 and k values ​​have a probability of 1, then the number of times the Gain value is calculated by binary search is only nmk, which is far less than the number of times the n values ​​are randomly binary searched.

[0057] Furthermore, because decision trees are a single-output model, the final output only has two possibilities: "yes" and "no." However, for the requirements of this system, the output usually involves more than just "yes" and "no." Therefore, we can only calculate the final result label one by one. For a specific label, if the value equals the value we need, we consider it "yes"; otherwise, we consider it "no." The generation steps of the CART decision tree are as follows: Figure 5 The diagram illustrates the steps for generating a CART decision tree for a single label. For each label value, we set two priorities: default and regular. There is only one default label. For page controls, we set the default value to a text box. If all decision trees output "no" or the decision tree cannot match any branch, the system's recommended value will be "text box". For other regular label values, we calculate them sequentially in descending order of the number of times the label exists.

[0058] Next, let's combine... Figure 6 The selection of target feature attributes is explained. Figure 6This is a decision tree model generated by control type. Based on the calculation results, we found that the generated decision trees do not follow the order of the initial, assumed human-defined classification. Instead, the word attribute we added to differentiate between checkboxes and text boxes (which have no special labels) becomes the primary attribute for classification. For some control types, the decision tree might only require reversing the first word attribute to classify the control type. Here, we only record the cases where the label for a specific control is "yes," and then iterate through the other labels sequentially to generate decision trees for other labels. Finally, by concatenating the generated decision tree results based on the same feature attributes, we obtain a multi-class decision tree model. The "text box" we mentioned earlier is not within the scope of this decision tree because it is the default option. Therefore, when a new sample is input and its corresponding template label is calculated, if it does not fit any category, "text box" is output.

[0059] Figure 6 The model is a dynamic structure, and its structure may change depending on the actual data generated in the past. However, because the main classification of the model is not the field type as one might expect, but rather the words in the field names, the foundation for this model lies in having a sufficiently consistent naming format and convention during data structure design. The more similar the naming conventions, the higher the accuracy of the system's generated parameters. Therefore, the longer the system is used and the more data it accumulates, the better its application performance will be. Conversely, if the data structure design adopts unconventional naming conventions, especially meaningless ones such as "COL_1" and "COL_2", the system's accuracy may drop drastically. This is a situation that should be avoided as much as possible during system use.

[0060] For other attributes such as required, query condition, and list display, the decision trees corresponding to these attributes are constructed using a similar decision tree generation method, except that the default values ​​are set differently depending on the situation. For the "required" tag, we believe most fields should be required, with only a few being optional. Therefore, if a field in the validation data does not match any branch of the decision tree construction result, we believe its value should be "yes". The "query condition" and "list display" attributes are the opposite, so their default value should be "no".

[0061] When the form recommendation parameters include table-level recommendation parameters, the tag recommendation parameters may include the template type of the table, wherein the form recommendation parameters correspond to whether there is a parent table in the same module, whether there is a child table in the same module, the number of fields to be displayed, and at least one attribute in the business system to which it belongs.

[0062] When determining parameters based on table-level recommended parameters, the table-level recommended parameters can be determined based on the existence of foreign keys in the data table; the existence of foreign keys is used to determine the foreign key relationship between the business table and the table in the common template.

[0063] Specifically, based on the usage of the code template, the code generation method can be divided into single-table and multi-table modes. However, since a single-table template can also be considered as a main table template without child tables, all table-level templates can be divided into two categories: main table templates and child table templates.

[0064] Using manual differentiation, the main table template is easy to identify; it simply needs to have no parent table. The actual data criterion should be that the table has no foreign keys. However, because business tables may have relationships with some common data tables, and this relationship is an important characteristic attribute when generating field-level parameters, this foreign key relationship must be recorded in the data model file. Therefore, we set the table-level characteristic attributes as "whether there is a parent table in the same module" and "whether there is a child table in the same module." This "same module" setting is specifically to distinguish the foreign key relationships between business tables and tables in common modules.

[0065] For sub-table templates, if a parent table exists within the same module, it is considered a sub-table. However, sub-table templates can have various types, and the appropriate type needs to be determined based on the table's attributes. According to the requirements regarding sub-table template types, form-based systems currently have three common page display scenarios for sub-tables, determined by the existence of the sub-table and the number of fields displayed. Because the same system needs to maintain a consistent page style, the primary criteria for determining the type vary depending on the system. When calculating, the relevant business system should also be considered as one of the feature attributes, but it does not participate in constructing the decision tree. Its purpose is to determine the range of historical data values ​​when calculating recommendation rules for parameters.

[0066] S140: Combine the form recommendation parameters with the initial template to obtain an application template; the application template includes a program for generating forms.

[0067] After obtaining the form recommendation parameters, these parameters are combined with the initial template to obtain the application template. The application template is the template that meets the current form generation requirements. The program in the template, i.e., the corresponding executable code, can complete the generation of the final form.

[0068] Specifically, the application template includes at least one of the following: an underlying framework, common functions, business logic code, and database initialization scripts. The underlying framework describes the framework set up by the program; the common functions regulate the functions implemented by the program; the business logic code executes the corresponding business logic; and the database initialization scripts implement the database initialization function. In practical applications, these settings can be configured according to specific needs, and there are no restrictions on this.

[0069] like Figure 7 As shown, there are different code generation methods based on application templates, including complete mode, module (table) generation mode and field generation mode.

[0070] The complete mode refers to the code generation system generating a complete set of system business code based on existing parameters, including the underlying framework, common functions, business code, and corresponding database initialization scripts. It is suitable for newly built systems, and the generated code can be used to quickly build a working code environment.

[0071] The module (table) generation mode is a mode that generates data based on the module or table selected by the user. It is suitable for use when creating new modules, and in specific cases, it is suitable for use when adjusting fields in existing modules.

[0072] The field generation mode generates only the fragmented code files related to that field, such as the Java BO class definition code, front-end controls, and JS code.

[0073] Although the system provides a variety of different generation modes, due to considerations of templates and parameter settings, it adopts a template nesting method to generate code. Therefore, the system generation method is always top-down. Taking the complete mode as an example, the system will first generate the required framework code and the system management function code, then generate the optional function code, and then generate the corresponding code according to the business module, in the order from the main table to the sub-table and from the table to the field.

[0074] In some implementations, the form generation process can be manually adjusted to ensure the desired effect. During the application template acquisition process, the managing user can input manual adjustment parameters to specify the desired form adjustment. Upon receiving these parameters, the application template can be obtained by combining them with recommended form parameters and the initial template. The specific process for setting these manual adjustment parameters can be tailored to the actual application requirements and will not be elaborated upon here.

[0075] S150: Generate a target form corresponding to the form generation request based on the application template.

[0076] After obtaining the application template, the target form can be generated using the application template. This can be done by first generating a form frame using the application template, then obtaining the main table data corresponding to the form frame, and finally filling the form frame with the main table data to obtain the target form.

[0077] Combined with appendix Figure 8 The flowchart for generating the form page further explains the above steps. When generating the form page, first, a master table is retrieved, and the master table template is obtained from the template library to generate the form page framework. Then, all field data under the table is traversed to generate field-level page controls, and the generated controls are written back to the master table form page framework. Field controls are generated in field order. If the field control type is not "not displayed" or "hidden box," code in the format "<field name>:<control>" is generated according to the control length set in the control template. Since most existing frameworks adopt an adaptive approach, both Bootstrap and Vue use a column-based mode to control control display. Therefore, the default page code generation mode uses a 3-column per row. If a control requires more space, the number of columns to be occupied is recorded in the control template to control the page layout. To ensure aesthetic layout, the current control length settings are all single column or full row.

[0078] When obtaining the target form, a main table can be generated first based on the form framework and the main table data. Then, if there are sub-tables corresponding to the main table, the sub-tables can be generated using the application template.

[0079] After the main table code is generated, it is determined whether the code related to the sub-table needs to be generated based on whether the main table has sub-tables.

[0080] Since list pages typically only query and display data from the main table, when generating a list page, the list page is generated according to the conditions in the main table field parameters and whether to display in a list, in field order. Controls specified in the conditions will be retrieved from the template library based on the control type corresponding to that condition field and populated back into the corresponding positions on the list page.

[0081] If the main table is configured to bind process parameters, a submit button and a corresponding page submission function should be generated simultaneously. At this point, it depends on whether the first task node in the process is set to submit to a person or a user group. If so, clicking the submit button in the list will display this page, with the user options matching the process configuration settings for the first task node. Otherwise, the submit button in the list will directly submit data to the background to start the process.

[0082] In the framework template, the process module function and business function use a listening mode to synchronize data. The listening program mainly implements functions such as state switching during the process flow. When configuring the process, a listening program needs to be set for each node. Subsequently, during the process flow, business data will be synchronized according to the configured listening program.

[0083] Based on the BPMN process design file obtained from the process definition function, the system can generate basic process configuration data through parsing. The system will generate a workflow node configuration table for each task node and an approval result configuration table for each branch based on the outgoing branches of that task node. Simultaneously, the system provides standard listener templates for the process module. These standard listeners can be downloaded from the system after the process configuration is complete and used in the business system code. If the system selects to generate a process before code generation, the standard listeners will be generated along with the module code.

[0084] Binding workflows to business data primarily involves two aspects: binding business forms for user access and allowing for modifications to business data during workflow transitions. When designing the workflow, different listener programs are bound based on the module to which the bound business forms belong. The workflow configuration function assigns business forms to each task node, sets approval interface options, and confirms the appropriate state of business data when different operation results are selected.

[0085] Therefore, while generating the target form, configuration can also be applied to the form to facilitate its use in subsequent steps. In some implementations, configuration parameters corresponding to the target form can be determined; these configuration parameters are used to determine the display content and operation permissions of the target form.

[0086] The following is in conjunction with the appendix Figure 9 The above configuration process will be further described. The main task of the form configuration step is to determine what form needs to be displayed for this task and what the operation permissions should be.

[0087] Because the business code in the system is generated automatically by the code generation system, all form pages in the same business system will have the same URL construction pattern. In the existing framework, the complete URL of a business form consists of three parts: the standard form path, primary key information, and operation type. Among them, the operation type can only include three situations during the process: modify, view, and approve. In this case, approval indicates that the user of this task node may have higher data modification permissions than the modify permission.

[0088] Therefore, the operation type is a parameter that needs to be specified by the user in the process configuration function, and it is also a parameter that needs to be automatically recommended in this system.

[0089] In other implementations, an operation type corresponding to the target form can be determined; the operation type is used to indicate the type of operation that the target form allows the user to perform; and operation controls are set in the target form based on the operation type.

[0090] Still combined with appendix Figure 9 The operation result configuration is based on the branching situation defined in the flowchart to set the controls required for the review of the operation result and the state of the process.

[0091] There are three types of user selection boxes: None, Radio, and Checkbox. Generally, "None" indicates that the next step is a specified user group, so it's not necessary to specify the next user. Radio buttons indicate that the next step is a specified user, and usually require filtering by user group. In some cases, this filtering might need to include a departmental requirement (for example, in an outbound visit application process, selecting a foreign affairs secretary requires the secretary to be from the department that submitted the application). In this case, it's necessary to specify which field from the business form the department should be used. Checkboxes indicate that the next step is a countersigning node. Users can only select a user checkbox if the operation result is countersigning. The user filtering rules for checkboxes are the same as for radio buttons.

[0092] The process status is modified by the listener after the user submits the process by selecting this result. This is an important configuration that makes the user feel that business data and the process are a whole. This parameter can actually be associated with the task node name, because data within the same task node should have the same current status regardless of its previous task node. Therefore, we consider the task node name to be equivalent to the state of business data. When the task nodes of the process are read, the corresponding status dictionary is found based on the associated table name, and the names of the task nodes existing in the process are merged into the status dictionary of that table. The status that needs to be set at this time is the ID of the next task node to which this branch flows.

[0093] The following is in conjunction with the appendix Figure 10 The implementation process of the above method is further supplemented by a specific code automatic generation system, such as... Figure 10 As shown, the automatic code generation system mainly includes a basic functional module and a code analysis and generation module.

[0094] The basic functional modules mainly include three parts: template management, data dictionary management, and rule management.

[0095] Template management is the most crucial part of the basic functionality and the foundation of code generation. The template management function primarily maintains user-extracted code templates (including database scripts, Java code templates, page templates, and standard workflow templates), including information such as template content, relationships between templates, and template type. In the code auto-generation system designed in this paper, template type is a very important parameter. The system employs a multi-level classification structure to distinguish different types of templates, and these classifications will play a vital role in the subsequent code generation process.

[0096] Data dictionary management primarily provides auxiliary features for subsequent template parameter calculation and recommendation. The data management function offers standard dictionary template downloads, allowing requirements personnel to solicit the necessary business dictionaries from business users. It also allows importing dictionary content from standard template records and permits users to upload dictionary conversion scripts in template management. These scripts automatically generate dictionary content from the system and import it into the dictionary tables of different business databases.

[0097] Rule management is mainly used to adjust some calculation parameters of automatically generated parameter rules. Once the system is running stably, no further manual intervention is required.

[0098] The code analysis and generation module is divided into three parts: business system management, code generation, and process management.

[0099] Business system management is primarily used to register basic information about business systems, such as system name, project name, database information, selected template theme, and selected optional functions. The code generation system designed in this paper is a multi-data source connectable system. It can connect to the development environment databases of various systems through the database information set in the business system, and directly run the generated database scripts. This function can be enabled as needed.

[0100] The code generation module is divided into three sub-modules: data structure parsing, parameter recommendation, and business code generation. Data structure parsing primarily reads the database definition file uploaded by the user, identifies the table structure within the file, and categorizes business tables into multiple modules using table name prefixes according to development conventions, recording the specific information of the business tables and their fields. The parameter recommendation function generates corresponding recommended parameters by comparing the data recorded in the data structure analysis with historical generated data and using rules calculated through a decision tree algorithm. The business code generation function, based on these parameters and the data structure, calls the template selected by the business system and generates the required business code according to certain rules.

[0101] The process management module is divided into three sub-modules: process definition, process configuration generation, and process migration. The process definition function provides users with a visual process editing interface linked to business modules. When creating a new process, it generates a process based on the system's selected standard process template. Users can then adjust this template themselves or directly upload existing process definition files (BPMN 2.0 files). The process generation function includes generating configuration data for the process approval interface and generating standard process monitoring code. The process migration function is used to migrate edited process definitions and configuration data to test or production environments.

[0102] In this example, system data is stored using a combination of file directories and a database. Template files are stored in the template library's file directory according to the template hierarchy, which is convenient for debugging the system and for adjusting the template generation effect during use.

[0103] Based on the above embodiments and scenario examples, it can be seen that after receiving a form generation request, the method first obtains the initial template corresponding to the request, then determines the recommended parameters based on the form definition information contained in the request, and finally obtains an application template by combining the recommended parameters with the initial template. The application template then uses the program for generating forms included in the application template to generate the target form corresponding to the request. Based on the initial template, the method generates corresponding recommended parameters according to the form's requirements, thereby enabling the generation of the required target form using the recommended parameters combined with the template. This satisfies diverse form requirements, allowing users to obtain the necessary forms promptly and effectively, facilitating business execution and improving the user experience.

[0104] based on Figure 1 The corresponding form generation method is described, and an embodiment of this specification provides a form generation device. The form generation device is installed in a form generation equipment. For example... Figure 11 As shown, the form generation device includes the following modules.

[0105] The form generation request receiving module 1110 is used to receive form generation requests; the form generation request contains form definition information; the form definition information is used to describe the table structure of the form to be generated.

[0106] The initial template acquisition module 1120 is used to acquire the initial template corresponding to the form generation request.

[0107] The form recommendation parameter determination module 1130 is used to determine the form recommendation parameters based on the form definition information; the form recommendation parameters are used to construct the structure and type of the generated form based on the template.

[0108] The application template acquisition module 1140 is used to combine the form recommendation parameters with the initial template to obtain an application template; the application template includes a program for generating forms.

[0109] The target form generation module 1150 is used to generate a target form corresponding to the form generation request based on the application template.

[0110] based on Figure 1 The corresponding form generation method, as described in the embodiments of this specification, includes a form generation device. For example... Figure 12 As shown, the form generation device may include a memory and a processor.

[0111] In this embodiment, the memory can be implemented in any suitable manner. For example, the memory can be a read-only memory, a hard disk drive, a solid-state drive, or a USB flash drive, etc. The memory can be used to store computer program instructions.

[0112] In this embodiment, the processor can be implemented in any suitable manner. For example, the processor can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers, etc. The processor can execute the computer program instructions to perform the following steps: receiving a form generation request; the form generation request includes form definition information; the form definition information is used to describe the table structure of the form to be generated; obtaining an initial template corresponding to the form generation request; determining recommended form parameters based on the form definition information; the recommended form parameters are used to construct the structure and type of the generated form based on the template; combining the recommended form parameters with the initial template to obtain an application template; the application template includes a program for generating the form; and generating a target form corresponding to the form generation request based on the application template.

[0113] It should be noted that the above-mentioned form generation methods, devices and equipment can be applied to the field of artificial intelligence technology, or to other technical fields other than artificial intelligence technology, without any restrictions.

[0114] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0115] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0116] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this specification can be implemented by means of software plus the necessary first hardware platform. Based on this understanding, the technical solutions of this specification, in essence or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments of this specification.

[0117] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0118] This manual can be used in a wide variety of primary or dedicated computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, etc.

[0119] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification can also be practiced in distributed computing environments, where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0120] Although this specification has been described by way of examples, those skilled in the art will recognize that many variations and modifications are possible without departing from the spirit of this specification, and it is intended that the appended claims cover such variations and modifications without departing from the spirit of this specification.

Claims

1. A form generation method, characterized in that, include: Receive form generation request; The form generation request contains form definition information; The form definition information is used to describe the table structure of the form to be generated; Obtain the initial template corresponding to the form generation request; Determine the form recommendation parameters based on the form definition information; The form recommendation parameters are used to construct the structure and type of the generated form based on the template; The form recommendation parameters are combined with the initial template to obtain an application template; the application template includes a program for generating forms; Generate a target form corresponding to the form generation request based on the application template; The form recommendation parameters include field-level recommendation parameters; the field-level recommendation parameters include at least one of data parsing data, field control data, field selection data, field query data, and field display data. The step of determining form recommendation parameters based on the form definition information includes: determining feature attributes corresponding to the field-level recommendation parameters; the feature attributes are used to describe the type and structure of the field-level recommendation parameters; generating at least one candidate feature attribute value corresponding to the feature attributes using a decision tree algorithm; selecting a target feature attribute value from the candidate feature attribute values ​​based on the application effect of the candidate feature attribute values; the target feature attribute value is used to construct an application template; or determining table-level recommendation parameters based on the existence of foreign keys in the data table; the existence of foreign keys is used to determine the foreign key relationship between the business table and the table in the public template. The form recommendation parameters include table-level recommendation parameters; the table-level recommendation parameters include the table template type; the form recommendation parameters correspond to whether there is a parent table in the same module, whether there is a child table in the same module, the number of fields to be displayed, and at least one attribute in the business system to which it belongs.

2. The method as described in claim 1, characterized in that, The initial template includes at least one of the following: database script template, code template, page template, and standard process template.

3. The method as described in claim 1, characterized in that, The initial template includes at least one sub-template; the sub-template is used to distinguish different database scripts and / or front-end frameworks.

4. The method as described in claim 1, characterized in that, The step of determining the form recommendation parameters based on the form definition information includes: The business module division information, business table information, and business field information are determined based on the form definition information; the business module division information, business table information, and business field information are used to describe the structure and relationship of the business modules, business tables, and business fields, respectively.

5. The method as described in claim 1, characterized in that, The step of combining the form recommendation parameters with the initial template to obtain the application template includes: Receive manually adjustable parameters input by the user; The application template is obtained by combining the manually adjusted parameters, the form recommended parameters, and the initial template.

6. The method as described in claim 1, characterized in that, The application template includes at least one of the following: underlying framework, common functions, business code, and database initialization scripts.

7. The method as described in claim 1, characterized in that, The step of generating the target form corresponding to the form generation request based on the application template includes: Generate form frames using application templates; Retrieve the main table data corresponding to the form frame; The target form is obtained by filling the form frame with the data from the main table.

8. The method as described in claim 7, characterized in that, The step of filling the form frame with the main table data to obtain the target form includes: Generate the main table based on the form framework and the main table data; If the main table has a corresponding sub-table, the sub-table is generated using an application template.

9. The method as described in claim 1, characterized in that, The step of generating the target form corresponding to the form generation request based on the application template includes: Determine the configuration parameters corresponding to the target form; the configuration parameters are used to determine the display content and operation permissions of the target form.

10. The method as described in claim 1, characterized in that, The step of generating the target form corresponding to the form generation request based on the application template includes: Determine the operation type corresponding to the target form; the operation type is used to indicate the type of operation that the target form allows the user to perform. Based on the operation type, set the operation control in the target form.

11. A form generation device, characterized in that, include: The form generation request receiving module is used to receive form generation requests; The form generation request contains form definition information; The form definition information is used to describe the table structure of the form to be generated; An initial template acquisition module is used to acquire an initial template corresponding to the form generation request; The form recommendation parameter determination module is used to determine the form recommendation parameters based on the form definition information. The form recommendation parameters are used to construct the structure and type of the generated form based on the template; An application template acquisition module is used to combine the form recommendation parameters with the initial template to obtain an application template; the application template includes a program for generating forms; The target form generation module is used to generate a target form corresponding to the form generation request based on the application template. The form recommendation parameters include field-level recommendation parameters; the field-level recommendation parameters include at least one of data parsing data, field control data, field selection data, field query data, and field display data; determining the form recommendation parameters based on the form definition information includes: determining the feature attributes corresponding to the field-level recommendation parameters; the feature attributes are used to describe the type and structure of the field-level recommendation parameters; generating at least one candidate feature attribute value corresponding to the feature attributes using a decision tree algorithm; selecting a target feature attribute value from the candidate feature attribute values ​​based on the application effect of the candidate feature attribute values; the target feature attribute value is used to construct an application template; or determining table-level recommendation parameters based on the existence of foreign keys in the data table; the existence of foreign keys is used to determine the foreign key relationship between the business table and the table in the public template; the form recommendation parameters include table-level recommendation parameters; the table-level recommendation parameters include the table template type; the form recommendation parameters correspond to at least one attribute of whether there is a parent table in the same module, whether there is a child table in the same module, the number of fields displayed, and the business system to which they belong.

12. A form generation device, comprising a memory and a processor; The memory is used to store computer program instructions; The processor is configured to execute the computer program instructions to perform the following steps: receiving a form generation request; The form generation request contains form definition information; The form definition information is used to describe the table structure of the form to be generated; Obtain the initial template corresponding to the form generation request; Determine the form recommendation parameters based on the form definition information; The form recommendation parameters are used to construct the structure and type of the generated form based on the template; The form recommendation parameters are combined with the initial template to obtain an application template; the application template includes a program for generating forms; A target form corresponding to the form generation request is generated based on the application template; wherein, the form recommendation parameters include field-level recommendation parameters; the field-level recommendation parameters include at least one of data parsing data, field control data, field selection data, field query data, and field display data; determining the form recommendation parameters according to the form definition information includes: determining the feature attributes corresponding to the field-level recommendation parameters; the feature attributes are used to describe the type and structure of the field-level recommendation parameters; generating at least one candidate feature attribute value corresponding to the feature attributes using a decision tree algorithm; selecting a target feature attribute value from the candidate feature attribute values ​​based on the application effect of the candidate feature attribute values; the target feature attribute value is used to construct the application template; or determining table-level recommendation parameters based on the existence of foreign keys in the data table; the existence of foreign keys is used to determine the foreign key relationship between the business table and the table in the public template; the form recommendation parameters include table-level recommendation parameters; the table-level recommendation parameters include the template type of the table; the form recommendation parameters correspond to at least one attribute of whether there is a parent table in the same module, whether there is a child table in the same module, the number of fields displayed, and the business system to which they belong.

Images