A web dynamic form generation method based on declarative configuration

Abstract

This invention discloses a method for generating dynamic web forms based on declarative configuration, relating to the field of computer technology. The method includes: establishing a user configuration unit to collect configuration information through declarative configuration form descriptors; establishing a configuration management unit to parse, validate, store, and distribute configuration descriptors; establishing a core rendering engine to perform component mapping, dynamic rendering, event binding, and layout management based on the configuration descriptors; establishing a response unit, which includes a form data model module for responsive state management and a UI rendering module for grid layout rendering; and establishing an external API interface to expose form lifecycle management methods. This invention transforms traditional handwritten form code into writing declarative JSON configuration, with a unified rendering engine dynamically generating forms at runtime, significantly improving development efficiency, maintainability, and business flexibility. It is particularly suitable for enterprise-level back-end management systems with a large number of forms.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a method for generating dynamic web forms based on declarative configuration. Background Technology

[0002] In current enterprise-level web application development, forms, as the core carrier of data input and interaction, have significant shortcomings in their traditional development model. First, developers need to perform the following repetitive tasks for each form: 1. Manually write template code: Construct numerous basic UI components using HTML or framework-specific syntax (such as Vue Template). 2. Manually implement data binding: Set up two-way data binding (such as v-model) for each form field and manage its corresponding reactive data state. 3. Manually integrate validation logic: Write synchronous / asynchronous validation rules and handle complex error messages and interactive feedback. 4. Manually handle layout and styling: Adjust field arrangement, spacing, and responsive behavior using CSS or layout components. 5. Manually implement business interactions: Write specific interaction logic for special fields (such as dependency selection, autofill, etc.).

[0003] These repetitive tasks lead to low development efficiency, high code duplication rate, and maintenance difficulties. When business requirements change, the source code needs to be modified and redeployed directly, resulting in poor agility. In addition, it is difficult to ensure consistency in interactive experience, visual style, and code quality among forms implemented by different developers or teams, which increases the long-term maintenance cost of the system.

[0004] While excellent UI component libraries such as Ant Design Vue and Element UI offer a wealth of form controls (such as input boxes, selectors, date pickers, etc.), they address the issue at the "atomic control" level and do not provide a systematic solution for "assembling and managing" these controls to build complete form applications. Developers still need to do a lot of repetitive "glue code" writing, and the form logic remains scattered across various components and pages, failing to achieve true "configuration" and "dynamics". Summary of the Invention

[0005] The purpose of this invention is to provide a web dynamic form generation method based on declarative configuration to solve the problems existing in the prior art.

[0006] The above-mentioned technical objective of the present invention is achieved through the following technical solution: A method for generating dynamic web forms based on declarative configuration includes the following steps: Step S1: Establish a user configuration unit to collect user configuration information and read the user configuration information through a declarative configuration form descriptor. Step S2: Establish a configuration management unit for parsing, validating, storing, and distributing the declarative configuration form descriptor; Step S3: Establish a core rendering engine to perform component mapping, dynamic rendering, event binding, and layout management based on the received declarative configuration form descriptor, in order to generate a dynamic form interface description. Step S4: Establish a response unit, which includes a form data model module and a UI rendering module. The form data model module is used to perform reactive unified state management on the native API object that constructs form data. The UI rendering module is used to perform grid layout rendering of standard components or custom slots on the interface description generated by the core rendering engine to generate the final interactive form. Step S5: Establish an external API interface to expose lifecycle management methods for manipulating the dynamic form to the outside world.

[0007] By adopting the above technical solutions, the user configuration unit obtains basic user configuration information, and then the configuration management unit parses, verifies, stores, and distributes the configuration information, which can effectively avoid duplication; the core rendering engine performs unified and standardized rendering for all requirements, so that the interactive experience and visual style are effectively unified; the response unit reduces repetitive manual work by splicing standard components or automatically using slot grids, and realizes external data sharing through external API interfaces.

[0008] In a further embodiment, the declarative configuration form descriptor is a structured data model based on JSONSchema or JavaScript objects, the core of which is an array of multiple field descriptor objects; each field descriptor includes at least: a type attribute for specifying the UI control type, a value attribute for establishing two-way data binding, and a name attribute for setting the display label.

[0009] In a further embodiment, the field descriptor further includes a UI presentation and interaction attribute group, which includes one or more of the following: a disabled attribute for controlling the disabled state of the field, an options attribute for defining a list of options, and a col attribute for controlling the width of the field in the grid layout.

[0010] In a further embodiment, the field descriptor further includes a data validation attribute group, which includes a rule attribute. The rule attribute is used to define the synchronous or asynchronous validation rules for the field, and the validation rules include at least mandatory field validation rules and format validation rules.

[0011] In a further embodiment, the field descriptor further includes a behavior and business logic attribute group, which includes a change or onchange event callback function for implementing dynamic linkage between fields, and a getParams parameter for declaratively associating UI fields with backend business services.

[0012] By adopting the above technical solution, this invention defines a machine-readable and human-configurable structured data model. Through multi-dimensional attribute groups (basic identifiers, UI presentation, data validation, and business logic), it can completely and declaratively describe all the characteristics of a form, transforming the traditional "coding" work into "configuration" work, and providing a data foundation for realizing the dynamic generation and unified management of forms.

[0013] In a further embodiment, the core rendering engine internally maintains a type-component mapping table. During dynamic rendering, it iterates through the array of field descriptors, looks up the corresponding Vue component constructor from the mapping table based on the type attribute of each field descriptor, and dynamically constructs the component's props object and event listeners to complete the component instantiation.

[0014] In a further embodiment, the external API interface includes at least: a getValue interface for triggering overall form validation and returning form data after validation passes, a getFieldsValue interface for directly returning the current form data without triggering validation, and a resetValue interface for resetting form data.

[0015] By adopting the above technical solution, this invention encapsulates complex form operations (submission, retrieval, reset, and validation) into standardized Promise-based APIs, so that the upper-level business logic does not need to care about the internal implementation details of the form, thus achieving separation of concerns and ensuring the consistency and reliability of the interaction method.

[0016] In a further embodiment, when the type attribute value of the field descriptor is slot, the core rendering engine renders a named slot, transferring rendering control of the field to the parent component to allow the injection of custom components.

[0017] By adopting the above technical solution, this invention encapsulates complex form operations (submission, retrieval, reset, and validation) into standardized Promise-based APIs, so that the upper-level business logic does not need to care about the internal implementation details of the form, thus achieving separation of concerns and ensuring the consistency and reliability of the interaction method.

[0018] In a further embodiment, the reactive unified state management in step S4 is implemented based on Vue3's reactive or refAPI, and the core rendering engine uses the v-model:value directive to bidirectionally bind UI components to the corresponding attributes in the form data model module.

[0019] In a further embodiment, the layout management in step S3 is achieved by receiving the overall layout parameter layoutNum and combining it with the col attribute value in each field descriptor to dynamically calculate the width of each form item in the grid layout.

[0020] By adopting the above technical solution, all layout information is included in the configuration data. Front-end developers do not need to manually write CSS code to adjust styles, which can achieve flexible and responsive form layout, making it easy to achieve visual consistency and batch modification later.

[0021] In summary, the present invention has the following beneficial effects: 1. By adopting the declarative configuration and dynamic rendering method of this invention, for forms composed of standard controls, the development workload is reduced from the traditional manual writing of Vue components, templates, scripts, and styles to writing a structured JSON configuration data. Development, debugging, and testing time are expected to be reduced by more than 70%, making it especially suitable for enterprise-level B2B management systems with a large number of forms; 2. The technical solution of this invention centrally stores the "definition" of the form in the configuration data. When the business rules change, only the configuration needs to be modified (which can be dynamically distributed by the backend), and the front-end interface can be automatically updated without recompiling and re-deploying. At the same time, all forms are produced by the same core rendering engine, which fundamentally ensures the absolute consistency of interactive behavior, validation feedback, and visual style, and reduces long-term maintenance costs. 3. This invention enables the structure, field rules, and linkage logic of forms to no longer be hard-coded, but to be dynamically driven by configuration data and rendered in real time in the user's browser. This provides a solid technical foundation for building zero-code / low-code form building platforms, dynamic workflow engines, and configurable form modules in multi-tenant SaaS applications.

[0022] 4. This invention strictly adheres to the "open / closed principle," perfectly covering 80% of conventional form scenarios through "configuration-driven" approaches, significantly reducing the complexity of the core system. At the same time, it elegantly handles the remaining 20% ​​of complex customized scenarios through "slot mechanisms" and declarative business parameters (getParams), making the overall system easy to understand and maintain. Attached Figure Description

[0023] Figure 1 This is a system architecture block diagram according to an embodiment of the present invention; Figure 2 This is a schematic diagram of the attribute structure of the field descriptor object in an embodiment of the present invention; Figure 3 This is a flowchart of the dynamic rendering logic inside the core rendering engine in an embodiment of the present invention. Detailed Implementation

[0024] The present invention will be further described in detail below with reference to the accompanying drawings.

[0025] It should be noted that in the description of this invention, any descriptions of orientation, such as up, down, front, back, left, right, etc., indicating orientation or positional relationships, are based on the orientation or positional relationships shown in the accompanying drawings. They are only for the purpose of facilitating the description of this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, be constructed or operated in a specific orientation, and should not be construed as a limitation of this invention.

[0026] Example 1: like Figures 1-3 As shown, a method for generating dynamic web forms based on declarative configuration includes the following steps: Step S1: Establish a user configuration unit to collect user configuration information and read the user configuration information through a declarative configuration form descriptor. Step S2: Establish a configuration management unit for parsing, validating, storing, and distributing the declarative configuration form descriptor; Step S3: Establish a core rendering engine to perform component mapping, dynamic rendering, event binding, and layout management based on the received declarative configuration form descriptor, in order to generate a dynamic form interface description. Step S4: Establish a response unit, which includes a form data model module and a UI rendering module. The form data model module is used to perform reactive unified state management on the native API object that constructs form data. The UI rendering module is used to perform grid layout rendering of standard components or custom slots on the interface description generated by the core rendering engine to generate the final interactive form. Step S5: Establish an external API interface to expose lifecycle management methods for manipulating the dynamic form to the outside world.

[0027] The Chinese definitions of the following English singletons are as follows: addonAfter indicates an input box aftertag; ajv indicates a JSON Schema validation library; Ant indicates the Ant Design component library prefix; API indicates an application programming interface; change indicates a value change event; checkList indicates a checkbox group type; col indicates the number of grid columns; componentMap indicates a component mapping table; constructor indicates a constructor function; createSomeIdApi indicates an API function for creating IDs; CSS indicates Cascading Style Sheets; datePicker indicates a date picker; defineExpose indicates Vue; 3 indicates the exposed component method API; Design indicates Design; Descriptor indicates a descriptor; disabled indicates a disabled state; DOM indicates the Document Object Model; Element indicates Element. The UI component library includes: EMPLOYEE (employee business identifier), Field (field), Flexbox (flexible box layout), formData (form data model), formList (form field configuration list), getFieldsValue (get fields value interface), getParams (business logic associated parameters), getValue (get and validate form data interface), Grid (grid layout), HTML (Hypertext Markup Language), input (input box), inputCreateId (input box type with a generate button), JavaScript (a scripting language), JSON (JavaScript Object Notation), labelCol (label column layout), layoutNum (total number of columns), name (display label), onchange (value change event callback), and onSearch (search function). Event callback, options represents the list of options, ORDER represents the order business identifier, placeholder represents the placeholder text, Promise represents an asynchronous programming object, props represents component properties, radio represents a radio button, reactive represents Vue, 3 reactive APIs, ref represents Vue, 3 reactive reference APIs, resetValue represents the form reset interface, rule represents the validation rule, SaaS represents Software as a Service, Schema represents the architectural pattern, select represents a dropdown selector, slot represents a slot, slotName represents the slot name, suffix represents the input field suffix, textarea represents a multi-line text box, type represents the component type, UI represents the user interface, validateFields represents the field validation interface, value represents the data binding key, v-else represents the Vue conditional rendering directive.`v-for` is a Vue list rendering directive, `v-if` is a Vue conditional rendering directive, `v-model` is a Vue two-way data binding directive, `Vue` is a JavaScript framework, `Web` refers to the World Wide Web, and `yup` is an object schema validation library.

[0028] Specific implementation process: The entire solution of this invention consists of four main parts: data model, rendering engine, state management and extension mechanism.

[0029] Regarding the declarative form configuration descriptor model: This invention defines a machine-readable, human-configurable structured data model based on JSON Schema or JavaScript objects to fully describe a form; a form is defined by an array (called formList) of multiple field descriptor objects; each field descriptor is an object containing multi-dimensional attributes: It is divided into: 1. Basic identifier attribute type (component type identifier, string, required): determines what kind of UI control the field will be rendered as on the interface; this is the primary basis for the rendering engine to match components; for example: 'input' (ordinary input box), 'select' (drop-down selector), 'radio' (radio button group), 'datePicker' (date picker), 'textarea' (multi-line text box), 'checkList' (custom checkbox group), 'inputCreateId' (input box with "Generate" button, integrating specific business logic), and 'slot' (custom slot, used for fully customized UI).

[0030] 2. value(data binding key, string, required): Specifies the attribute key name corresponding to this field in the central form data model formData; the engine uses this key name to establish a two-way binding between the UI component and the data model (e.g., v-model:value="formData[item.value]").

[0031] 3. name(display label, string, required): The label text displayed on the form for the field, such as "username" or "department".

[0032] Regarding UI presentation and interaction attributes: placeholder(string): Placeholder text for the input box or selector.

[0033] disabled (Boolean): Controls whether the field is disabled.

[0034] options(array): For fields with type 'select', 'radio', or 'check', this attribute defines a list of options in the format [{label:'Display Text', value:'Value'}, ...].

[0035] col(layout control, number): Defines the number of columns this field occupies in the grid layout (e.g., in a 24-grid, 12 means it occupies half the width); combined with the overall layout parameter (layoutNum), it enables flexible, responsive form layouts without writing CSS.

[0036] addonAfter / suffix(string / component): Adds prefix and suffix content to the input box.

[0037] Regarding data validation and rule attributes: rule(array): Defines the validation rules for this field; it can contain various rule objects, such as {required:true, message:'This field is required'} (required rule), {pattern: / ^\\d+$ / , message:'Please enter a number'} (format rule), and custom rule functions that support asynchronous validation.

[0038] Regarding behavioral and business logic attributes: change / onchange(event callback, function): A callback function reference triggered when the field value changes; this mechanism is the core of realizing dynamic linkage between fields; for example, when the value of the "province" selection box changes, this callback function can be triggered to dynamically clear or reload the options data of the "city" selection box.

[0039] `getParams(business logic association parameter, any type)`: This is used to declaratively associate UI fields with backend business services. As shown in the original code, in a field with type 'inputCreateId', this parameter (e.g., 'EMPLOYEE') will be passed to the `onSearch` method inside the rendering engine, which in turn calls a specific backend API (`createSomeIdApi('EMPLOYEE')`). This achieves the encapsulation and reuse of specific business logic, allowing the configuration to describe not only the UI but also the behavior.

[0040] Regarding custom and extended properties: slotName(string): When type is 'slot', this property specifies the name of a named slot; the rendering engine will completely transfer the rendering control of this position to the parent component, allowing developers to insert arbitrarily complex custom Vue components, thereby handling extremely personalized UI needs that cannot be met by standard control libraries.

[0041] like Figure 2 and Figure 3 As shown, this invention provides a core, reusable Vue single-file component (e.g., named DynamicFormRenderer.vue or FormItem.vue) as the configuration-driven rendering engine for the entire solution; its internal architecture and workflow are as follows: Including input interfaces: formList(Prop, Array): The array of declarative configuration descriptors mentioned above.

[0042] formData(Prop, Object): A reactive object created by Vue reactive() or ref(), which serves as the central data storage for the entire form.

[0043] layoutNum(Prop, Number): Optional, defines the default number of columns in the form and is used to calculate the default field width.

[0044] labelCol(Prop, Object): Optional, defines the general layout of the label.

[0045] Internal core mapping table: The engine maintains a static or configurable type-component mapping dictionary internally.

[0046] Dynamic rendering and assembly process: Step 1: Traversal and Parsing: The engine uses Vue's v-for directive to traverse the formList array.

[0047] Step 2, Component Matching: For each item, obtain the corresponding Vue component constructor through componentMap[item.type].

[0048] Step 3: Dynamically generate attributes: Dynamically construct the props object of the target component instance based on various UI attributes (placeholder, disabled, options, etc.) on the item.

[0049] Step 4: Data Binding and Assembly: Use Vue's directives or composition API to generate data binding similar to... <component v-model:value=""formData[item.value]”… / ">The binding relationship enables real-time synchronization between the UI and formData.

[0050] Step 5: Event Listener Mounting: If the item defines change, onchange, or an event supported by the engine (such as @search), the corresponding event listener is dynamically created and bound to the component instance; the listener function can access the relevant parameters on the item (such as getParams).

[0051] Step 6, Conditional Rendering and Slot Handling: Special types are handled using the v-if / v-else directives; when item.type === 'slot', a slot is rendered.<slot:name="item.slotName” / > The rendering rights will be transferred.

[0052] Step 7, Output: After the above process, the engine finally generates a complete form interface in the DOM, consisting of standard UI controls and custom components, with all fields correctly bound to data and events.

[0053] Furthermore, a unified form lifecycle management API needs to be established. The rendering engine is not only responsible for UI generation but also acts as the manager of form states, providing a set of well-encapsulated, Promise-based APIs. These APIs are exposed to the parent component through Vue 3's defineExpose method. getValue(): The core submission interface; this method triggers the entire form validation process (usually calling the validateFields method of the underlying UI library's Form instance); if all validations pass, it returns the formatted complete formData; if validation fails, it returns false or a specific error message object; business components only need to call this interface when submitting data.

[0054] getFieldsValue(): Data snapshot interface; does not trigger validation, directly returns a shallow copy of the current formData object or the value of a specific field; suitable for scenarios such as data preview and temporary storage.

[0055] `resetValue(data?):` Resets the form; resets the values ​​of all fields in the form to empty or to the values ​​corresponding to the passed-in `data` object; commonly used in "clear" operations or "edit backfill" scenarios.

[0056] validateFields(fieldNames?): Fine-grained validation interface; optional, used to validate specified fields.

[0057] These APIs standardize complex form operations, allowing upper-level business logic to completely ignore the internal implementation details of the forms, thus achieving a good separation of concerns.

[0058] Furthermore, this solution achieves scalability through plug-in architecture and deep business integration mechanisms; First, custom rendering slots: Through the type:'slot' mechanism, this invention acknowledges and supports boundary cases that cannot be covered by the standard process; the parent component can inject any Vue component through a named slot, which can have its own independent state, logic and style; the engine is responsible for providing it with the correct layout context, realizing non-intrusive extension of the framework.

[0059] Secondly, declarative business logic binding: As shown in the implementation of the onSearch method in the original code, this invention advocates encapsulating reusable business logic (such as calling specific APIs) into independent functions; but the key innovation is that the triggering conditions and parameters required for the execution of this logic are entirely defined by the field descriptor item; for example, a "Generate Employee Number" button and a "Generate Order Number" button can share the same onSearch method, passing different business identifiers (such as 'EMPLOYEE' or 'ORDER') only through item.getParams; this achieves deep decoupling of business logic and UI components and ultimate logic reuse.

[0060] Finally, layout configuration: By combining layoutNum and each item.col, forms can be configured from single-column to multi-column, or even complex mixed layouts. All layout information is contained in the configuration data, eliminating the need for front-end developers to adjust style code, which facilitates visual consistency and batch modifications later.

[0061] The dynamic rendering and assembly process of this invention includes: Iteration and parsing: The engine uses Vue's v-for directive to iterate through the formList array; Component matching: For each item, retrieve the corresponding Vue component constructor using componentMap[item.type]. Dynamic property generation: Dynamically construct the props object of the target component instance based on various UI properties (placeholder, disabled, options, etc.) on the item; Data binding assembly: Using Vue's directives or composition APIs to generate similar... <component v-model:value=""formData[item.value]”… / ">The binding relationship enables real-time synchronization between the UI and formData; Event listener mounting: If the item defines change, onchange, or events supported by the engine (such as @search), the corresponding event listener is dynamically created and bound to the component instance. The listener function can access the relevant parameters on the item (such as getParams). Conditional rendering and slot handling: Special types are handled using the v-if / v-else directives. When item.type === 'slot', a slot is rendered.<slot:name="item.slotName” / > The rendering rights will be transferred. Output: After the above process, the engine finally generates a complete form interface in the DOM, consisting of standard UI controls and custom components, with all fields correctly bound to data and events.

[0062] Example 2: The difference between this embodiment and Embodiment 1 is that the declarative configuration form descriptor uses YAML format instead of JSON Schema or JavaScript objects. YAML format has higher readability and is easier for non-technical personnel to manually edit and maintain. The user configuration unit contains a YAML parser to convert the user-input YAML configuration into an internally unified structured data model. This structured data model still consists of an array of multiple field descriptor objects, each of which includes at least a type attribute, a value attribute, and a name attribute. In addition, the configuration management unit also adds a configuration version management module to perform version marking and incremental update detection on each issued configuration descriptor. When a change in configuration version is detected, only the different parts of the configuration descriptor are issued, reducing network transmission overhead and improving runtime update efficiency.

[0063] Example 3: The difference between this embodiment and Embodiment 1 is that the UI presentation and interaction property group in the field descriptor not only includes the disabled property, options property, and col property, but also further includes: the className property (supporting string, object, or function forms) for dynamically controlling the field style class, the hidden property (supporting boolean values or function expressions based on the form data model) for controlling whether the field is visible, and the tooltip property for setting the field prompt information; among them, the hidden property supports declarative conditional expressions, such as {hidden: "formData.status === 'disabled'"}, and the core rendering engine recalculates this expression every time the form data changes to dynamically display or hide the corresponding field, thereby implementing complex conditional rendering logic without writing additional JavaScript code.

[0064] Embodiment 4: The difference between this embodiment and Embodiment 1 is that the rule property in the field descriptor not only supports synchronous and asynchronous verification rules for single fields, but also supports cross-field association verification rules. Specifically, the rule property can include a dependencies field for declaring a list of value key names of other fields on which this verification depends; when the value of any dependent field changes, the re-execution of this verification rule is automatically triggered. In addition, for asynchronous verification rules, the core rendering engine internally maintains a verification task queue and supports a cancellable Promise mechanism: when a new asynchronous verification of the same field is triggered, the previous unfinished verification request is automatically cancelled to avoid error prompts caused by race conditions. The verification results are displayed through a unified error prompt component, which supports customizing the error message template.

[0065] Embodiment 5: The difference between this embodiment and Embodiment 1 is that the change or onchange event callback function in the field descriptor is not directly referenced to a JavaScript function, but is described using a declarative expression language. This expression language is based on JSON Path or a custom lightweight expression syntax, allowing users to write linkage logic in string form, such as: "formData.city = formData.province === 'Guangdong'? 'Shenzhen' : ''". The core rendering engine internally embeds an expression evaluator that resolves and executes this expression when the field value changes to achieve automatic update of other field values, dynamic filtering of the option list, or switching of the field disabled state. This method does not require writing and deploying additional JavaScript code, making the form linkage logic fully configurable and supporting dynamic distribution from the backend.

[0066] Example 6: The difference between this embodiment and Embodiment 1 is that the core rendering engine is based on the React framework instead of the Vue framework. Internally, the engine maintains a type-component mapping table. By traversing the array of field descriptors, it looks up the corresponding React component type in the mapping table based on the `type` attribute of each field descriptor. During dynamic rendering, the `React.createElement` method is used to construct component elements, and the properties in the field descriptors are converted into React props objects. The `value` property achieves two-way data binding of the controlled component through `valueprop` and the `onChange` callback. Reactive unified state management is implemented using React's `useReducer` or `useState` Hook, and the form data model is stored in a centralized `state` object. Layout management dynamically calculates the width of each form item using CSS Grid or Flexbox combined with the `col` property. External API interfaces are exposed to the parent component through the `useImperativeHandle` Hook, implementing lifecycle management methods such as `getValue`, `getFieldsValue`, and `resetValue`.

[0067] Example 7: The difference between this embodiment and Embodiment 1 is that when the `type` attribute of the field descriptor is `slot`, the core rendering engine not only renders a named slot but also supports a dynamic component registration mechanism. Specifically, users can pre-register a custom component library in the configuration management unit, with each custom component associated with a unique component name. In the field descriptor, the name of the custom component to be dynamically loaded is specified through the `componentName` attribute, instead of using a fixed slot name. At runtime, the core rendering engine retrieves the component constructor from the component registry based on the `componentName` and dynamically instantiates it. Simultaneously, this field descriptor supports the `scopedSlots` attribute, used to define the scope data passed to the custom component, such as the current form data model and form validation status, enabling the custom component to deeply interact with the host form environment. This mechanism allows third-party developers to extend form controls as plugins without modifying the core rendering engine code.

[0068] Example 8: The core rendering engine adds a lazy-loading rendering module and a virtual scrolling module for form scenarios containing a large number of fields (e.g., more than 50 fields).

[0069] Regarding the lazy-loading rendering module: When the length of the form field descriptor array exceeds a preset threshold (e.g., 30), the engine will not render all form items at once. Instead, it will prioritize rendering fields within the visible area and fields with high user interaction frequency (such as input boxes and selectors). For fields located outside the visible area and not necessarily displayed immediately (such as the note box at the bottom and the attachment upload area), the engine will replace them with a placeholder component and listen for the scroll event of the form container or use the Intersection Observer API. When the placeholder enters the visible area, the actual field component will be dynamically loaded and rendered. This mechanism significantly reduces the number of DOM nodes in the initial rendering and the component instantiation overhead, improving page loading speed and interactive response performance.

[0070] Virtual scrolling module: For forms with a very large number of fields (e.g., more than 100 fields) and a single-column vertical layout, the engine wraps the form area in a virtual scrolling container. This container only renders a few form items near the current scrolling viewport (e.g., within twice the viewport height), rather than all fields. The engine dynamically calculates the total height and offset of the scrolling container based on the estimated height of each form item or the actual cached height after rendering, and dynamically creates and destroys DOM elements of form items far from the viewport during scrolling. The virtual scrolling module works in conjunction with the lazy loading module: for fields that have not yet been loaded, the virtual scrolling container displays a skeleton screen or a loading prompt, and the actual component is rendered only after scrolling to the desired position. Field descriptor extension: To support the above optimizations, the field descriptor adds a `lazyRender` property (boolean, default false) to explicitly indicate whether the field allows lazy loading; and a `virtualScroll` property (boolean or object) to specify whether the field participates in the virtual scroll layout and its placeholder height. When iterating through `formList`, the core rendering engine prioritizes checking these properties and, in conjunction with global performance configuration, determines the actual rendering strategy for the field. This implementation solves the problems of page lag and excessive memory usage that may occur in complex business systems (such as dynamic questionnaires and large configuration panels) with a large number of form fields, achieving high-performance large-scale form rendering while maintaining the advantages of declarative configuration.

[0071] Example 9: The declarative configuration form descriptor adds a permission and security attribute group to implement fine-grained field-level access control, including visibility, editability, and data anonymization strategies.

[0072] Permission attribute group: Each field descriptor may contain a permission attribute, the value of which is an object that includes at least the following sub-attributes: role: A string or array of strings that specifies the user role identifiers allowed to access this field (e.g., ["admin", "manager"]). The core rendering engine will retrieve the current user's role list from the global context before rendering. If the current role does not match, the rendering of this field will be automatically skipped (equivalent to the field not existing).

[0073] editableRole: A string or array of strings that specifies the role that is allowed to edit this field; if the current role only has viewing permissions and not editing permissions, the engine renders the field as a read-only form (such as plain text or a disabled input box).

[0074] hiddenRole: A string or array of strings that specifies the role (with higher priority than role) for which the field should be hidden.

[0075] mask: Data anonymization rules, for example {type:"phone",showLast:4} means that only the last 4 digits of the phone number are displayed, and the rest are replaced with asterisks; this rule only takes effect when the field is in read-only or view mode, and the original data is displayed in edit mode.

[0076] Dynamic Permission Parser: A permission parsing module has been added to the configuration management unit. Before configuration is issued or the engine renders, this module preprocesses the configuration descriptors based on the current user's context (role, department, custom tags, etc.), filters out field descriptors that the user does not have permission to access, and dynamically adds the disabled:true attribute and de-identification style to fields that can be viewed but not edited. The permission parser supports synchronous and asynchronous permission verification functions and can dynamically obtain user permission policies from the backend service.

[0077] Runtime permission update: The updatePermission method has been added to the external API interface, which allows the business layer to dynamically update the permission status of fields based on user operations (such as switching roles or changing work modes) when the form is running. The engine automatically re-renders the affected fields without refreshing the entire form.

[0078] In the description of this invention, unless otherwise explicitly defined, terms such as "set up," "install," and "connect" should be interpreted broadly, and those skilled in the art can reasonably determine the specific meaning of the above terms in this invention in conjunction with the specific content of the technical solution.

[0079] This specific embodiment is merely an explanation of the present invention and is not intended to limit the invention. After reading this specification, those skilled in the art can make modifications to this embodiment without contributing any inventive step, but such modifications are protected by patent law as long as they are within the scope of the claims of the present invention.< / component> < / component>

Claims

1. A method for generating dynamic web forms based on declarative configuration, characterized in that, Includes the following steps: Step S1: Establish a user configuration unit to collect user configuration information and read the user configuration information through a declarative configuration form descriptor. Step S2: Establish a configuration management unit for parsing, validating, storing, and distributing the declarative configuration form descriptor; Step S3: Establish a core rendering engine to perform component mapping, dynamic rendering, event binding, and layout management based on the received declarative configuration form descriptor, in order to generate a dynamic form interface description. Step S4: Establish a response unit, which includes a form data model module and a UI rendering module. The form data model module is used to perform reactive unified state management on the native API object that constructs form data. The UI rendering module is used to perform grid layout rendering of standard components or custom slots on the interface description generated by the core rendering engine to generate the final interactive form. Step S5: Establish an external API interface to expose lifecycle management methods for manipulating the dynamic form to the outside world.

2. The Web dynamic form generation method based on declarative configuration according to claim 1, characterized in that: The declarative configuration form descriptor is a structured data model based on JSONSchema or JavaScript objects, the core of which is an array of multiple field descriptor objects; Each field descriptor includes at least the following: a type attribute to specify the type of the UI control, a value attribute to establish two-way data binding, and a name attribute to set the display label.

3. The Web dynamic form generation method based on declarative configuration according to claim 2, characterized in that: The field descriptor also includes a UI presentation and interaction attribute group, which includes one or more of the following: a disabled attribute for controlling the disabled state of the field, an options attribute for defining a list of options, and a col attribute for controlling the width of the field in the grid layout.

4. The Web dynamic form generation method based on declarative configuration according to claim 2, characterized in that: The field descriptor also includes a data validation attribute group, which includes a rule attribute. The rule attribute is used to define the synchronous or asynchronous validation rules for the field. The validation rules include at least mandatory field validation rules and format validation rules.

5. The Web dynamic form generation method based on declarative configuration according to claim 2, characterized in that: The field descriptor also includes a behavior and business logic attribute group, which includes a change or onchange event callback function for implementing dynamic interaction between fields, and a getParams parameter for declaratively associating UI fields with backend business services.

6. The Web dynamic form generation method based on declarative configuration according to claim 2, characterized in that: The core rendering engine maintains a type-component mapping table. During dynamic rendering, it iterates through the array of field descriptors, looks up the corresponding Vue component constructor from the mapping table based on the type attribute of each field descriptor, and dynamically constructs the component's props object and event listeners to complete the component instantiation.

7. The Web dynamic form generation method based on declarative configuration according to claim 1, characterized in that: The external API interfaces include at least: a getValue interface for triggering overall form validation and returning form data after successful validation; a getFieldsValue interface for directly returning the current form data without triggering validation; and a resetValue interface for resetting form data.

8. The Web dynamic form generation method based on declarative configuration according to claim 2, characterized in that: When the type attribute of the field descriptor is valued as slot, the core rendering engine renders a named slot, transferring rendering control of the field to the parent component to allow the injection of custom components.

9. The Web dynamic form generation method based on declarative configuration according to claim 1, characterized in that: The reactive unified state management in step S4 is implemented based on Vue3's reactive or ref API. The core rendering engine uses the v-model:value directive to bind the UI components to the corresponding attributes in the form data model module in two directions.

10. The Web dynamic form generation method based on declarative configuration according to claim 1, characterized in that: The layout management in step S3 is achieved by receiving the overall layout parameter layoutNum and combining it with the col attribute value in each field descriptor to dynamically calculate the width of each form item in the grid layout.

Images