[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: pulling with expat - success!
"Clark C. Evans" wrote: > Does this code fragment help out? It is far from > perfect, however, the "pull" based code would call > getNextEvent() to return the next XML event... Thanks Clark! That was what I needed. I had my mind set on recursion and failed to think about an event queue. I was able to slide this under my API and seems to work well. Although memory usage will be higher than my solution, the design is taking advantage of expat for the lower-level details. The basic design goes like this: 1. XML::Parser::Parse() starts pulling events in a loop <loop> 2. expat calls startElement I create an Element (with the attributes) and push it on a stack I create a StartElement Event and push it on the event queue 3. expat calls endElement I create an EndElement Event and push it on the event queue. At this point I take the top Element off the element stack (which should match this EndElement), and store a pointer to it inside the Event. The element stack is there only to synchronize the events with the elements. 4. expat calls characterData: I buffer the data into a string inside the top-most element </loop> 5. When there are some events in the queue, an event is pulled off and handled If there is a handler at the current scope, it is called Otherwise, a skip-to flag is set and all events that don't get us back to the previous level are thrown away 6. When a handler is called, it pulls events from the queue and processes them until the ending-element event that matches this element is found 7. When a handler's Element::Parse() returns, the element is pushed onto a delete queue (because we can still use the Element pointer in the remainder of the handler) 8. When a handler returns, the delete queue is emptied I've only tested with some small files, but I think the design is sound. There is a lot more memory overhead (creating events and elements as they are encountered) than my previous implementation, but I'm hoping to use some memory pools for the Elements, Events, and Attributes, so the overall run-time overhead should be minimal when it's finished. Thanks for all the suggestions! -- Paul Miller - stele@f... 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/ and on CD-ROM/ISBN 981-02-3594-1 To unsubscribe, mailto:majordomo@i... the following message; unsubscribe 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
|