XForms Essentials, from O'Reilly. Chapter 8 Dynamic Forms | WebReference

XForms Essentials, from O'Reilly. Chapter 8 Dynamic Forms

XForms Essentials: XForms Building Blocks

XForms Essentials shows readers how to integrate XForms with both HTML and XML vocabularies. If you work with forms, HTML, or XML information, XForms Essentials will provides a simpler route to more sophisticated interactions with users. By Micah Dubinko.

An excerpt from the book: XForms Essentials by O'Reilly.

"What the world really needs is more love and less paperwork." -Pearl Bailey"XML lets organizations benefit from structured, predictable documents. Thus, XML breeds forms. QED." -David Weinberger

The previous chapter ended with a look at the simple syntax of XForms. This chapter goes into greater detail on the concepts underlying the design of XForms, as well as practical issues that come into play, including a complete, annotated real-world example.

A key concept is the relationship between forms and documents, which will be addressed first. After that, this chapter elaborates on the important issue of host languages and how XForms integrates them.

More Than Forms

Despite the name, XForms is being used for many applications beyond simple forms. In particular, creating and editing XML-based documents is a good fit for the technology.

A key advantage of XML-based documents over, say, paper or word processor templates, is that an entirely electronic process eliminates much uncertainty from form processing. Give average "information workers" a paper form, and they'll write illegibly, scribble in the margins, doodle, write in new choices, and just generally do things that aren't expected. All of these behaviors are manually intensive to patch up, in order to clean the data to a point where it can be placed into a database. With XForms, it is possible to restrict the parts of the document that a user is able to modify, which means that submitted data needs only a relatively light double-check before it can be sent to a database. (One pitfall to avoid, however, is a system that is excessively restrictive, so that the person filling the form is unable to accurately provide the needed data. When that happens, users typically give bad information or avoid the electronic system altogether.)

Various efforts are underway to define XML vocabularies for all sorts of documents. Perhaps one of the most ambitious is UBL, the Universal Business Language, currently being standardized through OASIS (the Organization for the Advancement of Structutured Information Standards). The goal of UBL is to represent all different sorts of business documents--purchase orders, invoices, order confirmations, and so on--using a family of XML vocabularies. XForms is a great tool with which to create and edit UBL documents.

A Real-World Example

As an example, this section will develop an XForms solution for creating and editing a UBL purchase order. The first step is to define the initial instance data, which is a skeleton XML document that contains the complete structure of the desired final document, but with only initial data. This document serves as a template for newly-created purchase orders, and provides a framework on which to hang the rest of the form.

TIP:   This complete example form is available online at https://dubinko.info/writing/xforms/ubl/.

Example 2-1 shows what a UBL purchase order document looks like. Figure 2-1 shows, in the X-Smiles browser, an XForms document capable of creating such a document.

Figure 2-1. An XML purchase order being created with XForms

 

Example 2-1: An XML purchase order using UBL

<Order xmlns="urn:oasis:names:tc:ubl:Order:1.0:0.70" 
xmlns:cat="urn:oasis:names:tc:ubl:CommonAggregateTypes:1.0:0.70">
  <cat:ID/>
  <cat:IssueDate/>
  <cat:LineExtensionTotalAmount currencyID="USD"/>
  <cat:BuyerParty>
    <cat:ID/>
    <cat:PartyName>
      <cat:Name/>
    </cat:PartyName>
    <cat:Address>
      <cat:ID/>
      <cat:Street/>
      <cat:CityName/>
      <cat:PostalZone/>
      <cat:CountrySub-Entity/>
    </cat:Address>
    <cat:BuyerContact>
      <cat:ID/>
      <cat:Name/>
    </cat:BuyerContact>
  </cat:BuyerParty>
  <cat:SellerParty>
    <cat:ID/>
    <cat:PartyName>
      <cat:Name/>
    </cat:PartyName>
    <cat:Address>
      <cat:ID/>
      <cat:Street/>
      <cat:CityName/>
      <cat:CountrySub-Entity/>
    </cat:Address>
  </cat:SellerParty>
  <cat:DeliveryTerms>
    <cat:ID/>
    <cat:SpecialTerms/>
  </cat:DeliveryTerms>
  <cat:OrderLine>
    <cat:BuyersID/>
    <cat:SellersID/>
    <cat:LineExtensionAmount currencyID=""/>
    <cat:Quantity unitCode="">1</cat:Quantity>
    <cat:Item>
      <cat:ID/>
      <cat:Description>Enter description here</cat:Description>
      <cat:SellersItemIdentification>
        <cat:ID>Enter part number here</cat:ID>
      </cat:SellersItemIdentification>
      <cat:BasePrice>
        <cat:PriceAmount currencyID="">0.00</cat:PriceAmount>
      </cat:BasePrice>
    </cat:Item>
  </cat:OrderLine>
</Order> 

The markup used by UBL seems slightly verbose, but this is necessary to capture all the small variations that occur in the purchase orders used by different organizations. Note that the cat:OrderLine element can repeat as many times as necessary, though only a single occurrence is needed for the initial instance data. Also note that the root element uses a different XML namespace than the rest of the document. Thanks to the context node rules in XForms, the root element never needs to be directly referred to, and thus form authors can happily ignore this minor detail.

Created: March 27, 2003
Revised: October 10, 2003

URL: https://webreference.com/programming/xforms/1