Form page design platform, construction method thereof and form page construction method

Abstract

The application provides a form page design platform and a construction method thereof and a form page construction method. The construction method comprises the following steps: acquiring and analyzing a scene design requirement input by a user to determine an analysis result; determining one or more form design scenes of at least one granularity type according to the analysis result; performing attribute merging on each form operation scene according to preset common field attributes by using a preset merging rule to determine a reuse attribute domain corresponding to each form operation scene; determining a plurality of abstract behavior units according to user behaviors corresponding to each form design scene; and constructing the form page design platform according to each reuse attribute domain and each abstract behavior unit of each form design scene by using a preset interface design framework. The form page design platform constructed in this way can reuse a field attribute in multiple scenes once a field attribute is defined, thereby solving the technical problems of complex development process and lack of flexibility in the prior art form development technology.

Description

Technical Field

[0001] This application relates to the field of form development, and in particular to a form page design platform and its construction method and form page construction method. Background Technology

[0002] Data interaction between the front-end and back-end is a crucial aspect of many electronic product development processes, and forms are an important type of data interaction page. Forms have a relatively simple structure and business logic; they are used to transmit data input from the front-end to the back-end, or to present back-end data on the front-end. Forms typically use fields to hold various data items. For example, in a user query form, username, gender, and age are all considered fields.

[0003] Currently, although the development logic of form pages is highly reusable, developers still have to repeatedly configure these form pages with the same logic in existing form page development technologies. In other words, existing form page development platforms or frameworks suffer from technical problems such as complex development processes and a lack of flexibility.

[0004] Therefore, how to construct a form page development platform that is easy and flexible for developers to use has become an urgent technical problem to be solved. Summary of the Invention

[0005] This application provides a form page design platform and its construction method, as well as a form page construction method, to solve the technical problems of existing form page development platforms or frameworks having complex development processes and lack of flexibility.

[0006] Firstly, this application provides a method for constructing a form page design platform, comprising:

[0007] Obtain and parse the user input to meet the scenario design requirements, and determine the parsing results;

[0008] Based on the parsing results, one or more form design scenarios of at least one granularity type are determined. Each form design scenario contains one or more form operation scenarios. Form operation scenarios can be reused in multiple form design scenarios. Form operation scenarios are used to perform preset operations on the interactive data between the front end and the back end.

[0009] Using preset merging rules, attributes of each form operation scenario are merged according to preset common field attributes to determine the reusable attribute domains corresponding to each form operation scenario.

[0010] Based on the user behavior corresponding to each form design scenario, determine multiple abstract behavior units;

[0011] Using a pre-defined interface design framework, a form page design platform is constructed based on the reusable attribute domains and abstract behavioral units of various form design scenarios, enabling users to develop front-end and back-end data interaction interfaces through the form page design platform.

[0012] In one possible design, form operation scenarios include at least one of the following: querying a form, querying a list, adding a form, updating a form, deleting a form, and displaying form details.

[0013] In one possible design, preset merging rules are used to merge attributes for each form operation scenario based on preset common field attributes, determining the reusable attribute domains corresponding to each form operation scenario, including:

[0014] Retrieve the collection of element fields corresponding to each form operation scenario;

[0015] According to the preset merging rules, each element field in each element field set is merged to determine the attribute value of one or more common field attributes contained in the reused attribute field.

[0016] Among them, the number of types of public field attributes and the attribute values ​​of public field attributes are different or not completely the same in different form operation scenarios.

[0017] In one possible design, the element fields in the element field set include: the default value range of each public field attribute and the basic attribute set range. Correspondingly, according to a preset merging rule, the element fields in each element field set are merged, including:

[0018] Override the default value range with the basic attribute set range.

[0019] In one possible design, the basic property set field overrides the default value field, including:

[0020] When the default value of a public field attribute is not empty, check whether the corresponding public field attribute is contained in the basic attribute set.

[0021] If so, when the basic attribute set domain is merged with the default value domain, the attribute values ​​of each common field in the basic attribute set domain remain unchanged.

[0022] In one possible design, the element field also includes: a scene-ignore field. Correspondingly, according to preset merging rules, the element fields in each element field set are merged, and this also includes:

[0023] Remove the common field attributes that correspond to the scene ignore domain from the basic attribute collection domain.

[0024] In one possible design, the element domain also includes: the scene concern domain. Correspondingly, according to preset merging rules, the element domains in each element domain set are merged, which also includes:

[0025] Add common field attributes corresponding to the scene's focus areas to the basic attribute set domain.

[0026] In one possible design, the element field also includes: a scene modification field. Correspondingly, according to preset merging rules, the element fields in each element field set are merged, and this also includes:

[0027] Assign one or more attribute values ​​from the scene modification domain to the corresponding public field attribute in the base attribute collection domain.

[0028] In one possible design, the form design scenarios include: basic scenarios and combined scenarios, where a combined scenario is composed of one or more basic scenarios and one or more preset functions.

[0029] In one possible design, the basic scenarios include: form scenarios. Correspondingly, using a pre-defined interface design framework, a form page design platform is constructed based on the reusable attribute domains and abstract behavioral units of each form design scenario, including:

[0030] Based on the reusable attribute fields corresponding to the form scenario, parse each of the first fields contained in the form scenario to determine the first parsing result;

[0031] Determine whether the first field needs to be rendered based on the status information corresponding to the first field in the first parsing result.

[0032] If so, the first field is added to the rendering queue, and the rendering method of the first field is determined according to the preset rendering rules.

[0033] In one possible design, the basic scenarios include: a list scenario, which comprises one or more lists. Correspondingly, utilizing a pre-defined interface design framework, a form page design platform is constructed based on the reusable attribute domains and abstract behavioral units of each form design scenario, including:

[0034] Based on the reusable attribute domain corresponding to the list scenario, parse each of the second fields contained in the list scenario to determine the second parsing result;

[0035] Determine whether the second field needs to be displayed based on the status information corresponding to the second field in the second parsing result;

[0036] If so, then determine the list corresponding to the second field to be displayed based on the second parsing result;

[0037] Add the second field and list to be displayed to the rendering queue, and determine the rendering method of the second field and list to be displayed according to the preset rendering rules.

[0038] In one possible design, the combined scenarios include at least one of the following: query scenario, action processing scenario, pop-up scenario, and full page scenario;

[0039] The query scenario is a combination of the form scenario and the list scenario from the basic scenario;

[0040] An action processing scenario consists of a form scenario and / or a list scenario combined with at least one abstract behavior unit.

[0041] The pop-up scenario is composed of abstract behavioral units corresponding to the pop-up behavior, as well as form and / or list scenarios;

[0042] A complete page scene consists of multiple different types of pop-up scenes, at least one list scene, at least one form scene, and / or at least one query scene, and / or at least one action processing scene.

[0043] In one possible design, the form page design platform includes a connection interface for third-party component libraries.

[0044] Secondly, this application provides a form page design platform, including: a settings module, a scene module, and an interface module;

[0045] The settings module is used to obtain user-input design data, parse the design data, and set the various fields and data interfaces involved in the form page based on the parsing results;

[0046] The scenario module is used to construct form pages using multiple preset form design scenarios. The form design scenario includes one or more form operation scenarios. The form operation scenario uses reusable attribute fields to represent common field attributes, so that users only need to define the attribute value of the common field attribute once to repeatedly call the form operation scenario in the form design scenario.

[0047] The interface module is used to connect to third-party component libraries, which are used to render form pages.

[0048] Thirdly, this application provides an electronic device, comprising:

[0049] Memory, used to store program instructions;

[0050] The processor is used to call and execute program instructions in memory, and to execute the construction method of any possible form page design platform provided in the first aspect.

[0051] Fourthly, this application provides a storage medium in which a computer program is stored, the computer program being used to execute any of the possible form page design platform construction methods provided in the first aspect.

[0052] Fifthly, this application also provides a computer program product, including a computer program that, when executed by a processor, implements a construction method for any of the possible form page design platforms provided in the first aspect.

[0053] In a sixth aspect, this application provides a form page construction method, applicable to any possible form page design platform provided in the first and second aspects, the method comprising:

[0054] Retrieve user-defined design data and parse the design data;

[0055] Based on the analysis results, the settings module of the form page design platform is used to set the various fields and data interfaces corresponding to the form page. The fields include public fields and personalized fields, and the data interfaces include public interfaces and personalized interfaces.

[0056] Based on the parsing results, various fields, and data interfaces, the scenario module of the form page design platform is used to determine one or more form design scenarios corresponding to the form page;

[0057] Based on various form design scenarios, the form page design platform's scenario module and interface module are used to call the preset rendering component library to construct and render the form page.

[0058] This application provides a form page design platform and its construction method, as well as a form page construction method. The construction method acquires and parses user-input scenario design requirements to determine the parsing result; based on the parsing result, it determines one or more form design scenarios of at least one granularity type. Each form design scenario contains one or more form operation scenarios, which can be reused across multiple form design scenarios. These form operation scenarios are used to perform preset operations on interactive data between the front-end and back-end. Using preset merging rules, based on preset common field attributes, it merges the attributes of each form operation scenario to determine the reusable attribute domains corresponding to each form operation scenario; based on the user behavior corresponding to each form design scenario, it determines multiple abstract behavior units; and using a preset interface design framework, it constructs the form page design platform based on the reusable attribute domains and abstract behavior units of each form design scenario, enabling users to develop front-end and back-end data interaction interfaces through the form page design platform. The form page design platform constructed in this way allows developers to automatically reuse field attributes across multiple scenarios with only one definition, solving the technical problems of complex development processes and lack of flexibility in existing form page development platforms or frameworks. Attached Figure Description

[0059] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0060] Figure 1 A schematic diagram illustrating the construction scenario of a form page design platform provided in an embodiment of this application;

[0061] Figure 2 A flowchart illustrating a method for constructing a form page design platform according to an embodiment of this application;

[0062] Figure 3 Provided for the embodiments of this application Figure 2 A schematic diagram of a basic scenario construction logic in S205;

[0063] Figure 4 A schematic diagram illustrating the combined construction logic of various scenarios in a form page design platform provided in this application embodiment;

[0064] Figure 5 Provided for the embodiments of this application Figure 2 A schematic diagram of another basic scenario construction logic in S205;

[0065] Figure 6 A flowchart illustrating another method for constructing a form page design platform provided in this application embodiment;

[0066] Figure 7 This application provides a schematic diagram of the merging logic in a reusable attribute field corresponding to a query form scenario.

[0067] Figure 8 A schematic diagram illustrating various logical operations involved in a query form scenario provided in an embodiment of this application;

[0068] Figure 9 A schematic diagram of the structure of a form page design platform provided in this application embodiment;

[0069] Figure 10 A flowchart illustrating a form page construction method provided in an embodiment of this application;

[0070] Figure 11 This application provides a schematic diagram of the data flow of a CRUD form operation as illustrated in an embodiment.

[0071] Figure 12 A schematic diagram of the structure of a form page construction platform provided in this application embodiment;

[0072] Figure 13 This is a schematic diagram of the structure of an electronic device provided in this application.

[0073] The accompanying drawings have illustrated specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to specific embodiments. Detailed Implementation

[0074] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort, including but not limited to combinations of multiple embodiments, are within the scope of protection of this application.

[0075] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a particular order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented, for example, in orders other than those illustrated or described herein. Furthermore, the terms “comprising” and “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0076] The following is an introduction and explanation of the technical terms that appear in this application:

[0077] In this application, CRUD represents the creation, deletion, modification, and query functions of forms in web front-end development: Create: Create a new record; Update: Update a new record; Retrieve: Retrieve a record; Delete: Delete a record.

[0078] Vue is a progressive framework for building user interfaces. Unlike other large frameworks, Vue is designed to be used layer by layer from the bottom up. Vue's core library focuses only on the view layer, making it easy to learn and integrate with third-party libraries or existing projects. On the other hand, when used with modern toolchains and various supporting libraries, Vue is fully capable of powering complex single-page applications. Vue 3 is the third major release of Vue. This application uses Vue's reactive features to build a form page design platform.

[0079] Fes Design is a UI (User Interface) component library based on Vue 3, providing over 30 commonly used components, such as Form, Table, Pagination, Input, and Select, which are frequently used in form scenarios. One or more embodiments of this application reference Fes Design components to generate form pages.

[0080] For front-end development of mid- and back-end products, the most common scenario is developing a form's CRUD operations. When developing this type of page, you'll find that these pages share two characteristics: a fixed page structure and relatively unchanging business logic. When developing two form pages, you'll find that the fields and interfaces are different, but the remaining approximately 80% of the code is reusable glue code. How to reuse this glue code becomes key to improving the efficiency of form page development.

[0081] In related technologies, Sula is a framework that enables CRUD development of forms through configuration. In web form page development, developers or researchers complete the form page development by manually setting a semantic JSON description configuration. For example, deleting table row records can be done through the following semantic configuration:

[0082] Type:'link',

[0083] Confirm: 'Are you sure you want to delete this?'

[0084] Props:{children:'Delete',}

[0085] Action:{

[0086] {url:' / api / manage / delete.json',

[0087] Metiod:'POST',

[0088] Params:{id:'#{record.id'},},},

[0089] 'refreshTable',},

[0090] The semantic configuration above means: first, create a hyperlink; then, respond to the click event; then, initiate a delete request; and finally, refresh the table.

[0091] However, Sula has some problems:

[0092] 1. Sula has a strong dependency on the Ant Design component library. When other component libraries are selected, the dependency cannot be removed, resulting in redundancy in the original component library and thus causing the framework's file package to be too large.

[0093] 2. The fields in the CRUD form are all reused, but Sula still needs to configure them separately. For example, when creating a user and displaying users in a list, the user's name, age, and gender fields are reused, but Sula still needs to create two separate configurations for the user creation form and the list display. This does not make full use of the repetitive code, resulting in a large workload for development.

[0094] 3. In Sula, field rendering can only be achieved through corresponding plugins, conveying a fully semantic JSON configuration to users (i.e., form page developers). However, JSON configuration is static and cannot implement custom slot rendering. Because Sula redefines form fields, it avoids the need for custom slot rendering, but this makes the semantic JSON configuration seem cumbersome and lacking in flexibility to users.

[0095] In summary, existing form page development platforms or frameworks suffer from technical problems such as complex development processes and a lack of flexibility.

[0096] To solve the above-mentioned technical problems, the inventive concept of this application is as follows:

[0097] Improving efficiency in CRUD form development primarily boils down to two principles: simplicity of operation and reduced workload. This application addresses these principles by resolving issues such as flexible plug-and-play functionality of component libraries, reusable form field definitions, and custom rendering support for form fields. This application uses a single `Field` class to describe the commonalities of CRUD form fields. By merging class attributes, it calculates application attributes for corresponding scenarios (CRUD operations), reducing the need for redundant form field definitions. An abstract `Preset` interface describes form rendering; therefore, when extending third-party component libraries, implementing the `Preset` interface allows for flexible selection of component libraries, enabling flexible plug-and-play functionality.

[0098] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0099] Figure 1 This is a schematic diagram illustrating the construction scenario of a form page design platform provided in an embodiment of this application. Figure 1As shown, developers input design requirements parameters for the form design scenarios included in the form page platform, as well as abstract descriptions of user behavior, through the development terminal 100. The server 200 analyzes these requirements parameters, constructs one or more form design scenarios and corresponding form classes for each scenario, and constructs abstract behavior units based on the abstract descriptions of user behavior. It then sets corresponding interfaces for each abstract behavior unit and generates interfaces for third-party component libraries, providing more flexible component library support for form page rendering. Finally, developers can adjust the calling relationships and rendering logic between form classes, interfaces, and abstract behavior units through a graphical interface. The server 200 then generates the form page design platform 300. Developers can input personalized field and interface definitions, while the remaining definitions and logic for common field attributes are handled by the form page design platform 300, achieving the technical effect of reusing field attribute definitions and improving form page development efficiency.

[0100] Figure 2 This is a flowchart illustrating a method for constructing a form page design platform according to an embodiment of this application. Figure 2 As shown, the specific steps of this data volume anomaly detection method include:

[0101] S201. Obtain and parse the user input scenario design requirements, and determine the parsing results.

[0102] In this step, the user, i.e. the R&D personnel of the form page design platform, inputs various form page design requirements through the graphical interface of the development end 100, including parameter requirements, scenario requirements, logic processing requirements, user behavior descriptions, etc. The server 200 then parses these scenario design requirements according to the preset format requirements and stores the corresponding parsing results in a preset format file.

[0103] S202. Based on the parsing results, determine one or more form design scenarios of at least one granularity type.

[0104] The purpose of this step is to concretize the form scenario. In this step, each form design scenario contains one or more form operation scenarios. Form operation scenarios can be reused in multiple form design scenarios. Form operation scenarios are used to perform preset operations on the interactive data between the front end and the back end.

[0105] Optionally, form operation scenarios include at least one of the following: querying a form, querying a list, adding a form, updating a form, deleting a form, and displaying form details.

[0106] Specifically, based on the analysis results of the scenario design requirements, CRUD form page development is divided into multiple form design scenarios, including: basic scenarios and combined scenarios. Combined scenarios consist of one or more basic scenarios combined with one or more preset functions.

[0107] It should be noted that, in one possible implementation, the basic scenario corresponds to the smallest scenario granularity, meaning the basic scenario cannot be further divided into smaller scenarios. For example, a form page that only contains input collection or display of one or more fields can be considered a basic scenario, called a form scenario (abbreviated as "Form"). Similarly, a form page containing one or more data display lists can also be considered a basic scenario, called a list scenario (abbreviated as "Table"). Combined scenarios, such as a pop-up form scenario, can be obtained by combining a pop-up function with a form scenario, and a query form scenario can be obtained by combining a query function with a form scenario. It can be understood that a basic scenario can also be: one or more preset functions + a form scenario or a list scenario.

[0108] S203. Using preset merging rules, merge the attributes of each form operation scenario according to the preset common field attributes, and determine the reusable attribute domains corresponding to each form operation scenario.

[0109] In this step, after merging the attributes of each common field according to the preset merging rules, developers of subsequent form pages only need to call the merged attributes through the form page design platform constructed in this embodiment, without having to write the field attributes for each scenario.

[0110] Specifically, in CRUD development, the corresponding form operation scenarios can be divided into: query form, query list, add form, update form, delete form, and detail form modules. The attributes of the form fields in these modules are reusable (for example, the username needs to be displayed in all modules except the delete form). So how can we define an attribute that applies to all modules at once? The approach of this application embodiment is to define the common attribute of all modules as BaseField, while the different attribute definitions for each form operation scenario are set in the corresponding module of the form operation scenario, namely the query form module, table query list module, insert add form module, update update form module, delete delete form module, and view detail form module.

[0111] S204. Based on the user behaviors corresponding to each form design scenario, determine multiple abstract behavior units.

[0112] In this step, the various user interactions with forms in different form design scenarios are abstracted into independent units, namely abstract behavior units. These abstract behavior units can automatically execute operations that were originally performed or configured manually by the developers. After abstracting these common logics, form page developers no longer need to worry about the common logic of form submission and validation, but only need to configure the different behaviors of form operations through Config, such as API interface addresses, callback handling before, during, and after API call execution, etc.

[0113] S205. Using a pre-defined interface design framework, construct a form page design platform based on the reusable attribute fields and abstract behavioral units of each form design scenario.

[0114] In this step, users can develop front-end and back-end data interaction interfaces through the form page design platform. The form page design platform includes connection interfaces for third-party component libraries, allowing it to operate without strong dependencies on any particular library. Users can customize their own third-party component libraries and simply select the pre-implemented connection interface to connect with the form page design platform.

[0115] Form design scenarios include: basic scenarios and combined scenarios.

[0116] In one possible design, the basic scenarios include: a form scenario, and its corresponding construction logic, such as... Figure 3 As shown.

[0117] Figure 3 Provided for the embodiments of this application Figure 2 A schematic diagram of a basic scenario construction logic in S205. (Example) Figure 3 As shown, it specifically includes:

[0118] S2051. Based on the reusable attribute fields corresponding to the form scenario, parse each first field contained in the form scenario to determine the first parsing result.

[0119] S2052. Determine whether the first field needs to be rendered based on the status information corresponding to the first field in the first parsing result.

[0120] If so, then execute S2053 in this step.

[0121] S2053. Add the first field to the rendering queue and determine the rendering method of the first field according to the preset rendering rules.

[0122] Figure 4 This is a schematic diagram illustrating the combined construction logic of various scenarios in a form page design platform provided in this application embodiment. For example... Figure 4 As shown, the form scenario is implemented by creating the useForm class.

[0123] Specifically, after creating the `useForm` class, it parses the passed-in form field definitions. Based on the form type, it determines if a field is available and adds it to the form object and rendering queue. Specifically, it first checks if there's a next field that hasn't been rendered yet. If so, it checks if the current field's state is false (meaning it doesn't need to be displayed). If so, it discards the field, abandoning its rendering operation and proceeding to the next field. If not, it binds the corresponding display model to the field and checks if the model's state is hidden. If so, it proceeds to the next field's rendering; otherwise, it adds the field to the rendering queue to await rendering. This process is repeated until all fields in the scene have completed their rendering checks.

[0124] The `useForm` method renders forms by selecting the field rendering method based on the priority of the `slotName` rule. For example, if a form field needs to be rendered differently in the add and update forms, the rendering result in the add and update forms can be customized through the `slot` method. In this way, the field only needs to be defined once and can be applied to all modules.

[0125] Specific rendering rules, such as Figure 5 As shown, after a field in each scenario enters the field rendering process, it first determines whether to perform slot rendering according to the field type. If yes, it is added to the rendering queue to render the form. If not, it continues to determine whether to perform slot rendering according to the form item (formItem) corresponding to the field. If yes, it is added to the rendering queue to render the form. If not, it continues to determine whether to perform slot rendering according to the preset general rendering logic. If yes, it is added to the rendering queue to render the form. If not, it continues to determine whether to perform slot rendering according to the preset general form item. If yes, it is added to the rendering queue to render the form. If not, it needs to determine whether to perform custom rendering according to the rendering rules in the preset custom field class (Preset field), such as calling the component library corresponding to the component library interface. If yes, it is added to the rendering queue to render the form.

[0126] With `useForm`, we need to associate the user's action with the form. The user's action is submitting form content to the backend. Therefore, the Action adds type buttons based on the form type. When the user clicks a button, the data entered by the user is retrieved from `useForm` and formatted, as shown below. Figure 5 The merge request parameters shown indicate that a submission request is sent to the backend to associate the form with the user's actions. For example... Figure 5As shown, after the operation request is executed, the backend server merges the request results and sends them to the query module's query result listening process. The backend then executes the corresponding query and determines whether the query results need to be updated. If so, the corresponding scenario is rendered, such as list rendering. We define this as useFormAction.

[0127] In one possible design, the basic scenarios include: a list scenario, and its corresponding construction logic, such as... Figure 5 As shown.

[0128] Figure 5 Provided for the embodiments of this application Figure 2 A schematic diagram of another basic scenario construction logic in S205. (See diagram below.) Figure 5 As shown, it specifically includes:

[0129] S2054. Based on the reusable attribute domain corresponding to the list scenario, parse each of the second fields contained in the list scenario to determine the second parsing result.

[0130] S2055. Determine whether the second field needs to be displayed based on the status information corresponding to the second field in the second parsing result.

[0131] If so, then execute S2056 in this step.

[0132] S2056. Determine the list corresponding to the second field to be displayed based on the second parsing result.

[0133] S2057. Add the second field and list to be displayed to the rendering queue, and determine the rendering method of the second field and list to be displayed according to the preset rendering rules.

[0134] Specifically, such as Figure 4 As shown, the list scenario is implemented by creating a `useTable` class. `useTable`: parses the fields passed in, determines which fields need to be displayed in the list, renders the required fields onto the list, and exposes methods for external access to update the list data.

[0135] The combined scenarios include at least one of the following: query scenario, action processing scenario, pop-up scenario, and full page scenario; the query scenario is composed of the form scenario and list scenario in the basic scenarios; the action processing scenario is composed of the form scenario and / or list scenario combined with at least one abstract behavior unit; the pop-up scenario is composed of the abstract behavior unit corresponding to the pop-up behavior and the form scenario and / or list scenario; the full page scenario is composed of multiple different types of pop-up scenarios, at least one list scenario, at least one form scenario, and / or at least one query scenario, and / or at least one action processing scenario.

[0136] To facilitate understanding of the logical relationships between the basic and combined scenarios in S2051 to S2056 of the form page design platform, as well as the rendering methods of each scenario, it is assumed that the form design scenarios involved in the parsing results of the scenario design requirements in this embodiment include: Query Form, Data Display List, Insert Modal Form, Update Modal Form, Delete Modal Form, View Modal Form, etc.

[0137] To implement the above form design scenarios, this application first constructs the most basic form operation scenarios, namely the basic scenarios, such as at least one of the Form scenario and the Table list scenario. Then, based on different granularity types, it combines four other form operation scenarios: query form + data list = query scenario, form + user action processing = action processing scenario, pop-up form (i.e., pop-up box) scenario, and complete form page (i.e., complete page) scenario.

[0138] like Figure 4 As shown, when we only need to query the form and list display, you can combine useFormAction and useTable yourself, but useQuery is more convenient. When useFormAction is used for querying, add a query button, and the result of the query button operation is displayed on useTable.

[0139] Adding or updating forms is usually done through pop-up windows. Therefore, the useModal class adds pop-up handling on top of the useFormAction class, merges the rendering of pop-ups and forms, and exposes methods for external manipulation of opening and closing pop-ups.

[0140] The complete form development uses the `usePage` class to simplify development, integrating four pop-up forms (Add, Update, Delete, and Details), a list, and a query form. It checks if there are any configured operation columns for the list, adds corresponding logic to the action buttons in the operation columns (e.g., adding an "Add" button to open an "Add" pop-up), and finally merges and renders all modules together.

[0141] After the above construction, a form page construction platform was obtained.

[0142] This embodiment provides a form page design platform and its construction method. It acquires and parses user-inputted scenario design requirements to determine the parsing results. Based on the parsing results, it determines one or more form design scenarios of at least one granularity type. Each form design scenario contains one or more form operation scenarios, which can be reused across multiple form design scenarios. These form operation scenarios are used to perform preset operations on interactive data between the front-end and back-end. Using preset merging rules, based on preset common field attributes, it merges the attributes of each form operation scenario to determine the reusable attribute domains corresponding to each form operation scenario. Based on the user behavior corresponding to each form design scenario, it determines multiple abstract behavior units. Using a preset interface design framework, based on the reusable attribute domains and abstract behavior units of each form design scenario, it constructs a form page design platform, enabling users to develop front-end and back-end data interaction interfaces through the form page design platform. This constructed form page design platform allows developers to automatically reuse field attributes across multiple scenarios with only one definition, solving the technical problems of complex development processes and lack of flexibility in existing form page development platforms or frameworks.

[0143] To facilitate understanding of the specific implementation of S203 and S204, another embodiment will be introduced below for further explanation.

[0144] Figure 6 This is a flowchart illustrating a method for constructing another form page design platform provided in an embodiment of this application. For example... Figure 6 As shown, the specific steps of this data volume anomaly detection method include:

[0145] S601. Obtain and parse the user input scenario design requirements, and determine the parsing result.

[0146] S602. Determine one or more form design scenarios of at least one granularity type based on the parsing results.

[0147] The purpose of this step is to concretize the form scenario. In this step, each form design scenario contains one or more form operation scenarios. Form operation scenarios can be reused in multiple form design scenarios. Form operation scenarios are used to perform preset operations on the interactive data between the front end and the back end.

[0148] Optionally, form operation scenarios include at least one of the following: querying a form, querying a list, adding a form, updating a form, deleting a form, and displaying form details.

[0149] Specifically, based on the analysis results of the scenario design requirements, CRUD form page development is divided into multiple form design scenarios, including: basic scenarios and combined scenarios. Combined scenarios consist of one or more basic scenarios combined with one or more preset functions.

[0150] S603. Obtain the collection of each element field corresponding to each form operation scenario.

[0151] S604. According to the preset merging rules, merge the element fields in each element field set and determine the attribute values ​​of one or more common field attributes contained in the reused attribute field.

[0152] In this step, the number of types of public field attributes and the attribute values ​​of public fields may differ or not be completely the same in different form operation scenarios.

[0153] Public field attributes include: status, name, label, type, required, rules, props, enumsName, options, span, etc.

[0154] status: Indicates the status of the field, including: show, not show, hidden, not hidden, etc.

[0155] name: Indicates the name of the field when it is processed in the backend.

[0156] label: Indicates the name of the field when it is displayed on the front end.

[0157] type: Indicates the type of control that holds the field, including: input box, checkbox, radio button, etc.

[0158] Required: Indicates whether the field is required. True means required, and false means not required.

[0159] rules: Represents the rules and restrictions on the character length, numerical size, etc. of the field.

[0160] props: Represents one or more parameters corresponding to this field.

[0161] enumsname: Represents all the options that can be enumerated in the checkbox.

[0162] options: Represents the option value for single selection or other personalized settings.

[0163] span: The size of the layout area occupied by the control when it is displayed.

[0164] In one possible design, the element fields in the element field set obtained in S603 include: the default value field of each public field attribute and the basic attribute set field. Therefore, when merging the two in this step, the basic attribute set field overrides the default value field, including:

[0165] When the default value of a public field attribute is not empty, check whether the corresponding public field attribute is contained in the basic attribute set; if so, when the basic attribute set field is merged with the default value field, the attribute values ​​of each public field attribute in the basic attribute set field remain unchanged.

[0166] In one possible design, the element field also includes: a scene-ignore field. Correspondingly, according to the preset merging rules, the element fields in each element field set are merged. It also includes: deleting common field attributes corresponding to the scene-ignore field from the basic attribute set field.

[0167] In one possible design, the element field also includes: the scene concern field. Correspondingly, according to the preset merging rules, the various element fields in each element field set are merged. It also includes: adding common field attributes corresponding to the scene concern field to the basic attribute set field.

[0168] In one possible design, the element field also includes: a scene modification field. Correspondingly, according to preset merging rules, the element fields in each element field set are merged, and this also includes:

[0169] Assign one or more attribute values ​​from the scene modification domain to the corresponding public field attribute in the base attribute collection domain.

[0170] Figure 7 This is a schematic diagram illustrating the merging logic in a reusable attribute field corresponding to a query form scenario provided in an embodiment of this application. For example... Figure 7 As shown, the `required` attribute of the public field has a value of `false` in the default field, meaning it is not required. However, the basic attributes defined in the basic attribute field corresponding to the query form scenario include: the field's `id`, and the label `ID` with `required` set to `true`, meaning it is required. Thus, the basic attribute field overrides the default value of `required`. In the query form scenario, the `required` attribute is not mandatory, so it is removed from the basic attribute field. Finally, the attributes of the module corresponding to the query form scenario are merged, and the value of the basic attribute `label`, "ID", is replaced with "number". This yields the true attribute of the `id` field in the query form scenario.

[0171] S605. Based on the user behaviors corresponding to each form design scenario, determine multiple abstract behavior units.

[0172] In this step, the various user interactions with forms in different form design scenarios are abstracted into independent units, namely abstract behavior units. These abstract behavior units can automatically execute operations that were originally performed or configured manually by the developers. After abstracting these common logics, form page developers no longer need to worry about the common logic of form submission and validation, but only need to configure the different behaviors of form operations through Config, such as API interface addresses, callback handling before, during, and after API call execution, etc.

[0173] Figure 8 This is a schematic diagram illustrating various logical operations involved in a query form scenario provided in an embodiment of this application. For example... Figure 8 As shown, to prevent developers from dealing with these repetitive and tedious user behavior logics, this invention abstracts user behavior into several independent units:

[0174] Form data formatting: After obtaining data from the backend service, determine the format that the fields need to be converted according to their definitions, such as converting timestamps to Date type and splitting multiple-selection characters into arrays.

[0175] Open Modal: Display a pop-up window. Set the corresponding title and form initialization logic according to the pop-up's scenario type. For example, when adding a new form, you need to clear it; when updating a form, you need to set the selected data.

[0176] Form validation: Execute validation logic based on the rules defined for the fields, such as required fields.

[0177] Interface parameter formatting: When data is submitted to the backend service, the format that the field needs to be converted is determined according to the field definition, such as converting Date to timestamp.

[0178] Execute API call: Request the backend API, submit data to the backend service, and retrieve the response data returned by the backend service.

[0179] Interface result formatting: The data format returned by the interface is not always consistent. The data is parsed according to the defined data format, and the success or failure of the interface call is also considered.

[0180] Closing the Modal dialog: Refreshes the list, hides the dialog, and determines whether to refresh the list data based on the use case.

[0181] S606. Using a pre-defined interface design framework, construct a form page design platform based on the reusable attribute fields and abstract behavioral units of each form design scenario.

[0182] Figure 9 This is a schematic diagram illustrating the structure of a form page design platform provided in an embodiment of this application. Figure 9As shown, this form page design platform includes: a settings module, a scenario module, and an interface module;

[0183] The setting module 901 is used to obtain the design data input by the user, parse the design data, and set the various fields and data interfaces involved in the form page according to the parsing results;

[0184] Scene module 902 is used to construct form pages using multiple preset form design scenarios. The form design scenario includes one or more form operation scenarios. The form operation scenario uses reusable attribute fields to represent common field attributes, so that users only need to define the attribute value of the common field attribute once to repeatedly call the form operation scenario in the form design scenario.

[0185] Interface module 903 is used to connect to a third-party component library, which is used to render the form page.

[0186] In one possible design, the settings module 901 includes a field definition module 9011 and a configuration definition module 9012. The field definition module 9011 is used to receive user-inputted fields during form page development, such as username, user age, and user gender. The configuration definition module 9012 is used to receive the interface address of the submission interface corresponding to the personalized user input.

[0187] It should also be noted that the form page design platform in this embodiment is built on the Vue 3.0 framework. It can flexibly select third-party component libraries to render fields and form pages through the interface module 903, making the development of form pages more flexible.

[0188] The above embodiments have yielded a form page design platform. The following provides a method for using the form page design platform based on the above construction method, namely, a form page construction method.

[0189] Figure 10 This is a flowchart illustrating a form page construction method provided in an embodiment of this application. Figure 10 As shown, the specific steps of this form page construction method include:

[0190] S1001. Obtain user-defined design data and parse the design data.

[0191] S1002. Based on the parsing results, use the settings module of the form page design platform to set the various fields and data interfaces corresponding to the form page.

[0192] In this step, the fields include public fields and personalized fields, and the data interfaces include public interfaces and personalized interfaces.

[0193] S1003. Based on the parsing results, each field, and the data interface, use the scenario module of the form page design platform to determine one or more form design scenarios corresponding to the form page.

[0194] S1004. Based on each form design scenario, utilize the scenario module and interface module of the form page design platform to call the preset rendering component library, construct and render the form page.

[0195] Specifically, a) Select an already implemented Preset component library interface, such as the fesd component library interface and the antd component library interface, and register it with the form page design platform.

[0196] b) Use defineFields, i.e., the domain definition module 9011, to define fields, such as username, user age, and user gender.

[0197] c) Use defineConfig, i.e., define configuration module 9012, to define the interface address to be submitted.

[0198] d) Select a form design scenario from scenario module 902, and pass in the fields and configurations defined in steps b and c. Here, we choose one such scenario. Figure 4 The complete form, i.e., the details, is displayed in the usePage.

[0199] e) Use the rendering components of the form page design platform or the rendering components in a third-party component library for rendering. If you need to customize the logic, you can write the corresponding slot in the form page design platform, such as writing slotName as query_age to customize the rendering.

[0200] Figure 11 This is a schematic diagram illustrating the data flow of a CRUD form operation as provided in an embodiment of this application. Figure 11 As shown:

[0201] a. In a complete CRUD form page, the user edits the query form (form view) and clicks the query button.

[0202] b. The form data (form model) is first processed by the first processing tool preset.formatToReqParams to obtain the interface conversion data. Then, the interface conversion data is processed by the second processing tool config.before to generate user behavior conversion parameters.

[0203] c. Execute a data request (preset.request) based on the user behavior conversion parameters to obtain the interface data submitted to the interface.

[0204] d. Determine if the data request was executed successfully. If successful, use the third-party processing tool `config.success` to convert the execution result into a success message (res model).

[0205] e. If an error occurs, the result is converted into an error message model using the fourth processing tool config.error, and the error message is output to the error view form using the preset.message message notification interface.

[0206] f. Determine if the success message res model has pagination information. If there is no pagination information or table data, output the success message res model to the success message form successview through the message prompt interface preset.message.

[0207] g. If there is pagination information (pager model), use the rendering tool preset.tableRender to render each page. When the user changes the page, return to process b.

[0208] h. If there is table data (table model), use the rendering tool preset.tableRender to render the table data into a list.

[0209] i. When a user clicks the operation button for a row in the list data, the data in that row (row model) is converted into form data (form model) through the form editing interface preset.formatToEdit, and finally displayed on the operation form. After the user clicks the edit button and saves, the process returns to step b.

[0210] All of the complex logic described above is completed independently by the form page design platform. This application realizes one-time field definition, abstraction of user behavior, and dynamic plug-and-play of UI library. The development process is simple and has fewer steps, which effectively improves the development efficiency of CRUD forms.

[0211] Figure 12 This is a schematic diagram of a form page construction device provided in an embodiment of this application. The construction device 1200 can be implemented through software, hardware, or a combination of both.

[0212] like Figure 12 As shown, the structural device 1200 includes:

[0213] The acquisition module 1201 is used to acquire the user input scenario design requirements;

[0214] Processing module 1202 is used for:

[0215] Analyze the scenario design requirements and determine the analysis results;

[0216] Based on the parsing results, one or more form design scenarios of at least one granularity type are determined. Each form design scenario contains one or more form operation scenarios. Form operation scenarios can be reused in multiple form design scenarios. Form operation scenarios are used to perform preset operations on the interactive data between the front end and the back end.

[0217] Using preset merging rules, attributes of each form operation scenario are merged according to preset common field attributes to determine the reusable attribute domains corresponding to each form operation scenario.

[0218] Based on the user behavior corresponding to each form design scenario, determine multiple abstract behavior units;

[0219] Using a pre-defined interface design framework, a form page design platform is constructed based on the reusable attribute domains and abstract behavioral units of various form design scenarios, enabling users to develop front-end and back-end data interaction interfaces through the form page design platform.

[0220] In one possible design, form operation scenarios include at least one of the following: querying a form, querying a list, adding a form, updating a form, deleting a form, and displaying form details.

[0221] In one possible design, module 1201 is also used to obtain the collection of each element field corresponding to each form operation scenario;

[0222] Processing module 1202 is also used for:

[0223] According to the preset merging rules, each element field in each element field set is merged to determine the attribute value of one or more common field attributes contained in the reused attribute field.

[0224] Among them, the number of types of public field attributes and the attribute values ​​of public field attributes are different or not completely the same in different form operation scenarios.

[0225] In one possible design, the element fields in the element field set include: the default value field for each public field attribute and the basic attribute set field. Correspondingly, the processing module 1202 is also used for:

[0226] Override the default value range with the basic attribute set range.

[0227] In one possible design, the processing module 1202 is used for:

[0228] When the default value of a public field attribute is not empty, check whether the corresponding public field attribute is contained in the basic attribute set.

[0229] If so, when the basic attribute set domain is merged with the default value domain, the attribute values ​​of each common field in the basic attribute set domain remain unchanged.

[0230] In one possible design, the element field also includes a scene ignore field, and correspondingly, the processing module 1202 is also used to delete the common field attribute corresponding to the scene ignore field from the basic attribute set field.

[0231] In one possible design, the element field also includes a scene concern field. Correspondingly, the processing module 1202 is also used to add public field attributes corresponding to the scene concern field to the basic attribute set field.

[0232] In one possible design, the element field also includes a scene modification field, and correspondingly, the processing module 1202 is also used for:

[0233] Assign one or more attribute values ​​from the scene modification domain to the corresponding public field attribute in the base attribute collection domain.

[0234] In one possible design, the form design scenarios include: basic scenarios and combined scenarios, where a combined scenario is composed of one or more basic scenarios and one or more preset functions.

[0235] In one possible design, the basic scenarios include: a form scenario, and correspondingly, processing module 1202 is used for:

[0236] Based on the reusable attribute fields corresponding to the form scenario, parse each of the first fields contained in the form scenario to determine the first parsing result;

[0237] Determine whether the first field needs to be rendered based on the status information corresponding to the first field in the first parsing result.

[0238] If so, the first field is added to the rendering queue, and the rendering method of the first field is determined according to the preset rendering rules.

[0239] In one possible design, the basic scenario includes a list scenario, which comprises one or more lists, and correspondingly, the processing module 1202 is used for:

[0240] Based on the reusable attribute domain corresponding to the list scenario, parse each of the second fields contained in the list scenario to determine the second parsing result;

[0241] Determine whether the second field needs to be displayed based on the status information corresponding to the second field in the second parsing result;

[0242] If so, then determine the list corresponding to the second field to be displayed based on the second parsing result;

[0243] Add the second field and list to be displayed to the rendering queue, and determine the rendering method of the second field and list to be displayed according to the preset rendering rules.

[0244] In one possible design, the combined scenarios include at least one of the following: query scenario, action processing scenario, pop-up scenario, and full page scenario;

[0245] The query scenario is a combination of the form scenario and the list scenario from the basic scenario;

[0246] An action processing scenario consists of a form scenario and / or a list scenario combined with at least one abstract behavior unit.

[0247] The pop-up scenario is composed of abstract behavioral units corresponding to the pop-up behavior, as well as form and / or list scenarios;

[0248] A complete page scene consists of multiple different types of pop-up scenes, at least one list scene, at least one form scene, and / or at least one query scene, and / or at least one action processing scene.

[0249] In one possible design, the form page design platform includes a connection interface for third-party component libraries.

[0250] It is worth noting that, Figure 12 The apparatus provided in the illustrated embodiments can execute the construction method of any of the above embodiments. Its specific implementation principle, technical features, explanation of technical terms and technical effects are similar, and will not be repeated here.

[0251] Figure 13 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 13 As shown, the electronic device 1300 may include at least one processor 1301 and a memory 1302. Figure 13 The example shown is an electronic device using a processor.

[0252] The memory 1302 is used to store programs. Specifically, the program may include program code, which includes computer operation instructions.

[0253] The memory 1302 may include high-speed RAM memory, and may also include non-volatile memory, such as at least one disk storage device.

[0254] The processor 1301 is used to execute computer execution instructions stored in the memory 1302 to implement the methods described in the above embodiments.

[0255] The processor 1301 may be a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement the embodiments of this application.

[0256] Optionally, the memory 1302 can be either standalone or integrated with the processor 1301. When the memory 1302 is a device independent of the processor 1301, the electronic device 1300 may further include:

[0257] Bus 1303 is used to connect the processor 1301 and the memory 1302. The bus can be an industry standard architecture (ISA) bus, a peripheral component interconnect (PCI) bus, or an extended industry standard architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc., but this does not mean there is only one bus or one type of bus.

[0258] Optionally, in a specific implementation, if the memory 1302 and the processor 1301 are integrated on a single chip, the memory 1302 and the processor 1301 can communicate through an internal interface.

[0259] This application embodiment also provides a computer-readable storage medium, which may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a disk, or an optical disk. Specifically, the computer-readable storage medium stores program instructions, which are used to implement the logical functions corresponding to each module in the above-mentioned device embodiments.

[0260] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods described in the above-described method embodiments.

[0261] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

[0262] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

[0263] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A method of constructing a form page design platform, characterized by, include: Obtain and parse the user input to meet the scenario design requirements, and determine the parsing results; Based on the parsing results, one or more form design scenarios of at least one granularity type are determined. Each form design scenario contains one or more form operation scenarios. The form operation scenarios can be reused in multiple form design scenarios. The form operation scenarios are used to perform preset operations on the interactive data between the front end and the back end. The form operation scenarios include at least one of the following: querying a form, querying a list, adding a form, updating a form, deleting a form, and displaying form details; Using preset merging rules, attributes of each form operation scenario are merged according to preset common field attributes to determine the reusable attribute domains corresponding to each form operation scenario. Based on the user behavior corresponding to each of the form design scenarios, multiple abstract behavior units are determined; Using a pre-defined interface design framework, a form page design platform is constructed based on the reusable attribute domains and abstract behavioral units of each form design scenario, so that users can develop front-end and back-end data interaction interfaces through the form page design platform. List scenarios are implemented by creating the useTable class. useTable is used to parse which fields need to be displayed in the list based on the passed fields, render the fields to be displayed onto the list, and expose methods to the outside to update the list data. The query form and list display are implemented by combining useFormAction and useTable. useFormAction is used to add a query button when querying, and the result of the query button operation is displayed in useTable. The `usePage` class integrates four pop-up forms, a list, and a query form; it checks if there are operation columns configured in the list, adds corresponding logic to the action buttons in the operation columns, and merges and renders all modules together.

2. The method of claim 1, wherein: The method involves using preset merging rules to merge attributes for each form operation scenario based on preset common field attributes, thereby determining the reusable attribute domains corresponding to each form operation scenario, including: Obtain the set of element fields corresponding to each of the aforementioned form operation scenarios; According to the preset merging rules, each element field in each element field set is merged to determine the attribute value of one or more common field attributes contained in the reused attribute field. The number of types of public field attributes included in different form operation scenarios, and the attribute values ​​of the public field attributes are not the same or not completely the same.

3. The method of claim 2, wherein: The element fields in the element field set include: the default value field of each of the common field attributes and the basic attribute set field. Correspondingly, merging the element fields in each element field set according to the preset merging rule includes: The basic attribute set domain overrides the default value domain.

4. The method for constructing a form page design platform according to claim 3, characterized in that, The step of overriding the default value range with the basic attribute set range includes: When the default value of the public field attribute is not empty, determine whether the basic attribute set contains the corresponding public field attribute; If so, when the basic attribute set domain is merged with the default value domain, the attribute values ​​of each of the common field attributes in the basic attribute set domain remain unchanged.

5. The method for constructing a form page design platform according to claim 3, characterized in that, The element field further includes: a scene ignore field. Correspondingly, merging the element fields in each element field set according to the preset merging rule also includes: Remove the common field attribute corresponding to the scenario ignore domain from the basic attribute set domain.

6. The method for constructing a form page design platform according to claim 3, characterized in that, The element domain further includes: a scene concern domain. Correspondingly, merging the element domains in each element domain set according to the preset merging rule also includes: Add the public field attribute corresponding to the scenario concern domain to the basic attribute set domain.

7. The method for constructing a form page design platform according to claim 3, characterized in that, The element field further includes: a scene modification field. Correspondingly, merging the element fields in each element field set according to the preset merging rule also includes: Assign one or more attribute values ​​from the scenario modification domain to the corresponding public field attribute in the basic attribute set domain.

8. The method for constructing a form page design platform according to claim 1, characterized in that, The form design scenarios include: basic scenarios and combined scenarios. The combined scenarios are composed of one or more of the basic scenarios and one or more preset functions.

9. The method for constructing a form page design platform according to claim 8, characterized in that, The basic scenarios include: form scenarios. Correspondingly, the construction of a form page design platform using a preset interface design framework, based on the reusable attribute domains and abstract behavioral units of each form design scenario, includes: Based on the reusable attribute field corresponding to the form scenario, parse each of the first fields contained in the form scenario to determine the first parsing result; Determine whether the first field needs to be rendered based on the status information corresponding to the first field in the first parsing result. If so, the first field is added to the rendering queue, and the rendering method of the first field is determined according to the preset rendering rules.

10. The method for constructing a form page design platform according to claim 8 or 9, characterized in that, The basic scenarios include: a list scenario, which includes one or more lists. Correspondingly, the construction of a form page design platform using a preset interface design framework, based on the reusable attribute fields and abstract behavioral units of each form design scenario, includes: Based on the reusable attribute domain corresponding to the list scenario, parse each of the second fields contained in the list scenario to determine the second parsing result; Determine whether the second field needs to be displayed based on the status information corresponding to the second field in the second parsing result; If so, then determine the list corresponding to the second field that needs to be displayed based on the second parsing result; The second field to be displayed and the list are added to the rendering queue, and the rendering method of the second field to be displayed and the list is determined according to the preset rendering rules.

11. The method for constructing a form page design platform according to claim 10, characterized in that, The combined scenarios include at least one of the following: query scenario, action processing scenario, pop-up scenario, and full page scenario; The query scenario is a combination of the form scenario and the list scenario in the basic scenario; The action processing scenario is composed of the form scenario and / or the list scenario combined with at least one of the abstract behavior units; The pop-up scenario is composed of the abstract behavior unit corresponding to the pop-up behavior, as well as the form scenario and / or the list scenario; The complete page scene is composed of multiple different types of pop-up scenes, at least one list scene, at least one form scene, and / or at least one query scene, and / or at least one action processing scene.

12. The method for constructing a form page design platform according to claim 1, characterized in that, The form page design platform includes a connection interface for third-party component libraries.

13. A form page design platform, characterized in that, include: The module includes a settings module, a scene module, and an interface module. The settings module is used to obtain design data input by the user, parse the design data, and set the various fields and data interfaces involved in the form page according to the parsing results; The scenario module is used to construct the form page using multiple preset form design scenarios. The form design scenario includes one or more form operation scenarios. The form operation scenario uses reusable attribute fields to represent common field attributes, so that users only need to define the attribute value of the common field attribute once to repeatedly call the form operation scenario in the form design scenario. The interface module is used to connect to a third-party component library, which is used to render the form page; The form operation scenarios include at least one of the following: querying a form, querying a list, adding a form, updating a form, deleting a form, and displaying form details; List scenarios are implemented by creating the useTable class. useTable is used to parse which fields need to be displayed in the list based on the passed fields, render the fields to be displayed onto the list, and expose methods to the outside to update the list data. The query form and list display are implemented by combining useFormAction and useTable. useFormAction is used to add a query button when querying, and the result of the query button operation is displayed in useTable. The `usePage` class integrates four pop-up forms, a list, and a query form; it checks if there are operation columns configured in the list, adds corresponding logic to the action buttons in the operation columns, and merges and renders all modules together.

14. A method for constructing a form page, characterized in that, The form page design platform described in claim 13 includes: Obtain user-defined design data and parse the design data; Based on the analysis results, the settings module of the form page design platform is used to set the various fields and data interfaces corresponding to the form page. The fields include public fields and personalized fields, and the data interfaces include public interfaces and personalized interfaces. Based on the parsing results, each of the fields, and the data interface, one or more form design scenarios corresponding to the form page are determined using the scenario module of the form page design platform; Based on each of the aforementioned form design scenarios, the form page is constructed and rendered by calling the preset rendering component library using the scenario module and interface module of the form page design platform.

Images