An iReport-based general web form generation method and system
By using iReport-based metadata processing and form design template generation methods, the problem of inconsistent formats between PDF forms and web forms was solved, achieving automated form design and cross-platform compatibility, and improving system scalability and user experience.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- JIANGSU WAFA INFORMATION TECH CO LTD
- Filing Date
- 2025-05-23
- Publication Date
- 2026-07-07
Smart Images
Figure CN120596754B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer software technology, and more specifically, to a general web form generation method and system based on iReport. Background Technology
[0002] In current business processes, PDF forms and web forms are widely used. iReport, as a powerful PDF output template designer, excels in solving PDF generation problems. However, in many practical application scenarios, PDF forms and web forms need to maintain consistent formatting to facilitate user operation and unified data management. Traditional methods often require designing and maintaining PDF forms and web forms separately, which not only increases development costs and time but also easily leads to formatting inconsistencies, resulting in poor user experience and difficulties in data processing. Therefore, an innovative technical solution is needed to address this issue. Summary of the Invention
[0003] The purpose of this invention is to provide a general web form generation method and system based on iReport to improve the aforementioned problems. To achieve this purpose, the technical solution adopted by this invention is as follows:
[0004] In a first aspect, the present invention provides a general web form generation method based on iReport, comprising:
[0005] Obtain document information, identify the document's metadata information and the attribute information that defines the metadata information, and obtain a structured set of metadata definitions;
[0006] Based on the metadata definition set and the form design function of i Report, the arrangement and attribute mapping of each object in the preset form basic interface are processed to obtain a form design template with the mapping relationship between interface controls and corresponding document attributes.
[0007] Based on the form design template, the Web control rendering engine and iReport's PDF generation function are called respectively to perform page control or file template rendering processing to obtain HTML pages and / or PDF files that can be used for user web data entry;
[0008] User data is entered and validated based on the HTML page to obtain standardized form data.
[0009] Secondly, the present invention also provides a general web form generation device based on iReport, comprising:
[0010] The acquisition unit is used to acquire document information, identify the metadata information of the document and the attribute information that defines the metadata information, and obtain a structured metadata definition set;
[0011] The mapping unit is used to process the arrangement and attribute mapping of each object in the preset form basic interface according to the metadata definition set and the form design function of iReport, so as to obtain a form design template with the mapping relationship between interface controls and corresponding document attributes.
[0012] The rendering unit is used to call the Web control rendering engine and iReport's PDF generation function respectively according to the form design template to perform page control or file template rendering processing, so as to obtain an HTML page and / or PDF file that can be used for user web data entry;
[0013] The processing unit is used to perform user data entry and verification processing based on the HTML page to obtain standardized form data.
[0014] The beneficial effects of this invention are as follows:
[0015] This invention provides a general web form generation method based on iReport. It fully utilizes the expressive power of structured metadata and iReport's powerful report design and PDF rendering capabilities. By extracting the multi-level metadata structure of documents, it automatically maps control types, sorts the spatial coordinates of control layouts, and outputs form templates bidirectionally. This allows for the rapid generation of both editable web pages and corresponding standardized PDF files. Furthermore, this method achieves structured data validation and standardized encapsulation through front-end and back-end separation, enhancing system scalability and platform compatibility. It significantly improves the automation level of form design and cross-platform deployment efficiency, exhibiting good versatility, maintainability, and output consistency, overcoming several shortcomings of existing technologies in terms of flexibility, efficiency, and standardization.
[0016] Other features and advantages of the invention will be set forth in the following description, and will be apparent in part from the description, or may be learned by practicing embodiments of the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures particularly pointed out in the written description, claims, and drawings. Attached Figure Description
[0017] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present invention and should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.
[0018] Figure 1 This is a schematic diagram of the general Web form generation method based on iReport described in an embodiment of the present invention;
[0019] Figure 2 This is a schematic diagram of the general web form generation device based on iReport described in an embodiment of the present invention.
[0020] In the diagram: 701, Acquisition module; 702, Mapping module; 703, Rendering module; 704, Processing module. Detailed Implementation
[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.
[0022] It should be noted that similar reference numerals and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. Furthermore, in the description of this invention, terms such as "first," "second," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.
[0023] Example 1:
[0024] This embodiment provides a general web form generation method based on iReport.
[0025] See Figure 1 The figure shows that the method includes steps S1, S2, S3 and S4.
[0026] Step S1: Obtain document information, identify the metadata information of the document and the attribute information defining the metadata information, and obtain a structured metadata definition set;
[0027] Understandably, this step first automatically or semi-automatically retrieves the document information to be processed from the business system, typically including data carriers with fixed structures such as invoices, contracts, and application forms. To achieve universal form generation, the key lies in metadata processing of these document contents, that is, abstracting each information element in the document into "metadata" with clear semantics. In this process, the system needs to identify the document's structural hierarchy through a rule engine or configuration template. For example, "basic invoice information" is identified as the main structure metadata, "invoice details" as the substructure metadata, and additional information for detail items, such as remarks, is further categorized as sub-structure metadata. This hierarchical structure not only reflects the subordinate relationships between data but also provides a basis for the subsequent nesting and layout of form controls. After identifying the metadata information, the system further needs to extract the attribute information of each metadata item, including field name, data type (such as string, date, floating-point number, etc.), field length, whether it is required, default value, and source of optional values. These attribute definitions are obtained through preset data standardization configurations or in conjunction with the data dictionary of the business system and uniformly encapsulated into a structured "metadata definition set." This set is not only the basic data model for the entire form generation process, but also determines the control type, validation rules, and display logic. The key technical effect of this step is that it realizes the structured abstraction of any business document, has good scalability and universality, and provides standardized and systematic data support for subsequent form design and multi-terminal output. In this step, step S1 includes steps S11, S12, and S13.
[0028] Step S11: Define the structure based on the document information. Specifically, define the basic invoice information as the main structure metadata, the invoice details as the substructure metadata, and the supplementary descriptions of the invoice details as the grandchild structure metadata to obtain three levels of metadata structure information.
[0029] This step, understandably, is based on the analysis of document information and the understanding of business semantics. It involves structurally decomposing the internal components to construct a hierarchical metadata structure. Taking an invoice as a typical example, the outermost set of information, such as invoice number, invoice date, and buyer / seller information, is first identified. These unique and holistic data items are categorized as main structure metadata, representing the core content of the document. Further delving into the invoice details, recurring records such as product name, quantity, unit price, and tax rate are represented as arrays or lists in the data model, corresponding to substructure metadata. In certain business scenarios, to enhance the completeness and flexibility of the detailed description, further explanatory information is required, such as product packaging specifications, place of origin, and additional instructions. This information, attached to each detailed item, constitutes substructure metadata. This three-tiered main-sub-substructure structure not only accurately reflects the organization of data in the document but also provides a nested logical basis for subsequent control layout, ensuring the orderliness and consistency of the generated form in terms of data mapping and user interaction.
[0030] Step S12: Analyze the attributes of the metadata based on the business type of the document information, and configure the data type, length, default value and value retrieval method to obtain the attribute definition set;
[0031] Understandably, this step uses the business type of the document information as the basis for analysis, refining the attributes of the metadata items extracted in the previous step to construct a complete field semantic model. Specifically, documents of different business types (such as purchase invoices, sales invoices, and input invoices) differ in field types and usage scenarios. Therefore, the system needs to call the built-in business rule engine or associated metadata dictionary to intelligently identify and configure the attributes of each metadata item. Taking the "Invoice Date" field as an example, in a sales invoice, this field should be defined as a "date type" with a fixed length of "10" and can be set as a required field, with the default value being the current system date. The "Tax Rate" field, on the other hand, should be a "floating-point type" with value constraints (such as a value range of 0.00 to 0.17), and a standard tax rate list can be obtained through configuration dropdown options or dynamic interfaces. During this process, the system also supports configuring multilingual identifiers, front-end display names, and validation logic for fields to ensure the completeness and controllability of attribute definitions. Ultimately, all field types, lengths, default values, required fields, and value retrieval methods (fixed, enumerated, API calls, etc.) are encapsulated into a unified "attribute definition set." This set serves as the basis for subsequent control generation and validation logic derivation, ensuring a high degree of consistency between the form's semantic expression and business rules. The technical effect of this step is that by introducing a business type-driven metadata attribute modeling mechanism, the system gains the ability to flexibly model heterogeneous documents, and the standardized attribute configuration improves the accuracy and consistency of data collection, laying a solid foundation for control matching, input validation, and form adaptation.
[0032] Step S13: Enter the attribute definition set into the standard message management page according to the hierarchical structure to obtain a structured metadata definition set.
[0033] This step involves inputting the attribute definition set generated in the previous stage into the standard message management page according to the master-child-grandchild hierarchy, and completing the formatted organization and structured storage to generate a unified and parsable metadata definition set. This process is not merely a simple input of field attributes; more importantly, it achieves the mapping and binding between the business data model and the system form engine. The system allows users to categorize and attach each field to the corresponding structural nodes according to the hierarchical order through a graphical interface or configuration tools, ensuring the accuracy of parent-child relationships, field arrangement order, and structural nesting logic. During the input process, the definition of each field (including data type, length, default value, whether it is required, and value retrieval method) is persistently stored in a unified data model format (such as JSON or database structure) and archived using a unique message identifier. Simultaneously, this structured metadata set can be directly called by the subsequent form control generation module to achieve automatic mapping from metadata to controls and rule deduction for interface layout.
[0034] Step S2: Based on the metadata definition set and the form design function of iReport, the arrangement and attribute mapping of each object in the preset form basic interface are processed to obtain a form design template with the mapping relationship between interface controls and corresponding document attributes.
[0035] Understandably, this step achieves automatic conversion from abstract data models to specific interface elements. A structured mapping mechanism ensures consistency between forms and data models, significantly reducing the workload of manual form design, improving form generation efficiency and configuration accuracy, and supporting consistent template reuse across different output channels. In this step, step S2 includes steps S21 and S22.
[0036] Step S21: Perform control mapping processing based on the structured attribute definition set. By mapping field types to controls, a control mapping scheme is obtained.
[0037] Understandably, in this step, the system takes a structured set of attribute definitions as input and generates a control mapping scheme with semantic matching capabilities through the rule-based mapping relationship between field types and control types. Specifically, the system intelligently selects the corresponding form control type based on the data type defined in each metadata item (such as string, integer, floating-point number, boolean value, date, enumeration, etc.). For example, string types are mapped to text fields (TextField), boolean types to check boxes (CheckBox), date types to date pickers (DatePicker), and enumeration or limited value types to dropdown boxes (ComboBox) or radio buttons (RadioButton). In addition, the system further refines the behavior attributes and validation logic of the controls based on the additional attributes of the fields, such as "whether it is read-only," "whether it is required," "maximum length," and "value retrieval method" (fixed, API retrieval, dictionary item), to ensure that the functionality of the controls conforms to business rules.
[0038] This control mapping is not limited to a one-to-one correspondence between a single field and a control. For fields with nested structures (such as arrays or sub-tables), the system will identify their hierarchical attributes and generate complex controls such as grid / table controls or reusable panel controls (subform) to support batch input of multiple data entries. The control mapping scheme is ultimately output as a structured configuration (such as JSON format) for subsequent form layout and rendering engine calls.
[0039] Step S22: Send the control mapping scheme to the iReport tool for form layout processing. During form layout processing, set all input boxes to the textField type and write the metadata name in the expression field in the format ${metadata name}. Set the attributes of the input boxes to preset parameters or use expressions to convert them to obtain a form design template containing the mapping relationship between interface controls and corresponding document attributes.
[0040] Understandably, this step sends the generated control mapping scheme to the iReport tool, initiates the form layout processing flow, and concretizes the abstract field-control mapping relationship into a visual design template. Considering iReport's limitations on control type support and its versatility in form printing and PDF generation scenarios, the system adopts a unified control configuration strategy during control layout processing: all fields are uniformly set to the textField type. This approach ensures layout consistency and universal adaptability for subsequent data population, especially suitable for scenarios where PDF format output is the core objective.
[0041] In its implementation, each textField control is automatically populated with a binding expression in the format ${metadata name}. This expression is dynamically parsed and populated by iReport during template rendering. Simultaneously, other properties of the control are configured by the system according to preset parameters or rules defined in the metadata, such as setting whether the field is editable, font style, display width, height, and alignment. This achieves automatic conversion from control mapping schemes to visual form templates, ensuring that each metadata field has a corresponding expression entry point in the interface. Furthermore, the unified control type and binding expression mechanism improves the flexibility of template maintenance and cross-scenario compatibility, making it particularly suitable for mixed application scenarios supporting web data entry and PDF printing.
[0042] Step S3: Based on the form design template, call the Web control rendering engine and iReport's PDF generation function respectively to perform page control or file template rendering processing to obtain an HTML page and / or PDF file that can be used for user web data entry;
[0043] It is understandable that this step establishes a form rendering mechanism based on a unified template-driven approach, adaptable to multi-terminal output. Through collaborative rendering using both Web and PDF engines, it not only significantly reduces the repetitive work of developing and maintaining form styles for different terminals, but also ensures data and performance consistency across various usage scenarios, meeting the core requirements of business systems for efficient and loosely coupled form generation. In this step, step S3 includes steps S31, S32, S33, and S34.
[0044] Step S31: Traverse and obtain all control information and metadata binding relationships in the form design template;
[0045] Understandably, this step involves traversing the complete structure of the form design template to automatically extract detailed attribute information for each control and its binding relationship with metadata. This process includes not only precise parsing of visual and functional attributes such as control type, size, position, and style, but also dynamic interpretation of control binding expressions to clarify the names and hierarchical structure of their associated metadata fields. Through deep parsing of the template (such as iReport's JRXML file or custom JSON configuration), the system can construct a mapping graph between controls and business data, ensuring data accuracy and consistency in subsequent data flow and interface rendering. Furthermore, the system may perform reasonable validation and standardization of control attributes to prevent rendering anomalies caused by design errors or configuration omissions. This step, utilizing the automated extraction of structured information from the template, greatly reduces manual intervention and improves the flexibility and efficiency of dynamic form adjustments.
[0046] Step S32: Establish a two-dimensional rectangular coordinate system with the lower left corner as the origin of the form design template, and sort each control according to its position in the two-dimensional rectangular coordinate system. The sorting rule is from left to right on the x-axis and from top to bottom on the y-axis. Recombine each control.
[0047] Understandably, this step involves introducing two-dimensional spatial modeling to spatially locate and logically sort the controls in the form design template, thereby achieving a standardized layout of controls on the page or document. Specifically, the system establishes a Cartesian coordinate system with the bottom left corner of the form page as the origin, and maps the coordinates of all controls based on their position information in the template (usually including pixel coordinates on the x and y axes). Subsequently, the system sorts the control set according to the visual reading order of "x-axis from left to right, y-axis from top to bottom" to ensure that the logical order of the controls presented when generating HTML pages or PDF documents is consistent with the natural reading order of human users.
[0048] In this process, the recombination of controls is not merely an adjustment of their visual positions, but a reconstruction of their logical structure. The system reconstructs the rendering order of controls through a sorting algorithm (such as dual-keyword sorting), enabling subsequent data binding, user interaction, and auto-fill operations to be executed more accurately and efficiently. Furthermore, this sorting mechanism supports grouping controls, ensuring the stability of their relative positions and interaction logic in complex scenarios such as responsive layouts, nested structures, or multi-column arrangements.
[0049] Step S33: Based on the metadata and field rules configured in the structured metadata definition set, fill in the description attribute of the control to obtain the assembled JSON data;
[0050] Understandably, this step, based on the extracted and structured metadata definition set, further maps the metadata field rules corresponding to each control to the control's description attributes, forming a standardized JSON data structure that can be used for subsequent rendering and interaction. Specifically, this process first identifies the binding relationship between controls and metadata, and extracts the attribute information configured for each field, such as data type (e.g., string, integer, date), input format (e.g., yyyy-MM-dd), maximum length, default value, optional value range (e.g., enumeration or dropdown data), and whether it is a required field, etc. Subsequently, this information is dynamically injected into the control's description attributes, forming a well-structured and semantically clear control configuration object. Finally, the system combines these control configuration objects into complete JSON data according to the sorted control order, serving as the data input source for the front-end rendering engine.
[0051] This process is not merely a data format conversion operation, but also a model-driven front-end description generation mechanism. It endows controls with not only visual attributes but also business semantics, enabling the front-end to automatically render controls, bind rules, and handle interactive responses based on JSON descriptions in a no-code or low-code environment. Simultaneously, this JSON data structure provides standard interfaces for debugging, template reuse, and form export, significantly improving the system's scalability and flexibility.
[0052] Step S34: Send the assembled JSON data to the front end and obtain the HTML page for user web data input, which is rendered by the front end. The front end renders the web page through a rendering rule engine, and the layout is arranged according to the coordinates of the controls, rules and input types during rendering.
[0053] Understandably, this step pushes the JSON data structure assembled in the previous stage to the front-end rendering module via an interface, driving it to complete the visual construction of the form page. This JSON data not only contains the control type, label, and data binding information, but also a complete description of each control, including its two-dimensional coordinates, input validation rules, default values, and value retrieval methods. After receiving this data, the front-end calls the built-in rendering rule engine to parse the controls item by item and complete the page layout based on the control's coordinate information. Specifically, the rendering rule engine will accurately position the controls according to the layout principle of "x-axis from left to right, y-axis from top to bottom" according to a preset grid or responsive layout framework. At the same time, it parses the input type of the controls (such as text boxes, date pickers, drop-down lists, etc.) and attaches corresponding front-end validation logic (such as regular expression validation, field length limits, conditional display, etc.) to ensure that the data entry behavior during user interaction is effectively guided and constrained.
[0054] This process enables data-driven automated front-end rendering, significantly reducing developers' reliance on manual coding of HTML page structures and styles, and improving the system's flexibility in responding to different business form requirements. By delegating complex control configurations to the back-end for unified output and automatic interpretation and rendering on the front-end, the system can quickly respond to changes in business rules, achieving dynamic form generation and automatic adaptation. This is particularly suitable for scenarios with high standardization but diverse formats, such as invoice submissions, contract entry, and government approvals. This step, following step S34, also includes steps S35, S36, and S37.
[0055] Step S35: Convert the JSON-formatted metadata in the form design template into map data according to iReport's specifications;
[0056] Understandably, this step further converts the already constructed JSON-formatted metadata into a Map-formatted data structure recognizable by iReport. This conversion is a crucial bridge between dynamic form rendering on the web and static PDF template generation in iReport. Since iReport is a report design tool for the Java environment, its data source relies on Java's key-value pair structure (i.e., Map). Therefore, the front-end JSON data structure needs to undergo semantically preserved format conversion. During this process, the system iterates through each control object in the JSON, extracting its core attributes such as "name, type, value, and validation rules," and maps them to a Map structure in a "key-value" format. The key is the metadata field name, and the value is the user input value or the control's default value. Necessary formatting is also included (e.g., converting date types to java.util.Date format, converting boolean values to boolean objects, etc.) to ensure consistency with iReport's field expression syntax.
[0057] Furthermore, the system considers the parsing mechanism for expression formats (such as ${field name}) in the iReport template, standardizing key values during Map construction to ensure precise correspondence between field names and the bound expressions in the template. When necessary, the system will also nest Map structures to support sub-level data transmission for complex form structures (such as multi-level invoice details). This structured transformation not only meets the data input requirements of the PDF generation engine but also lays the data foundation for subsequent high-fidelity report presentation.
[0058] Step S36: Using iReport's PDF rendering engine, the metadata is written into the form design template based on the mapping relationship between the interface controls and the corresponding document attributes, and saved as a PDF file;
[0059] Understandably, this step utilizes iReport's PDF rendering engine to inject the Map-formatted metadata generated in the previous stage into a predefined form design template, thus automating the generation of static PDF documents. In the iReport template, each control has established a binding relationship with the metadata fields through expressions (such as ${field name}). When the rendering engine receives the corresponding Map data, it automatically replaces the expressions referenced in each control with the values of the corresponding keys in the Map, and completes the rendering processing for styles, formats, etc. For example, in an invoice template, the field ${invoice number} will be replaced by the specific value corresponding to the "invoice number" key in the Map, and visually arranged according to the control's preset font, size, border, and other styles.
[0060] iReport's rendering engine also supports loop-filling logic for list-type controls (such as invoice details). Leveraging nested structures or sub-report functionality, it can map grandchild and child metadata structures to detail table rows, achieving accurate presentation of multi-level data in PDFs. Furthermore, this process supports conditional rendering, data format conversion (such as thousands separator for amounts and unified decimal places), and control visibility, enhancing the expressiveness and data adaptability of PDF templates. After rendering, the system outputs a complete PDF document and saves it to a specified path or memory stream for subsequent download, display, or archiving.
[0061] Step S37: Send the generated PDF file to the front-end page for display as a file stream.
[0062] Understandably, this step involves rendering the PDF file in the background and then pushing it to the front-end page as a file stream for users to preview, download, or save online. This process is typically implemented using an HTTP response stream (such as a Servlet OutputStream), which reads the PDF file from the server's memory or a local temporary storage path and writes it directly into the response body, setting appropriate response header parameters to inform the front-end browser to display the document directly in an embedded manner.
[0063] Using streaming instead of static file links offers several technical advantages: First, it avoids the security risks associated with exposing temporary files to static resource paths on the server; second, it significantly improves file transfer efficiency, supporting simultaneous generation and transfer or direct push from memory without disk I / O; third, it allows for dynamic control of access behavior before pushing the PDF based on user permissions, login status, or parameter validation, enhancing system flexibility and security. During front-end display, browsers typically integrate embedded PDF preview plugins such as PDF.js, enabling real-time rendering of streaming PDFs as page content and seamless integration with web form generation logic.
[0064] Step S4: Perform user data entry and verification processing based on the HTML page to obtain standardized form data.
[0065] Understandably, this step ensures the standardization, accuracy, and structure of data entered into the web form, providing a solid foundation for subsequent data persistence, PDF backfilling, interface transmission, and system integration. Through front-end dynamic validation and format constraint mechanisms, user input errors and back-end validation burden are significantly reduced, effectively improving the quality and efficiency of data collection. This is particularly suitable for application scenarios with extremely high data accuracy requirements, such as financial reporting, electronic contracts, and approval documents. In this step, step S4 includes steps S41, S42, and S43.
[0066] Step S41: Input the document information into the HTML5 page, and perform front-end field validation and formatting based on the information input into the HTML5 page to obtain data content that conforms to the metadata specification and obtain standardized form data.
[0067] Understandably, this step provides users with a structured data input interface via an HTML5 page. This interface has been precisely configured with control types, input formats, and validation rules based on the field rules defined in the metadata definition set. Users input actual document information (such as invoice number, invoice date, project name, amount, etc.) into the corresponding field controls on the page, and the system's front-end script immediately performs field-level validation processing on each input value. These validation operations include data type judgment (such as date format, numerical range), mandatory field determination, format consistency verification (such as email or ID card format), and enumeration value validity checks, while a front-end prompt mechanism ensures that users can correct erroneous input in a timely manner.
[0068] The data input process also incorporates front-end formatting logic. For example, the system automatically retains two decimal places for monetary fields, converts date fields to ISO format (YYYY-MM-DD), and removes spaces and illegal characters from text fields. This pre-processing data standardization strategy minimizes the back-end processing burden and improves the overall data quality and consistency of the system. After all validation and formatting, the system transforms each field input value into a standard data fragment conforming to metadata specifications, and categorizes and nests it according to a master-child-grandchild hierarchical model, ultimately resulting in standardized form data.
[0069] Step S42: Based on the data content conforming to the metadata specification, after processing by conversion rules and encapsulation in JSON format, structured JSON data is obtained;
[0070] Understandably, this step, based on predefined transformation rules, uniformly converts multi-level, complex data content into standard, structured JSON data that can be directly recognized and processed by the backend system. This transformation process is not merely a simple format conversion; rather, it involves classifying, reorganizing, mapping key-value pairs, and recursively encapsulating nested structures of the input data according to the hierarchical relationships, field attributes (such as primary key identifiers, reference fields, and data dependencies) in the metadata definition set, as well as the input logic rules under the business scenario.
[0071] For example, for an invoice, the basic invoice information serves as the main structure, which may contain multiple detailed items as substructures. Each detailed item, in turn, contains several remarks or explanatory fields as grandchild structures. During the conversion process, the system encapsulates these hierarchical fields into nested JSON objects. The main structure fields serve as the top-level keys, with substructures nested within them as arrays. Grandchild structures are further nested under their corresponding sub-items, maintaining the parent-child relationships between the data. Furthermore, the system standardizes the values of specific fields according to conversion rules, such as timestamp conversion, numerical precision control, and unified representation of Boolean values.
[0072] The technical advantage of this step lies in the fact that, through structured JSON representation, it not only ensures the semantic and hierarchical rigor of the data entered by the front-end, but also provides the back-end system with a highly unified and directly parsable standard input format. This data encapsulation method greatly improves data transmission and processing efficiency, reduces interface complexity, and ensures high scalability and compatibility of the entire Web form generation and processing system when facing complex business structures.
[0073] Step S43: After obtaining the command to click the submit button on the page, call the server-side interface to save the structured JSON data to the database.
[0074] Understandably, upon receiving the user's "Submit" button click instruction on the HTML page, this step immediately triggers the corresponding front-end event handling mechanism, sending the pre-packaged structured JSON data to the back-end service via a standardized interface protocol (such as RESTful API or GraphQL). During this process, the front-end includes the current user session information, a unique form identifier, and necessary security verification tokens to ensure the integrity and legitimacy of the submitted data. Upon receiving the structured JSON data, the back-end uses a parser to reconstruct the nested data structure and, based on the hierarchical structure and field attribute mapping information provided by the metadata definition set, performs database write operations. For data in a master-descendant hierarchy, the system first inserts it into the main table, then sequentially inserts it into the sub-tables and appendices based on the primary key, ensuring foreign key dependencies and logical integrity between data.
[0075] In real-world business scenarios, such as in an invoice management system, a submission operation means persistently storing the user-filled basic invoice information, multiple detailed items, and related instructions into the database all at once, avoiding the problems of multiple submissions and data redundancy inherent in traditional systems. Simultaneously, the system may also introduce distributed transaction control or asynchronous queue mechanisms to ensure the stability and consistency of data writes, exhibiting higher fault tolerance, especially under scenarios with large-scale concurrent access or network latency.
[0076] Example 2:
[0077] like Figure 2 As shown, this embodiment provides a general-purpose Web form generation device based on iReport. See [link to documentation]. Figure 2 The device includes an acquisition unit 701, a mapping unit 702, a rendering unit 703, and a processing unit 704.
[0078] The acquisition unit 701 is used to acquire document information and identify the metadata information and attribute information defining the metadata information of the document to obtain a structured metadata definition set.
[0079] The mapping unit 702 is used to process the arrangement and attribute mapping of each object in the preset form basic interface according to the metadata definition set and the form design function of iReport, so as to obtain a form design template with the mapping relationship between interface controls and corresponding document attributes.
[0080] The rendering unit 703 is used to call the Web control rendering engine and iReport's PDF generation function respectively according to the form design template to perform page control or file template rendering processing, so as to obtain an HTML page and / or PDF file that can be used for user web data entry;
[0081] The processing unit 704 is used to perform user data entry and verification processing based on the HTML page to obtain standardized form data.
[0082] It should be noted that the specific manner in which each module performs its operation in the apparatus described in the above embodiments has been described in detail in the embodiments of the method, and will not be elaborated here.
[0083] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
[0084] The above description is merely a specific embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should be included within the scope of protection of the present invention. Therefore, the scope of protection of the present invention should be determined by the scope of the claims.
Claims
1. A general web form generation method based on iReport, characterized in that, include: Obtain document information, identify the document's metadata information and the attribute information that defines the metadata information, and obtain a structured set of metadata definitions; Based on the metadata definition set and the form design function of iReport, the arrangement and attribute mapping of each object in the preset form basic interface are processed to obtain a form design template with the mapping relationship between interface controls and corresponding document attributes. Based on the form design template, the Web control rendering engine and iReport's PDF generation function are called respectively to perform page control or file template rendering processing, resulting in HTML pages and PDF files that can be used for user web data entry; Based on the HTML page, user data is entered and validated to obtain standardized form data; This includes acquiring document information and identifying the metadata information defining the document, including: The structure is defined based on the document information. Specifically, the basic information of the invoice is defined as the main structure metadata, the invoice details as the substructure metadata, and the supplementary descriptions of the invoice details as the grandchild structure metadata, resulting in a three-level metadata structure information. Analyze the attributes of metadata based on the business type of the document information, and configure the data type, length, default value and value retrieval method to obtain the attribute definition set; The attribute definition set is entered into the standard message management page according to the hierarchical structure to obtain a structured metadata definition set; Specifically, based on the metadata definition set and iReport's form design functionality, the arrangement and attribute mapping of objects in the preset form base interface are processed, including: Control mapping is performed based on a structured set of attribute definitions. By mapping field types to controls, a control mapping scheme is obtained. The control mapping scheme is sent to the iReport tool for form layout processing. During form layout processing, all input fields are set to the textField type, and the metadata name is written in the expression field in the format ${metadata name}. The properties of the input fields are set to preset parameters or converted using expressions to obtain a form design template containing the mapping relationship between interface controls and corresponding document attributes.
2. The general web form generation method based on iReport according to claim 1, characterized in that... Based on the form design template, the Web control rendering engine and iReport's PDF generation function are invoked respectively to perform page control or file template rendering processing, including: Iterate through and retrieve all control information and metadata binding relationships in the form design template; Establish a two-dimensional rectangular coordinate system with the lower left corner as the origin of the form design template, and sort each control according to its position in the two-dimensional rectangular coordinate system. The sorting rule is from left to right on the x-axis and from top to bottom on the y-axis. Recombine each control. Based on the metadata and field rules configured in the structured metadata definition set, fill in the description attributes of the control to obtain the assembled JSON data; The assembled JSON data is sent to the front end, and the front end renders the HTML page for users to input web data. The front end renders the web page using a rendering rule engine, and the layout is arranged according to the coordinates of the controls, rules and input types.
3. The general web form generation method based on iReport according to claim 1, characterized in that... Based on the form design template, the web control rendering engine and iReport's PDF generation function are invoked respectively to perform page control or document template rendering processing, and the process also includes: Convert the JSON-formatted metadata in the form design template into map data according to iReport's specifications; The iReport PDF rendering engine uses the mapping relationship between interface controls and corresponding document attributes to write metadata into the form design template and save it as a PDF file. The generated PDF file is sent to the front-end page for display as a file stream.
4. A general-purpose web form generation device based on iReport, characterized in that, include: The acquisition unit is used to acquire document information, identify the metadata information of the document and the attribute information that defines the metadata information, and obtain a structured metadata definition set; The mapping unit is used to process the arrangement and attribute mapping of each object in the preset form basic interface according to the metadata definition set and the form design function of iReport, so as to obtain a form design template with the mapping relationship between interface controls and corresponding document attributes. The rendering unit is used to call the Web control rendering engine and iReport's PDF generation function respectively according to the form design template to perform page control or file template rendering processing, so as to obtain HTML pages and PDF files that can be used for user web data entry; The processing unit is used to perform user data entry and verification processing based on the HTML page to obtain standardized form data; The acquisition unit includes: The first acquisition sub-unit is used to define the structure based on the document information. It obtains three levels of metadata structure information by defining the basic information of the invoice as the main structure metadata, the invoice details as the sub-structure metadata, and the supplementary descriptions of the invoice details as the grand structure metadata. The second acquisition subunit is used to analyze the attributes of metadata based on the business type of the document information, and configure the data type, length, default value and value retrieval method to obtain the attribute definition set; The third acquisition subunit is used to input the attribute definition set into the standard message management page according to the hierarchical structure to obtain a structured metadata definition set; The mapping unit includes: The first mapping subunit is used to perform control mapping processing based on a structured set of attribute definitions. By mapping field types to controls, a control mapping scheme is obtained. The second mapping subunit is used to send the control mapping scheme to the iReport tool for form layout processing. During form layout processing, all input boxes are set to the textField type, and the metadata name is written in the expression field in the format ${metadata name}. The properties of the input boxes are set to preset parameters or converted using expressions to obtain a form design template containing the mapping relationship between interface controls and corresponding document attributes.
5. The general-purpose Web form generation device based on iReport according to claim 4, characterized in that, The rendering unit includes: The first rendering sub-unit is used to traverse and obtain all control information and metadata binding relationships in the form design template; The second rendering subunit is used to establish a two-dimensional rectangular coordinate system with the lower left corner as the origin of the form design template, and sort each control according to its position in the two-dimensional rectangular coordinate system. The sorting rule is from left to right on the x-axis and from top to bottom on the y-axis, and then recombine each control. The third rendering subunit is used to fill in the description attributes of the control according to the metadata and field rules configured in the structured metadata definition set, and obtain the assembled JSON data. The fourth rendering subunit is used to send the assembled JSON data to the front end and obtain the HTML page that the user can enter web data into, which is rendered by the front end. The front end renders the web page through a rendering rule engine, and performs layout and arrangement according to the coordinates of the controls, rules and input types during rendering.
6. The general-purpose Web form generation device based on iReport according to claim 4, characterized in that, The rendering unit further includes: The fifth rendering subunit is used to convert the JSON-formatted metadata in the form design template into map data according to iReport's specifications; The sixth rendering subunit is used to write metadata into the form design template based on the mapping relationship between interface controls and corresponding document attributes using iReport's PDF rendering engine, and save it as a PDF file; The seventh rendering subunit is used to send the generated PDF file to the front-end page for display as a file stream.