Form data processing in the electronic form Series

Yuan Yongfu (http://www.xdesigner.cn)

Click to download the concept version of the form tool.

Generally, electronic form tools require that data in relational databases be automatically displayed and saved. For example, you can use SQL statements to query data filling text boxes or query list items filled with a batch of data in the list box. In addition, the database must be updated to save user input data to the database, and database records can be added, modified, and deleted. To implement this function, form tools must set SQL statements for reading data and updating databases when customizing form templates, or set the ing between form data input elements and database fields, when running, you must directly connect to the database and execute SQL update statements to update data. However, with the development of the times, this approach exposes some problems in development and operation.

For the current large and complex information management systems, many systems use a three-tier architecture or multi-tier structure. Here we only discuss representative three-tier architecture. In the three-tier architecture, program code is divided into three parts based on functions: database processing layer, business logic layer, and data display layer (User Interface Layer ). The database processing layer specifically processes the underlying database and maintains the basic data structure. The business logic layer calls the database layer to obtain and process data as needed, while the data display layer obtains and displays data from the business logic layer.

This three-layer architecture is complex, but the program is flexible and suitable for group development. It is easy to maintain and can easily control the security and restrictions of data access. Therefore, the three-layer architecture has a great influence at present. For a three-tier database information management system, only the data processing layer can directly access the database, and other program modules cannot.

The electronic form tool is used to display and input data. In terms of function, it should be a user interface layer in a three-tier structure. It should only obtain data from the business logic layer, you should not directly connect to the database to obtain data from the database layer, or skip the business logic layer to directly update the database. But at present, some form tools do this, undermining the original meaning of the three-layer structure. Generally, when the user interface layer directly queries the database to obtain data, only the three-tier structure is affected, and the database structure is changed. If the user interface layer is not updated, the data cannot be correctly displayed at most, there is no other impact; however, the user interface layer directly updates the database and adds and modifies or deletes database records, which should damage the three-tier structure, when the database structure changes and the user interface layer is not updated, the user interface layer may damage the database, resulting in data errors and data loss. For customers, the most important thing is data rather than application systems. application systems can be replaced and crash, but data cannot be mistakenly or lost. Therefore, considering the interests of the customer and the security of the software, the use of electronic form tools to directly update the database should be carefully considered.

Some electronic form tools have the ability to automatically update database records, but in the current software development process, such functional requirements are increasingly unimportant. This is because the more developers use a variety of mature object-database ing frameworks, or use a variety of code generators to generate code to operate on low-level databases, in addition, various companies have their own specifications and traditions, and form tools should not interfere with this too much.

To sum up, the form tool is on the user interface for displaying and inputting data. In the three-tier architecture, it belongs to the user interface layer. According to the basic specifications of the three-tier architecture, the user interface layer cannot directly read and update the underlying database. Therefore, e-Forms should not directly update databases, but provide data to the business logic layer of the three-tier architecture.

The form tool exchanges form data with the application system using XML documents. The application system organizes the data to be displayed into an XML document and passes it to the form tool user interface. On the user interface, after the user confirms the input form data, the form tool organizes the form data into an XML document and returns it to the application system for subsequent processing.

In the form document, each form element that can input data has a "Data Reference" attribute, which shows how the form tool is saved in the XML document. The format of this attribute is similar to an XPath string. It can contain multiple XML node names separated.

For example, if the data reference of a text box is "Employees/Address", the form data is stored in the Address subnode of the root node of the XML document. The generated XML snippet may be

<XFormValue>
<Employees>
<Address> text value </Address>
</Employees>
</XFormValue>

If the data in this text box is referenced as "Employees/@ Address", the form data is stored in the Address attribute of the child node named "employee" of the XML document root node. The generated XML snippet may be

<XFormValue>
<Employees Address = "text value"/>
</XFormValue>

Note: The data reference here simulates XPath, not true XPath. Only the names of XML elements at all levels can be set. If the XML Attribute appears, it is placed at the end without any judgment conditions.

In practice, the final purpose of using an electronic form is to display and edit database records. In this case, you can set the data reference of the form element to "table name/field name ". The generated form XML document can be as follows:

<XFormValue>
<Employees>
<Address> fosun Gate No. 245 </Address>
<BirthDate> 0:00:00 </BirthDate>
<City> Beijing </City>
<Country> China </Country>
<EmployeeID> 1 </EmployeeID>
<Extension> 5467 </Extension>
<FirstName> Ying </FirstName>
<Goal> 2000 </Goal>
<HireDate> 1992-5-1 </HireDate>
<HomePhone> (010) 65559857 </HomePhone>
<LastName> Zhang </LastName>
<Sex> 2 </Sex>
<Title> 4 </Title>
<TitleOfCourtesy> MS. </TitleOfCourtesy>
</Employees>
<Customers>
<Address> No. 50 dachongming road </Address>
<City> Tianjin </City>
<CompanyName> Sanchuan Industrial Co., Ltd. </CompanyName>
<ContactName> Miss Liu </ContactName>
<ContactTitle> sales representative </ContactTitle>
<Country> China </Country>
<CustomerID> ALFKI </CustomerID>
<Email> Silva@lisboncycle.com </Email>
</Customers>
</XFormValue>

Obviously, for such XML documents, starting from the root node, the name of the first child node is the name of the data table, and the name of the second child node is the name of each field in the data table. In this way, it is easy to map nodes in XML documents to database tables and fields. Therefore, it is easy to develop a common routine for updating data in XML documents to databases. In addition, all the code for updating the database based on the electronic form data can be centralized in the application system.

The next article describes the user availability of form tools.