[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: API thoughts...
At 2:14 PM -0800 3/5/97, Bill Smith wrote: >> Well, the Lark event-stream API sure looks & feels like a bunch of >> callbacks. You make a Lark object, call its readXML() method with one >> argument being a Handler object; Handler being a data-less class that >> just has a bunch of methods called things like doPI() and doStartTag() and >> doEntityReference() and doText() and so on; you'd normally subclass Handler >> replacing the methods for the events you wanted to see, and pass in >> that kind of object. Lark calls these upon recognizing >> the constructs in the input stream, passing the byte offset info, the >> element & entity stack (*if* you're treebuilding), and other currently >> relevant info. These methods are all booleans; if any returns true, >> Lark stops and returns control to whoever called readXML(). I like this boolean approach -- it lets the Handler object take back the flow of control, pretty easily. If Lark could break PCDATA up when the buffer stalls, you could easily implement a Browser-style application. >Another way to do this is to have the Lark object (or interface) define the >event methods rather than have a separate Handler object. When it's time to >parse something, create a subclass that overrides the (standard) event methods >for the Lark object. I don't like this quite as well for a generic API as I can see the use of Handler objects that don't know how to parse -- they can be glued to other event sources to run off of DB engines -- or even broken across a network to provide and XML event-stream mechanism... >A possible advantage to this method is that it makes clear the inheritance >relationship between the "standard" parser and something more specific. It >is also "easier" to create a more specific parser from an exisiting parser >object - simply subclass the existing parser and override the methods >required to provide the desired new functionality. If the methods in the standard parser don't do something you are interested in, you still have to do override them all -- and I don't see what default behavior would make sense other than "do nothing". It seems that you could get the benefits of having that simply by supplying a predefined Handler object that has null implementations for its methods. >The Lark model "hides" the inheritance relationship in the Handler object >making it necessary to look inside a Lark object to determine the type of >a given parser (something you might need to do when debugging). An >alternative is to create a new parser object that contains a subclassed event >handler. This makes it possible to distinguish the type of parser at the >"outer" level but requires two new objects instead of one to perform the >subclass. The debugging issue is certanly a bit inconvenient. If we use interfaces rather than classes for the API (almost certainly a good idea), then we can certainly create a Parser that implements Handler. >I'm not a parser expert so the subclass model may not make any sense but this >is a mechanism I have successfully used building other object-oriented >(including GUI-based) systems. I have also used callbacks but find them most >useful when forced to use C or other non-object-based languages. I think that subclassing here just means that I might be forced to pull in parser baggage (or null methods) when I want to implement a parser-free event handler or event generator. -- David _________________________________________ David Durand dgd@c... \ david@d... Boston University Computer Science \ Sr. Analyst http://www.cs.bu.edu/students/grads/dgd/ \ Dynamic Diagrams --------------------------------------------\ http://dynamicDiagrams.com/ MAPA: mapping for the WWW \__________________________ xml-dev: A list for W3C XML Developers Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ To unsubscribe, send to majordomo@i... the following message; unsubscribe xml-dev List coordinator, Henry Rzepa (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
|