[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XObjects
From: Tyler Baker <tyler@i...> >(1) There is a root element handler that is passed to the parser which handles >all of the events generated by parsing the root element. If a new child element >of the root element is encountered, the root element is responsible for >instantiating an element handler for the given element name. If no element >handler can be instantiated then null is returned. > >(2) All of the generic events of SAX you could consider are delegated down to >the currently selected parent element which is receiving character, element, and >pi events among others. This is done natively in my parser and has nothing to >do with SAX per se, but this sort of framework can be easily built on top of SAX >in a few hours I would think. I personally have had a lot of success using this >method (I will admit my opinion is biased by my own personal adulation) and find >it to be just about as straightforward as using Java Object Serialization as a >framework for reading and writing object state. > >(3) No registry, bindings, or any other muckety muck is necessary. All you need >is an instantiated implementation for a root element which knows how to >instantiate children elements who know how to instantiate children elements and >so on and so forth. It is equivalent to calling readObject() in Java Object >Serialization where you need to know the root object type to case to, but you >don't have to worry about the types of any of the child objects as the root >object knows what types they need to be cast to. As a component programmer (distinct from an oo programmer), I attempt to avoid embeding in a component class any knowledge of other component classes. (A component may know about interfaces and objects, but not other components.) The last thing I want is to have components created by other components using the new operator. Coins supports this programming style--all you need is a binding for the smart root. My own programming style depends on either factories or (preferably) binderies. Shouldn't XObject be able to accomodate diverse styles as well? OK, it means moving closer to the SAX DocumentHandler interface than what I had proposed. We need a START-ELEMENT to accomodate this. But then we've constrained the implementation. Tough choice. Perhaps a DOM- specific set of arguments on that START-ELEMENT would be a good compromise: public void startElement( java.lang.String name, org.w3c.dom.NamedNodeMap, org.xml.sax.Location) throws SAXException; This again allow for greater integration with the DOM without either precluding or excluding the use of SAX. Bill xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i... Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To (un)subscribe, mailto:majordomo@i... the following message; (un)subscribe xml-dev To subscribe to the digests, mailto:majordomo@i... the following message; subscribe xml-dev-digest List coordinator, Henry Rzepa (mailto:rzepa@i...)
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|