in my application i need to do several HTTP requests. All those requests return XML-Documents which need to be parsed and then go into table views or whatever… It’s about 10-20 Documents throughout the whole application. Attributes with the same name can occur in different documents so i need to differentiate these in my delegate methods.
My approach was to have only 1 class with the NSXMLParserDelegate methods, using different parsers per document (but with the same delegate) and differentiate between the parsers (aka documents) using the parser-argument in the delegate methods. but this is getting quite complex and i don’t wanna end up with tons of different parser-instance-variables and if clauses.
isn’t there a simpler way to do this? i thought of having 1 class per parsing operation (=> different delegates), but i guess that’s even worse..
One option is to put the XML delegate callbacks and/or data construction methods on the object that will get created from parsing that specific xml type. That would place the definition of the object along with the knowledge of how to create it from xml or data chunks in one place. By trying to place all of the parsing logic for all types in one delegate methods it’s over complicates that one delegate class and splits the knowledge of each of the types you’re working with.
The one challenge with that approach is composite objects. For example, if you have an artist object, an album object that contains an artist, and a call that gets a list of artists. One approach there is to have the composite object that’s parsing defer to that other object class (perhaps with your own protocol). For example, The album object is parsing and hits an “artist” element. So it knows to alloc an artist and as it hits data chunks from the delegate callbacks (until it hits close artist element) – it’s going to keep calling your protocol methods stuffing data into in. That defers the knowledge of what to do with that chunk of data to the class that defines that object. For a class that’s processing a list of artists it would have done this n times building up a list. A call that gets one artist (delegates on the artist class) would still call those sate data chunk stuffing methods on the artist object.
Finally, constructing objects as the XML is parsed, if done right, can have the benefit of keeping memory lower and perform faster. In contrast buffering up the complete xml string, creating a full XML DOM can use more memory which can also be slower for the user. So, consider performance as well.