A method, system, device and storage medium for generating a front-end page template

Abstract

The application discloses a front-end page template generation method, system and device and a storage medium, and is used for reducing differences and repetitive labor caused by manual configuration and reducing front-end page maintenance cost. The method comprises the following steps: parsing source code of a target service module by using an abstract syntax tree, locating a target request method according to identification information, and extracting an input parameter set and an output parameter set of the target request method; performing field standardization processing on the input parameter set and the output parameter set based on a preset field processing rule; generating query item configuration and display column configuration respectively according to the definition order of each field in the source code based on the processed input parameter set and the output parameter set; determining a component name of a page to be generated according to a preset route matching rule; and generating a front-end page template based on the component name, the query item configuration and the display column configuration.

Description

Technical Field

[0001] This application relates to the field of front-end development technology, and in particular to a method, system, apparatus and storage medium for generating front-end page templates. Background Technology

[0002] As front-end projects expand and business requirements change frequently, many CRUD (Create, Read, Update, Delete) pages commonly found in enterprise-level front-end projects often exhibit similar structures, consistent field sources, and high configuration redundancy. Traditional CRUD pages typically rely on developers manually writing front-end code for table column configurations, search item configurations, and form structures based on API documentation or backend return structures. This approach is not only inefficient but also prone to omissions or inconsistencies in field names, types, and validation rules, leading to inconsistent understanding of fields between the front-end and back-end, and consequently increasing maintenance costs.

[0003] Furthermore, existing technologies have also included solutions that rely on metadata description files, graphical tools, or low-code platforms. However, these solutions typically require developers to maintain separate description information or configuration files, failing to directly reflect the front-end code structure used in the actual project. Once the interface content or business logic changes, developers still need to manually update the relevant configurations, failing to reduce the problem of redundant maintenance of existing information within the project.

[0004] As business iterations accelerate and the number of front-end CRUD pages continues to increase, existing technologies are struggling to meet the demands of high-frequency delivery. In real-world projects, issues such as missing fields, inconsistent field order, and inconsistent display rules are frequently encountered. In other words, existing CRUD page construction methods suffer from poor consistency and high maintenance costs. Summary of the Invention

[0005] This application provides a method, system, apparatus, and storage medium for generating front-end page templates, which reduces the differences and repetitive work caused by manual configuration and lowers the maintenance cost of front-end pages.

[0006] The first aspect of this application provides a method for generating front-end page templates, including: Obtain the target service module to be processed, and the identification information of the target request method contained in the target service module; The source code of the target service module is parsed using an abstract syntax tree, the target request method is located based on the identification information, and the input parameter set and output parameter set of the target request method are extracted. The input parameter set and the output parameter set are subjected to field standardization processing, which includes identifying and merging paired time interval fields and identifying date type fields. Based on the processed set of input parameters and the set of output parameters, query item configuration and display column configuration are generated according to the definition order of each field in the source code. The component names of the page to be generated are determined according to the preset routing matching rules, and a front-end page template is generated based on the component names, the query item configuration, and the display column configuration.

[0007] Optionally, the source code of the target service module is parsed using an abstract syntax tree, the target request method is located based on the identification information, and the input parameter set and output parameter set of the target request method are extracted, including: The source code of the target service module is statically parsed to construct abstract syntax tree nodes. The abstract syntax tree nodes are traversed to find function definition nodes that match the identification information. Parse the parameter list of the function definition node, and extract the attribute definition of the first object type parameter in the parameter list as the input parameter set; Parse the function body of the function definition node, trace the return statement or response mapping logic within the function body, obtain the return object structure pointed to by the return statement or response mapping logic, and extract the attribute definitions of the return object structure as an output parameter set.

[0008] Optionally, in the field standardization process, the identification and merging of paired time interval fields includes: Traverse the set of input parameters or the set of output parameters to detect whether the field name contains a preset start identifier suffix or end identifier suffix; When two fields with the same prefix name are detected and respectively contain the start identifier suffix and the end identifier suffix, an association relationship is established between the two fields; Generate a new time interval type field to replace the two fields, and set the key name of the time interval type field to the prefix name.

[0009] Optionally, in the field standardization process, the identification date type field includes: Check the name suffixes of fields in the input parameter set or the output parameter set; When the name suffix matches a preset time type identifier string, the corresponding field is marked as a date component type; When generating query item configurations or display column configurations, write time formatting attributes for fields labeled as the date component type.

[0010] Optionally, based on the processed set of input parameters and the set of output parameters, query item configuration and display column configuration are generated according to the definition order of each field in the source code, including: The fields in the input parameter set or the output parameter set are traversed sequentially according to the order in which they are defined in the source code. Determine whether the name of the target field being traversed matches the exclusion list, which contains several preset pagination keywords; If there is no match, a corresponding query item configuration or display column configuration will be generated based on the attributes of the target field; If a match is found, the configuration generation step for the target field is skipped.

[0011] Optionally, determining the component name of the page to be generated according to preset routing matching rules includes: Read the project routing configuration file associated with the target service module; Parse the path attributes in the routing configuration file to find the page path corresponding to the target service module and the target request method; Extract the route name attribute value corresponding to the page path, and determine the route name attribute value as the component name of the page to be generated.

[0012] Optionally, generating a front-end page template based on the component name, the query item configuration, and the display column configuration includes: The component registration name of the front-end page template is declared based on the component name; Based on the query item configuration, construct the interface structure of the query area and generate data binding logic related to each query field; Based on the display column configuration, a table structure for the data list is constructed, and a data mapping relationship between the table columns and the corresponding output parameters is generated; Write event handling logic for responding to pagination requests and calling logic for initializing the first screen data when the page loads into the front-end page template.

[0013] A second aspect of this application provides a system for generating front-end page templates, including: The acquisition unit is used to acquire the target service module to be processed, and the identification information of the target request method contained in the target service module; The parsing unit is used to parse the source code of the target service module using an abstract syntax tree, locate the target request method according to the identification information, and extract the input parameter set and output parameter set of the target request method. The processing unit is used to perform field standardization processing on the input parameter set and the output parameter set. The field standardization processing includes identifying and merging paired time interval fields and identifying date type fields. The first generation unit is used to generate query item configuration and display column configuration respectively based on the processed input parameter set and the output parameter set, according to the definition order of each field in the source code; The second generation unit is used to determine the component name of the page to be generated according to the preset routing matching rules, and generate a front-end page template based on the component name, the query item configuration and the display column configuration.

[0014] A third aspect of this application provides an apparatus for generating a front-end page template, the apparatus comprising: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to execute the first aspect and any optional front-end page template generation method in the first aspect.

[0015] The fourth aspect of this application provides a computer-readable storage medium storing a program that, when executed on a computer, performs the first aspect and any optional front-end page template generation method of the first aspect.

[0016] As can be seen from the above technical solutions, this application has the following advantages: By acquiring the identification information of the target service module and its target request method, and using an abstract syntax tree to parse the source code to automatically extract the input and output parameter sets, page fields can be directly derived from the actual project code. Furthermore, by performing preset field standardization processing on the field set, including merging paired time interval fields and identifying date type fields, the fields have a unified structured expression before generation, ensuring consistency in field types and display rules. Subsequently, based on the processed field set and according to their definition order in the source code, query item configuration and display column configuration are generated. Preset routing matching rules determine the page component names, and the front-end page template is automatically generated accordingly.

[0017] This application automates the front-end page template construction process, enabling page fields to be directly identified, processed, and output based on interface definitions. This avoids issues such as field omissions, inconsistent field order, and inconsistent display rules that are prone to occur during manual coding, achieving automatic alignment between the front-end page structure and back-end data definitions. Furthermore, by reducing the discrepancies and repetitive work caused by manual configuration, this application significantly reduces front-end page maintenance costs, enabling higher-frequency page construction and updates in multi-business module scenarios, thereby improving overall front-end delivery efficiency. Attached Figure Description

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

[0019] Figure 1 A flowchart illustrating an embodiment of the method for generating front-end page templates provided in this application; Figure 2 A schematic diagram of an embodiment of extracting the set of input and output parameters from the source code structure in the front-end page template generation provided in this application; Figure 3 A schematic diagram of an embodiment of identifying and merging paired time interval fields in the generation of the front-end page template provided in this application; Figure 4 A schematic diagram of an embodiment of recognizing date type fields in the generation of front-end page templates provided in this application; Figure 5 A schematic diagram illustrating an embodiment of the query item configuration and display column configuration generated in the front-end page template generation provided in this application; Figure 6 A schematic diagram of an embodiment of determining the component name of the page to be generated in the front-end page template generation provided in this application; Figure 7 A schematic diagram illustrating an embodiment of generating a front-end page template for the purposes of this application; Figure 8 A schematic diagram of the structure of an embodiment of the system for generating the front-end page template provided in this application; Figure 9 A schematic diagram of an embodiment of the apparatus for generating front-end page templates provided in this application. Detailed Implementation

[0020] This application provides a method, system, apparatus, and storage medium for generating front-end page templates, which reduces the differences and repetitive work caused by manual configuration and lowers the maintenance cost of front-end pages.

[0021] It should be noted that the front-end page template generation method provided in this application can be applied to terminals as well as servers. For example, a terminal can be a smartphone, computer, tablet, smart TV, smartwatch, portable computer terminal, or a desktop computer, etc. For ease of explanation, this application uses the system running on the terminal as the execution subject for illustration.

[0022] Please see Figure 1 , Figure 1 An embodiment of the method for generating front-end page templates provided in this application includes: S101. Obtain the target service module to be processed, and the identification information of the target request method contained in the target service module; In existing manual development processes, page structure typically relies on developers manually determining field sources based on API documentation or team agreements. API methods are often scattered across different business modules and source files, requiring manual comparison of field names, types, and parameter order before being copied into the page configuration. This is highly susceptible to interruptions in the subsequent generation process due to incorrect file paths or misspelled function names. Therefore, this step, by obtaining the target service module to be processed and identifying the identifier information of the target request method contained within that module, establishes the entry point for the page generation process at the project source code level. This allows subsequent field parsing to proceed directly based on the actual code structure, eliminating the need for manual organization. The target service module refers to the service definition file in the front-end project used to encapsulate back-end interaction logic, typically a .ts or .js source code file. The identifier information refers to the function name or method key name defined within the target service module for performing network request operations—that is, the name of the target request method.

[0023] Specifically, step S101 can be executed based on a pre-defined directory structure convention of the front-end project. For example, it might be agreed that the request methods of the back-end interface are defined in files under the path api / <service module> / <page>.ts. According to this convention, an interactive command-line interface (CLI) tool is used to call the file system interface to scan the directory structure of the current front-end project and identify the business module directories containing the API definitions. Next, the scanned service definition files are displayed in a list on the interface, and the user's selection instruction for this list is received, identifying the user-selected file path as the target service module. After identifying the target service module, the tool reads the source code of that file, extracts and displays the list of exported function signatures, and receives the user's selection instruction to determine the target request method, thereby obtaining its identification information.

[0024] S102. Use the abstract syntax tree to parse the source code of the target service module, locate the target request method based on the identification information, and extract the input parameter set and output parameter set of the target request method. The system parses the source code of the target service module based on an Abstract Syntax Tree (AST) and locates the target request method in the syntax structure according to the identification information obtained in the preceding steps. An Abstract Syntax Tree (AST) is a tree-like data representation of the syntax structure of source code. It can map elements such as functions, variables, and statements in the code into nodes with hierarchical relationships and serves as the basic data model for automatic program analysis and processing.

[0025] Within the structured code view provided by the abstract syntax tree, the system can identify and retrieve the definition location, parameter structure, and return value of the target request method. This means it can extract the data sources related to page generation from the source code level and extract the data items used for input and output from the target request method into input parameter sets and output parameter sets, respectively. The input parameter set refers to the list of fields defined in the target request method used to transmit data to the server, which determines the field composition of the query area on the front-end page. The output parameter set refers to the list of fields contained in the data structure returned by the target request method, which determines the column composition of the table displayed on the front-end page.

[0026] S103. Perform field standardization processing on the input parameter set and the output parameter set. Field standardization processing includes identifying and merging paired time interval fields, and identifying date type fields. The system standardizes the input and output parameter sets based on preset field processing rules. Specifically, this standardization process uses the naming conventions and type characteristics of fields in the interface as a basis, identifying special fields through rule-based methods and uniformly representing them, ensuring greater consistency in structure and semantics for the field information required for subsequent page generation.

[0027] During field standardization, the system can identify paired fields with time interval meanings according to preset rules and replace them with a unified interval field format. This allows logically related time fields to be presented in a set-based manner, facilitating unified processing of subsequent query item configuration or display column configuration. Simultaneously, for fields whose naming or type characteristics indicate a date type, the system can also identify and classify them in this step, enabling these fields to be automatically associated with the corresponding date display or input logic during template generation. Through this field standardization process, the system can transform the input parameter set and output parameter set from potentially differing field sets into a well-structured and semantically unified set of fields, automatically completing the logical transformation of complex fields. This provides a directly usable standardized data source, ensuring that the page template generation process can proceed on a stable field foundation, improving the consistency and reliability of the overall generation process.

[0028] S104. Based on the processed set of input parameters and set of output parameters, generate query item configuration and display column configuration according to the definition order of each field in the source code; Based on the processed input and output parameter sets obtained from the preceding steps, the system generates query item configurations and display column configurations according to the definition order of each field in the source code. The field set, after field standardization, already possesses a unified structure and clear semantics, but it still needs to be organized according to the original arrangement order of the fields in the interface code to maintain consistency between the generated page and the interface method. By using the definition order in the source code as the basis for field arrangement, the system can preserve the business logic intent implied by the interface's writing order during the configuration generation stage. This ensures that the final presented query items and display columns not only conform to the actual interface structure but also avoid layout inconsistencies caused by manual order adjustments.

[0029] When generating query item configurations and display column configurations, the system constructs corresponding display and interaction configurations based on the functional positioning of the input parameter set and output parameter set in the business context, adapting the fields to the structural framework of the search area and data display area. The input parameter set typically corresponds to query conditions, and its fields are organized into query item configurations after being arranged in order; the output parameter set serves as the data structure returned by the interface, and its fields are arranged in the same order to form display column configurations. By systematically mapping the field set to the configuration structure in this step, the query logic and display logic required for page generation can be expressed in a unified way, and the entire configuration structure no longer requires manual adjustment.

[0030] S105. Determine the component name of the page to be generated according to the preset routing matching rules, and generate the front-end page template based on the component name, query item configuration and display column configuration.

[0031] To ensure that the generated page can be correctly associated in the routing system, this step reads the routing configuration corresponding to the target service module and page directory, searches for the route item that matches the target page path in the route definition according to the path structure and naming rules agreed upon in the project, and extracts its name identifier from the route item as the source of the component name, so that the generated page can be directly integrated into the existing routing organization structure.

[0032] Specifically, the system first constructs a target component path conforming to a predefined format (e.g., / ${module} / ${page directory name} / index) based on the module name and page directory name determined in the preceding steps, and then reads the source code of the route configuration file in the project. Next, it uses AST parsing technology to construct a syntax tree for the route configuration, traversing the object attribute nodes within it. It searches for nodes in the route object whose component attribute values ​​match the target component path. Once a match is found, it locates the name attribute node at the same level and extracts its expression value as the component name. If no valid route is matched or an attribute is missing during parsing, a fallback mechanism is triggered, automatically generating the component name using a predefined derivation strategy. This could involve converting the page directory name to PascalCase format and appending a module prefix, or waiting for the user to manually adjust it later.

[0033] Subsequently, the system generates a front-end page template based on the component name, query item configuration, and display column configuration, transforming the structured configuration generated in the previous steps into directly executable front-end project code. Specifically, the system uses the component name declaration configuration determined in step S105 to ensure the routing caching mechanism is effective; then, it maps the query item configuration to the search area, enabling the generated page template to form interactive query conditions based on the set of input parameters; and it maps the display column configuration to a table structure, allowing the generated page template to present the data content returned by the interface according to the set of output parameters, thereby constructing a complete list display view.

[0034] During the template generation process, the system integrates component definitions, query areas, and data display areas using a preset page structure organization method, so that the final output page template has the basic configuration required for rendering logic, interaction logic, and data binding. This enables the generated page to have complete CRUD capabilities and can be directly used as a page file in the project module.

[0035] In this embodiment, by acquiring the identification information of the target service module and its target request method, and using an abstract syntax tree to parse the source code to automatically extract the input parameter set and output parameter set, the page fields can be directly derived from the actual project code. Furthermore, by performing preset field standardization processing on the field set, including merging paired time interval fields and identifying date type fields, the fields have a unified structured expression before generation, ensuring consistency in field types and display rules. Subsequently, based on the processed field set and according to their definition order in the source code, query item configuration and display column configuration are generated. The component names of the page are determined through preset routing matching rules, and the front-end page template is automatically generated accordingly.

[0036] This embodiment utilizes an automated front-end page template construction process, enabling page fields to be directly identified, processed, and output based on interface definitions. This avoids issues prone to occur during manual coding, such as field omissions, inconsistent field order, and inconsistent display rules, achieving automatic alignment between the front-end page structure and back-end data definitions. Furthermore, by reducing the discrepancies and repetitive work caused by manual configuration, this application significantly reduces front-end page maintenance costs, enabling higher-frequency page construction and updates in multi-business module scenarios, thereby improving overall front-end delivery efficiency.

[0037] Please see Figure 2 According to some embodiments of the present invention, in step S102, the input and output parameter sets are extracted from the source code structure, which may specifically include, but are not limited to, the following: S201. Staticly parse the source code of the target service module to construct abstract syntax tree nodes, traverse the abstract syntax tree nodes, and search for function definition nodes that match the identification information. In the initial stage of static analysis, the system first reads the source code string of the target service module and converts it into an Abstract Syntax Tree (AST) containing complete syntactic details. In this tree structure, each code element (such as variable declarations, function definitions, and expressions) is instantiated as an AST node of a specific type. The system then traverses the AST nodes and precisely matches the function name or method key name based on the identifier information of the target request method obtained in the previous steps. This allows the system to locate the target request method at the source code level, ensuring that subsequent extraction of input and output parameters can be based on the actual project code without manual searching.

[0038] S202. Parse the parameter list of the function definition node and extract the attribute definition of the first object type parameter in the parameter list as the input parameter set; After locating the target function logic, the system needs to identify the required input parameter structure to deduce the query conditions for the front-end page. Specifically, after locating the function definition node, the system further parses the parameter list of the function definition node to obtain the input fields required for the page query. In front-end engineering practice, to maintain interface extensibility, API request methods typically use the first parameter as a configuration object containing all business parameters. Based on this engineering convention, the system identifies the parameter types in the parameter list, parses the first object type parameter, and extracts its internal attribute definitions to form an input parameter set. This input parameter set contains field information used to transmit data to the backend, with each field corresponding to a query condition in the front-end page query.

[0039] In its implementation, the system accesses the parameter array of the AST nodes, retrieves the first parameter node with index 0, and checks its syntax type: if the type is an object destructuring pattern, it indicates that the code directly destructs the input parameter object at the parameter position. The system then traverses the property nodes within this object pattern, extracting the name of each property key. If the type is an identifier, it indicates that the code uses a type definition, such as a TypeScript Interface. The system further searches for the interface definition corresponding to the identifier and parses the property list in the interface. The system establishes the extracted property name list as the input parameter set, thus completing the semantic mapping from function input parameters to page query items. Through this step, without relying on manually organizing interface documentation or development conventions, the page generation process can directly obtain the query fields defined in the actual code, thereby avoiding page functionality abnormalities caused by incorrect parameter order, misspelled field names, or omissions.

[0040] S203. Parse the function body of the function definition node, trace the return statement or response mapping logic in the function body, obtain the return object structure pointed to by the return statement or response mapping logic, and extract the attribute definition of the return object structure as the output parameter set.

[0041] After determining the query criteria, the system needs to further parse the function's return value to construct the page list structure. Specifically, the system traverses the syntax nodes of the function body, traces the return statement or response mapping logic, identifies the return object structure generated after the function execution, and then extracts the attribute definitions in the return object structure as an output parameter set.

[0042] Specifically, the system retrieves the function body of the function definition node and scans its return statements. If the return statement directly contains an object literal, its attributes are extracted directly; if the return statement calls a mapping function or returns a variable, the system traces upwards using the AST chain to find the implementation logic of the mapping function or the source of the variable's assignment. By recursively tracing the response mapping logic, the system can ultimately locate the return object structure describing the shape of the returned data and extract its attribute keys as the output parameter set. This process ensures that even with encapsulation or transformation logic in the code, the system can still accurately reconstruct the data column definitions ultimately delivered to the front-end page.

[0043] In this embodiment, by statically parsing the source code of the target service module and constructing an abstract syntax tree, the system can automatically locate the target request method and extract the input parameter set and output parameter set from the method parameter list and return object, thereby achieving automated acquisition of page fields. Compared with the traditional manual sorting method, the field extraction process based on static source code analysis in this embodiment can ensure that the page fields are consistent with the actual data structure of the project, reducing manual maintenance costs.

[0044] During the front-end page generation process, when the interface fields contain logically related paired time fields (such as "startTime" and "endTime"), if they are not handled uniformly, the page query items or display column configurations are prone to duplicates, confusion, or inconsistent display issues. Therefore, please refer to [link / reference needed]. Figure 3 According to some embodiments of the present invention, the date type field in step S103 may specifically include, but is not limited to, the following: S301. Traverse the input parameter set or output parameter set, and check whether the field name contains a preset start identifier suffix or end identifier suffix; The system iterates through each field key name in the input parameter set or output parameter set extracted in the preceding steps. For each field, the system uses regular expressions or string matching algorithms to check whether it ends with a preset start identifier suffix (e.g., Start, StartTime, Begin) or a preset end identifier suffix (e.g., End, EndTime, Finish) to identify time fields that may have logical relationships.

[0045] S302. When two fields with the same prefix name are detected and each contains a start identifier suffix and an end identifier suffix respectively, establish an association between the two fields. After identifying candidate time fields, the system further performs prefix matching on the field names to determine whether these time fields logically belong to the same business entity. Specifically, for each field containing a start identifier suffix, the system extracts its prefix name; for example, `createTimeStart` is separated into `createTime`. Then, it searches for fields containing an end identifier suffix to see if there are any fields with the same prefix name. When two fields with the same prefix name and containing both a start identifier suffix and an end identifier suffix respectively are detected, it is determined that these two fields constitute a logically paired set of time fields, and an association index is established between them.

[0046] It should be noted that if the field naming does not conform to the convention, i.e., it does not have a preset start or end identifier suffix, such as beginTime and endTime, although semantically they are time fields, they will not be recognized as time interval fields. Instead, they will be treated as ordinary search fields, and assigned independent query orders searchOrder:1 and searchOrder:2 respectively. For single-end time fields (only xxxStartTime exists but no corresponding xxxEndTime), although they will be recorded in the timeMap and marked start:true during the detection phase, because the condition of "simultaneous existence of start and end markers" is not met, this field will not enter the final parameter mapping paramsMap, nor will a corresponding search term be generated, thus avoiding the occurrence of semantically incomplete pseudo-time interval configurations.

[0047] S303. Generate a new time interval type field to replace the two fields, and set the key name of the time interval type field to the prefix name.

[0048] After establishing field relationships, the system generates a new time range field based on the prefix name, replacing the original start and end fields with this unified field. The generated time range field structurally includes start and end time information and uses a common prefix on the key name to maintain consistency with the original field logic. Through this process, the time range field can be directly used to construct query items or display columns during the page template generation stage, ensuring that the front-end page maintains consistency with the API return data in both logic and presentation, while improving the usability of query operations and the standardization of field management. In effect, the final generated page configuration will no longer show two separate input boxes, but will directly present a time range selector bound to the `createTime` logical key. At runtime, the front-end framework will automatically decompose the selected time array from this component back into Start / End parameters and send them to the backend, or receive Start / End data from the backend and merge them for display, thus automatically optimizing the front-end interactive experience without changing the backend API contract.

[0049] In this embodiment, by automatically detecting, associating, and merging paired time fields in the input and output parameter sets, the system achieves standardized and structured expression of the fields. The system performs logical integration of time intervals at the field level, making the generated page query items and display columns clearer in structure and more semantically consistent. This provides a reliable field foundation for subsequent automated page template generation, thereby improving the efficiency and stability of front-end page generation.

[0050] During the front-end page generation process, developers often need to manually determine whether a field is a date type, which is not only time-consuming but also prone to errors. Therefore, please refer to [link / reference needed]. Figure 4 According to some embodiments of the present invention, the date type identification field in step S103 may specifically include, but is not limited to, the following: S401. Check the name suffix of the fields in the input parameter set or output parameter set; In scenarios lacking strong type definitions (such as in a pure JavaScript environment) or with broad type definitions (such as simply defining them as string or number), it is often difficult to distinguish between plain text and date / time data based solely on data type. To accurately infer the business meaning of fields, the system iterates through the input and output parameter sets, checking the name suffix of each field.

[0051] S402. When the name suffix matches the preset time type identifier string, mark the corresponding field as a date component type; The system extracts name suffixes and matches them against preset time type identifier strings, i.e., keyword tables representing time attributes, such as "Date" and "Time," to automatically identify possible date fields. Once a match is successful (e.g., if the field name is updateTime and the suffix "Time" matches the keyword table), the system marks the field as a date component type in its internal data structure. This marking not only preserves the field's original input or output attributes but also logically categorizes it as a time type field. This allows subsequent page template generation to apply dedicated date processing logic in query items or display columns, ensuring the field behaves correctly during page rendering and user interaction, and preventing the date field from being mistakenly treated as ordinary text or numeric fields.

[0052] S403. When generating query item configuration or display column configuration, write time formatting attributes for fields marked as date component type.

[0053] After the fields are marked, the system writes the corresponding time formatting attributes for all fields marked as date component types when building the query item configuration and display column configuration. This includes setting the format of the date picker, the display format of dates in the table, or the time range selection logic. Through this step, the front-end page template can automatically apply unified date display and interaction rules, ensuring that page rendering and data interaction meet the business logic requirements of the time field.

[0054] In this embodiment, date type fields are automatically identified and marked by detecting the suffixes of field names in the input and output parameter sets, and time formatting attributes are written into the query items and display column configurations. Through this processing, the page template can accurately present date data, support date input components, and ensure consistency with backend data types, thereby improving the automation and reliability of the page generation process and avoiding field type identification errors and configuration inconsistencies caused by manual operations.

[0055] Please see Figure 5 According to some embodiments of the present invention, step S104, when generating the query item configuration and display column configuration, may specifically include, but is not limited to, the following: S501. Iterate through the fields in the input parameter set or output parameter set in the order they are defined in the source code. During the front-end page generation process, to ensure that the query item configuration and display column configuration are consistent with the field order of the interface method, it is necessary to traverse the fields based on their original definition order in the source code. The system accesses each field node sequentially according to the order in which the fields in the input parameter set or output parameter set are arranged in the source code, thus maintaining a display order consistent with the source code logic during configuration generation. By preserving the business logic intent implied by the interface writing order, the page generation process can build a unified and stable query item and display column structure without relying on manual sorting, reducing layout or interaction problems caused by disordered field order.

[0056] S502. Determine whether the name of the target field being traversed matches the exclusion list, which contains several preset pagination keywords. During the configuration generation process, certain fields (such as pagination parameters like "pageNum" and "pageSize") typically do not need to be displayed as page query items or table columns. When iterating through the fields, the system uses a pre-defined exclusion list to determine if the current field name matches any pagination keywords. This allows the system to automatically identify and exclude unnecessary fields during query item and display column configuration generation, ensuring that the final page configuration only includes business-related fields, thus improving the clarity and logical coherence of the page structure.

[0057] S503. If there is no match, generate the corresponding query item configuration or display column configuration based on the attributes of the target field. For fields that do not match the exclusion list, the system will generate corresponding query item configurations or display column configurations based on the field's attributes. Fields in the input parameter set typically correspond to query conditions, and their attributes determine the query component type and display order. Fields in the output parameter set are used for table column display, and their attributes determine column width, formatting rules, and sorting methods. Through automated generation, page query items and display columns can directly map to API field attributes, ensuring a high degree of consistency between the front-end display logic and the back-end data structure, while eliminating the need for manual configuration file writing.

[0058] S504. If a match is found, skip the configuration generation step for the target field.

[0059] For fields in the exclusion list, the system will automatically skip the configuration generation step for that field and will not include it in the query item or display column configuration. This mechanism effectively prevents pagination fields or other control fields that do not need to be displayed from being mistakenly added to the page display area, thereby keeping the page structure simple and the logic clear, and ensuring that the generated template can be used directly, reducing manual adjustment and maintenance costs.

[0060] In this embodiment, an automated field configuration generation process is achieved by traversing fields sequentially according to the source code, and then using an exclusion list to determine and generate query items and display column configurations. During the configuration generation process, pagination fields that do not need to be displayed are automatically skipped, thereby ensuring that the query items and display columns of the generated page only contain business-related fields, making the front-end page display logic consistent with the interface field structure.

[0061] Please see Figure 6 According to some embodiments of the present invention, the component names of the page to be generated in step S105 may specifically include, but are not limited to, the following: S601, Read the project routing configuration file associated with the target service module; In front-end engineering, each page typically needs to be registered in the routing system to be accessible in the browser. In traditional development, component names and route paths are often manually maintained by developers, which can easily lead to naming inconsistencies or path errors. This step automatically reads the project routing configuration file associated with the target service module, aligning the page generation process with the existing routing system and providing component name information for the subsequently automatically generated front-end page templates. The system can locate the corresponding routing configuration file for the target service module based on an agreed-upon project directory structure or configuration mapping, achieving automated association.

[0062] S602. Parse the path attribute in the routing configuration file and find the page path corresponding to the target service module and the target request method; After reading the routing configuration file, the system uses an abstract syntax tree or configuration parsing tool to parse the route object, traversing its path attributes. By comparing the target service module's module name, page directory name, and target request method information, the system can find the route path nodes corresponding to the target service module and page. This step ensures that the generated front-end page can be correctly embedded into the existing routing system and maintains a one-to-one correspondence with the back-end interfaces and service modules, avoiding page inaccessibility issues due to path mismatches.

[0063] S603. Extract the route name attribute value corresponding to the page path, and determine the route name attribute value as the component name of the page to be generated.

[0064] After locating the target page path node, the system further extracts its corresponding route name attribute value and uses this value as the source of the generated front-end page component name. In this way, the generated page component name conforms to the project's route naming conventions and can be directly used within the routing system, thus ensuring that the generated page can be referenced and accessed normally. If a valid route name is not found or the attribute is missing during the parsing process, the system can also activate a fallback mechanism to automatically deduce the component name based on the page directory name or module name, ensuring the continuity and reliability of the page generation process.

[0065] In this embodiment, by reading the project routing configuration file, parsing the path attributes, and extracting the route name attribute value, the component names of the pages to be generated can be automatically obtained. By associating the component names with the existing routing system, the system ensures that the generated front-end pages can be directly integrated into the project structure, avoiding manual naming errors and improving the automation and maintainability of page generation.

[0066] Please see Figure 7 According to some embodiments of the present invention, generating a front-end page template in step S106 may specifically include, but is not limited to, the following: S701, Declare the component registration name of the front-end page template based on the component name; In front-end engineering, component names are used not only for page identification but also for route caching, module referencing, and component registration. In traditional development, component names are usually manually maintained by developers, which can easily lead to naming conflicts or inconsistencies with routing. This step automatically declares the component's registered name in the generated front-end page template based on the component name determined in previous steps. In this way, the generated page can be directly referenced in the project and remains consistent with the routing system and page caching mechanism, ensuring the standardization and reusability of the generated template.

[0067] S702. Construct the interface structure of the query area based on the query item configuration, and generate data binding logic related to each query field; The system automatically constructs the interface structure of the query area on the page using the query item configuration generated in the preceding steps. Each query field corresponds to a field in the input parameter set, and corresponding components are generated based on the field type, such as text input boxes, dropdown selectors, and date pickers. Simultaneously, the system automatically generates the binding logic between query fields and the data model, enabling real-time mapping of user input or selection values ​​to corresponding request parameters. This achieves seamless integration between front-end query operations and API data requests, ensuring complete consistency between the field structure of the query area and the API definition, and avoiding field omissions or binding errors caused by manual configuration.

[0068] S703. Construct a table structure for the data list based on the display column configuration, and generate a data mapping relationship between the table columns and the corresponding output parameters; After constructing the query range, the system automatically builds a table structure for the data list based on the display column configuration generated in the previous steps. Each column maps to a field in the output parameter set, and the system automatically generates the data mapping logic between columns and the data returned by the API, including column names, sorting rules, and formatted display (such as date or time range formatting). This generated table structure accurately presents the data returned by the API while maintaining consistency with the backend data structure, avoiding display anomalies caused by inconsistent column order or field mapping.

[0069] S704. Write event handling logic for responding to pagination requests and calling logic for initializing the first screen data when the page loads in the front-end page template.

[0070] The system embeds pagination event handling logic into the generated page template, including handling page number switching, page size adjustment, and other operations. It also adds logic to initialize the first-screen data upon page load. In this way, the generated page not only has complete query and display capabilities but also enables pagination data requests and first-screen data rendering, ensuring that valid data is displayed immediately upon page load.

[0071] In its implementation, after completing component registration and generating the query area and data table structure, the system injects the metadata obtained in the previous steps (component name, target request method name, column configuration fragments, etc.) into a predefined CRUD configuration script framework. The system automatically infers the API reference path based on the module path and service name, embeds the column configuration fragment into the CRUD configuration's `columns` object, and configures default options conforming to project specifications (e.g., closing the operation bar, adding a button, etc.). The generated TypeScript code is standardized using a code formatting tool and then persistently written to the target path. Simultaneously, a Vue page template is automatically generated based on the route resolution results, including standard structures such as data list component binding, first-screen refresh logic, and pagination request event handling, ensuring that the generated page maintains consistency with the project architecture specifications in terms of functionality, structure, and data binding. Through this step, the generated page template can be directly used without manual adjustments, achieving automated front-end page generation.

[0072] In a specific embodiment, it is assumed that the preconditions have been met, i.e., the system has defined routes, API request methods, and response mappings according to the agreement. Taking business module A, service unit B, request method getList, and page directory name PageX as an example, the process of the system generating the front-end page is as follows: The user runs the page generator, selecting business module A, entering the page directory name PageX, selecting service unit B, and entering the target request method name getList in the interactive interface. The system then automatically creates the page directory based on the user's input (if the directory does not exist), parses the source code of the selected service unit B, and locates the request encapsulation function containing getList. The system further extracts the field set of the first object type input parameter of the function and parses the response mapping logic to obtain the return object field set.

[0073] During the column generation phase, the system preprocesses the extracted input and output field sets, including merging logically related start and end time fields into a time interval column, while filtering out pagination parameter fields. Based on the processed field set, the system automatically generates the query item configuration and display column configuration required for the page, maintaining the field order consistent with the interface definition, thereby ensuring that the query area and data list on the front-end page are consistent with the interface logic.

[0074] Finally, the page template generation process begins: In the configuration script, the system embeds column configuration and pagination request binding logic; in the Vue page template, the system registers component names, renders the list component, and attaches the first-screen refresh logic, allowing the page to retrieve API data upon loading. Once generated, users can see the query area and data column structure automatically generated from the API when they open the page. Column titles can be modified locally according to actual needs. For example, input parameter fields can be customized as follows: In {memberId,countryCode,createdStartTime,createdEndTime,...}, createdStartTime and createdEndTime are automatically merged into a createdTime range column, generating corresponding query items and display columns. At the same time, the field order is kept consistent with the API returned data {id,status,amount,createdTime,...}, achieving automatic alignment of fields between the front-end page and the back-end API.

[0075] The following provides a detailed description of the system for generating front-end page templates provided in this application. Please refer to [link / reference]. Figure 8 , Figure 8 An embodiment of a system for generating front-end page templates provided in this application, the system comprising: The acquisition unit 801 is used to acquire the target service module to be processed, and the identification information of the target request method contained in the target service module; The parsing unit 802 is used to parse the source code of the target service module using an abstract syntax tree, locate the target request method based on the identification information, and extract the input parameter set and output parameter set of the target request method. The processing unit 803 is used to perform field standardization processing on the input parameter set and the output parameter set. The field standardization processing includes identifying and merging paired time interval fields, and identifying date type fields. The first generation unit 804 is used to generate query item configuration and display column configuration respectively based on the processed input parameter set and output parameter set, according to the definition order of each field in the source code; The second generation unit 805 is used to determine the component name of the page to be generated according to the preset routing matching rules, and generate a front-end page template based on the component name, query item configuration and display column configuration.

[0076] Optionally, the parsing unit 802 is specifically used for: Static parsing is performed on the source code of the target service module to construct abstract syntax tree nodes. The abstract syntax tree nodes are traversed to find function definition nodes that match the identification information. Parse the parameter list of the function definition node, and extract the property definition of the first object type parameter in the parameter list as the input parameter set; The function body of the parsing function definition node is traced, the return statement or response mapping logic within the function body is obtained, the return object structure pointed to by the return statement or response mapping logic is obtained, and the attribute definitions of the return object structure are extracted as the output parameter set.

[0077] Optionally, the processing unit 803 is specifically used for: Iterate through the set of input parameters or the set of output parameters, and check whether the field name contains a preset start identifier suffix or end identifier suffix; When two fields with the same prefix name are detected and each contains a start identifier suffix and an end identifier suffix respectively, an association relationship is established between the two fields; Generate a new time interval type field to replace the two fields, and set the key name of the time interval type field to the prefix name.

[0078] Optionally, the processing unit 803 is further used for: Check the name suffixes of fields in the input or output parameter set; When the name suffix matches the preset time type identifier string, the corresponding field will be marked as a date component type; When generating query item configurations or display column configurations, write time formatting properties for fields marked as date component types.

[0079] Optionally, the first generating unit 804 is specifically used for: Iterate through the fields in the input parameter set or output parameter set in the order they are defined in the source code; Determine whether the name of the target field being traversed matches the exclusion list, which contains several preset pagination keywords; If there is no match, the corresponding query item configuration or display column configuration will be generated based on the attributes of the target field; If a match is found, the configuration generation step for the target field is skipped.

[0080] Optionally, the second generation unit 805 is specifically used for: Read the project routing configuration file associated with the target service module; Parse the path attributes in the routing configuration file to find the page path corresponding to the target service module and the target request method; Extract the route name attribute value corresponding to the page path, and use the route name attribute value as the component name of the page to be generated.

[0081] Optionally, the second generating unit 805 is further used for: The component registration name in the front-end page template is declared based on the component name; The interface structure of the query area is constructed based on the query item configuration, and data binding logic related to each query field is generated. The table structure of the data list is constructed based on the display column configuration, and the data mapping relationship between the table columns and the corresponding output parameters is generated; Write event handling logic for responding to pagination requests and calling logic for initializing the first screen data when the page loads in the front-end page template.

[0082] In this embodiment, the functions of each unit are the same as described above. Figure 1-7 The steps in the method embodiments shown correspond to those in the examples, and will not be repeated here.

[0083] This application also provides a device for generating front-end page templates; please refer to [link / reference]. Figure 9 , Figure 9 One embodiment of the apparatus for generating front-end page templates provided in this application includes: Processor 901, memory 902, input / output unit 903, bus 904; The processor 901 is connected to the memory 902, the input / output unit 903, and the bus 904; The memory 902 stores a program, and the processor 901 calls the program to execute any of the methods for generating front-end page templates as described above.

[0084] This application also relates to a computer-readable storage medium on which a program is stored, which, when run on a computer, causes the computer to perform any of the methods for generating front-end page templates as described above.

[0085] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0086] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0087] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0088] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0089] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A method for generating a front-end page template, characterized in that, The method includes: Obtain the target service module to be processed, and the identification information of the target request method contained in the target service module; The source code of the target service module is parsed using an abstract syntax tree, the target request method is located based on the identification information, and the input parameter set and output parameter set of the target request method are extracted. The input parameter set and the output parameter set are subjected to field standardization processing, which includes identifying and merging paired time interval fields and identifying date type fields. Based on the processed set of input parameters and the set of output parameters, query item configuration and display column configuration are generated according to the definition order of each field in the source code. The component names of the page to be generated are determined according to the preset routing matching rules, and a front-end page template is generated based on the component names, the query item configuration, and the display column configuration.

2. The method according to claim 1, characterized in that, The source code of the target service module is parsed using an abstract syntax tree. The target request method is located based on the identification information, and the input parameter set and output parameter set of the target request method are extracted, including: The source code of the target service module is statically parsed to construct abstract syntax tree nodes. The abstract syntax tree nodes are traversed to find function definition nodes that match the identification information. Parse the parameter list of the function definition node, and extract the attribute definition of the first object type parameter in the parameter list as the input parameter set; Parse the function body of the function definition node, trace the return statement or response mapping logic within the function body, obtain the return object structure pointed to by the return statement or response mapping logic, and extract the attribute definitions of the return object structure as an output parameter set.

3. The method according to claim 1, characterized in that, In the field standardization process, the identification and merging of paired time interval fields includes: Traverse the set of input parameters or the set of output parameters to detect whether the field name contains a preset start identifier suffix or end identifier suffix; When two fields with the same prefix name are detected and respectively contain the start identifier suffix and the end identifier suffix, an association relationship is established between the two fields; Generate a new time interval type field to replace the two fields, and set the key name of the time interval type field to the prefix name.

4. The method according to claim 1, characterized in that, In the field standardization process, the identification date type field includes: Check the name suffixes of fields in the input parameter set or the output parameter set; When the name suffix matches a preset time type identifier string, the corresponding field is marked as a date component type; When generating query item configurations or display column configurations, write time formatting attributes for fields labeled as the date component type.

5. The method according to claim 1, characterized in that, Based on the processed input parameter set and output parameter set, query item configuration and display column configuration are generated according to the definition order of each field in the source code, including: The fields in the input parameter set or the output parameter set are traversed sequentially according to the order in which they are defined in the source code. Determine whether the name of the target field being traversed matches the exclusion list, which contains several preset pagination keywords; If there is no match, a corresponding query item configuration or display column configuration will be generated based on the attributes of the target field; If a match is found, the configuration generation step for the target field is skipped.

6. The method according to claim 1, characterized in that, The step of determining the component names of the page to be generated according to preset routing matching rules includes: Read the project routing configuration file associated with the target service module; Parse the path attributes in the routing configuration file to find the page path corresponding to the target service module and the target request method; Extract the route name attribute value corresponding to the page path, and determine the route name attribute value as the component name of the page to be generated.

7. The method according to any one of claims 1 to 6, characterized in that, The process of generating a front-end page template based on the component name, the query item configuration, and the display column configuration includes: The component registration name of the front-end page template is declared based on the component name; Based on the query item configuration, construct the interface structure of the query area and generate data binding logic related to each query field; Based on the display column configuration, a table structure for the data list is constructed, and a data mapping relationship between the table columns and the corresponding output parameters is generated; Write event handling logic for responding to pagination requests and calling logic for initializing the first screen data when the page loads into the front-end page template.

8. A system for generating front-end page templates, characterized in that, The system includes: The acquisition unit is used to acquire the target service module to be processed, and the identification information of the target request method contained in the target service module; The parsing unit is used to parse the source code of the target service module using an abstract syntax tree, locate the target request method according to the identification information, and extract the input parameter set and output parameter set of the target request method. The processing unit is used to perform field standardization processing on the input parameter set and the output parameter set. The field standardization processing includes identifying and merging paired time interval fields and identifying date type fields. The first generation unit is used to generate query item configuration and display column configuration respectively based on the processed input parameter set and the output parameter set, according to the definition order of each field in the source code; The second generation unit is used to determine the component name of the page to be generated according to the preset routing matching rules, and generate a front-end page template based on the component name, the query item configuration and the display column configuration.

9. An apparatus for generating front-end page templates, characterized in that, The device includes: Processor, memory, input / output units, and bus; The processor is connected to the memory, the input / output unit, and the bus; The memory stores a program, which the processor invokes to perform the method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium contains a program that, when executed on a computer, performs the method as described in any one of claims 1 to 7.

Images