|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Is event-driven programming for SAX2 (Simple API for XML) endangering your sanity? After Part 1 of this three-part series introduced SAX2 parsing, you should feel more in touch with reality! In that article, I supplied basic handler techniques, which we'll build on in this article, to keep your code manageable.
Read the whole "XML Documents on the Run" series:
In this article, I extend the SAX2 handling approach suggested in Part 1 to cope with multiple nested-structure levels within an XML document. Using that approach, you can implement a class for each structure type you need to handle, keeping your code clean and eliminating event-driven programming's messiness.
Our quest for improved XML event-stream processing doesn't end with SAX2, though. I also introduce the pull-parser approach that's increasingly gaining attention as a SAX2 alternative. With pull parsing, your program keeps control, rather than relinquishing it to the parser -- letting you avoid the event-driven hassles completely!
Note: You can download this article's example source code from Resources.
I ended Part 1 with ways to extend the event-driven handling model we'd started to develop. I mentioned that you could enhance the interface to include start elements and nesting, and promised I'd address that in Part 2. So, let's get to it!
First, here's a more complicated version of the trade history documents from Part 1:
<?xml version="1.0"?>
<trade-history>
<option-trade>
<symbol>SUNW</symbol>
<tracking id="7495733">
<time>08:45:19</time>
<seller ident="XBA" type="direct"/>
<buyer ident="ZFT" type="agent"/>
<exchange>XA</exchange>
</tracking>
<option-type>call</option-type>
<strike-price>100</strike-price>
<expiration-month>9</expiration-month>
<trade-price>13.47</trade-price>
<quantity>500</quantity>
</option-trade>
<stock-trade>
<symbol>SUNW</symbol>
<tracking id="7499345">
<time>08:45:19</time>
<seller ident="CCC" type="agent"/>
<buyer ident="ABT" type="agent"/>
<exchange>XA</exchange>
</tracking>
<price>86.24</price>
<quantity>500</quantity>
</stock-trade>
...
</trade-history>
The new version uses a new tracking element present in both the stock-trade and option-trade elements. The tracking element provides information applicable to all trade types. The types include the trade time, which we'd previously included
directly in the stock and option trade information, as well as additional items to track the parties involved and the trade
exchange.
In Part 1, to keep things simple, I stuck to the basics of using element content for our information. Now that you've seen the basics, in this article I extend the coverage to attributes. Using attributes for information rather than element content depends mainly on your style, and you'll often need to work with documents that combine the two approaches. I set up the trade-history document's new format with that in mind, and I included attribute values for useful information in the added tracking-element substructure. We'll look at how to handle such information in the following code examples.