[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: API thoughts...

  • From: Bill Smith <Bill.Smith@E...>
  • To: xml-dev@i...
  • Date: Wed, 5 Mar 1997 14:14:32 -0800 (PST)

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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.