The solution of xObject
The idea of xObject is based on SAX event model. Let's begin with brief description of how SAX works. Figure 3.7 shows an interaction diagram demonstrating how the sequence of events is driven by parsing XML document. The scenario in the diagram represents processing of an input XML document. As the parser parses the sections of the document, a sequence of events is generated and sent to a "DocumentHandler", which reacts to the events by customized functionality. The sequence of the events is characteristic to the structure of the input document.
Figure 3.7: Interaction Diagram: SAX processing
The future text frequently refers to "sequence of events" sent to the "DocumentHandler". The events are the executions of "DocumentHandler"'s operations shown in figure 3.8. Meaning of these operations is self explaining, each of them is called when start/end of document/element is reached. All implementations of "DocumentHandler" interface represent the customized functionality associated with the input XML document elements.
Figure 3.8: Class Diagram: DocumentHandler operations
Now back to xObject. The xObject does the same thing as the parser. It sends the sequence of events, representing the structure and data of the input document, to the "DocumentHandler". The difference between the parser and the xObject is that the parser parses a text (XML) file, while the xObject only sends the events according to required structure and data, represented by the xObject.
Let's illustrate the difference on a simple example. Assume an input document, shown in figure 3.9, which need to be processed by a "DocumentHandler".
Figure 3.9: Example: XML fragment
Figure 3.10 shows the scenario with XML parser. In this case is the input document stored either in memory or in a file. As the parser parses the XML elements, it sends events to the "DocumentHandler", which performs the required customized actions.
Figure 3.10: Interaction Diagram: event sequence by XML parser
Figure 3.11 shows more less the same interaction. The sequence of the events sent to "DocumentHandler" remains the same, because this is the purpose of both scenarios: to process the same input document (shown in figure 3.9). The difference is that the xObject is not parsing a string, it is only sending the appropriate sequence of the events to the "DocumentHandler".
Figure 3.11: Interaction Diagram: event sequence by xObject
Figure 3.12 shows the interaction of currently existing solutions. There usually is an object ("SomeObject") responsible for converting the data into XML string (using "toXML" operation). After the string is received, it is passed to the XML parser to process it, just as shown in figure 3.10.
Figure 3.12: Interaction Diagram: Currently existing solution
As already described in the "disadvantages of the existing solutions" in section "The disadvantages", this solution suffers from two extra steps: composing the XML string and consequent parsing of the XML string. While with the xObject approach, both these steps are eliminated, which has extreme impact on performance improvement and also better design, where the logic of converting data into XML is maintained separately by the xObject.
Let's focus now on the technique of generating the sequence of events by the xObject. Any component which need to present its data in XML format must implement XObject interface, shown in figure 3.13. The interface provides two operations, each for one of the major XML processing models: SAX and DOM. Whenever the component is requested to present its data in XML format, one of these operations is called.
Figure 3.13: Class Diagram: XObject operations
Now, there are two possible solutions of the xObject implementation. The first one is a custom object, built to provide specific sequence of events. An example is "XArticle", shown in figure 3.14, which is the continuation of the previously discussed "article" example. "XArticle" is an xObject and therefore has to implement "XObject" interface. Property "text" holds the value to be sent to the "DocumentHandler".
Figure 3.14: Class Diagram: XArticle
The interaction diagram presenting the "XArticle", generating a sequence of events sent to a "DataHandler" is shown in figure 3.15. Notice, that it is the "XArticle" who is responsible for invoking the "DocumentHandler"'s operations.
Figure 3.15: Interaction Diagram: event sequence by XArticle
The other solution of a xObject is a generic one. There is a library of generic xObjets which can be used for the most needed situations. As a need of other xObjects arise, new ones can be added on demand. The appropriate xObject to replace the non-generic "XArticle" is "SingleXElement". The "SingleXElement" represent single XML element. One can set its name, attributes and value. The interaction diagram showing the event sequence generated by "SingleXElement" is shown in figure 3.16.
Figure 3.16: Interaction Diagram: event sequence by SingleXElement
Figure 3.17 shows the class diagram of all generic xObjects currently available. The most important xObjects from the library are the two "XElement"s: "SingleXElement" and "XElementSet". The "SingleXElement" represents one single (non-composed) XML element, such as the "article" from figure 3.4. The "XElementSet" can, in addition to the "SingleXElement"'s functionality, contain other XML elements. An example is the "nav-bar", shown in the same figure.
The remaining xObjects from the library represents data which already are in XML format. It can be either XML file ("XStream") or XML text held in memory ("XString").
Figure 3.17: Class Diagram: xObject library
The "XDocument" and "XData" provides the notion of a "document" consisting of a data represented by the "root" element. This is used, when there is more complex process of composing the input document. If there is large amount of hierarchically connected components where each of them produces certain subtree of the input document, it is difficult to determine which one is the root element. Therefore, all the components always deal with instances of "XData" and when there is the final step --- processing of the input document, such as XSLT transformation --- then the encapsulating "XDocument" is created. The obvious reason for this approach is that only "XDocument" sends the "start/end document" events to the "DocumentHandler", which should encapsulate the overall event sequence. See the "page" example interaction diagram, shown in figure 3.19, for more about this.
When such a library of xObjects is available, then the solution of the "page" example from figure 3.6 is very simple. There is no need for designing new classes. They are all used from the library. In the figure 3.18 is an object diagram showing instances from the xObject library which solves the "page" example.
Figure 3.18: Object Diagram: the "page" example by xObjects
For the complexity of the example solution demonstration, an interaction diagram is shown in figure 3.19, presenting the event sequence generated by set of xObjects.
Figure 3.19: Sequence Diagram: "page" example