[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: API thoughts...
> 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(). 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. 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. 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. 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. 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
|