I take that back - I was adding a header to the returned XML which already had one. If I don't do that, I don't get a parsing error, but I don't get any delegate methods fired after the parse is called. Do I need to assign a delegate someplace else besides the [parser setDelegate:self] ?
On Tue, Jan 5, 2010 at 8:26 AM, Eric E. Dolecki <[email protected]> wrote: > Immediately after the [parser parse] I check it: > > if( [parser parseError]){ > NSLog(@"parse error"); > } > > This always fires - but I think that the XML is valid. My delegate methods > aren't firing at all - so I don't think it's a namespace issue. Does the > code seem okay? > > If I dump the stringReply into a UIWebView it renders it fine. I just want > to pull out current conditions and get the image (gif) to display in a > UIImageView... > > > > On Tue, Jan 5, 2010 at 6:38 AM, Jeremy Pereira <[email protected]> wrote: > >> >> On 5 Jan 2010, at 05:09, Eric E. Dolecki wrote: >> >> > >> > - (void)parser:(NSXMLParser *)parser didStartElement:(NSString >> *)elementName >> > namespaceURI:(NSString *)namespaceURI qualifiedName:(NSString *)qName >> > attributes:(NSDictionary *)attributeDict { >> > >> > NSLog(@"didStartElement"); >> > >> > //not sure how to handle namespaces in obj-c >> > >> > if( [elementName isEqualToString:@"yweather:condition"]){ >> > >> > NSString *thisOwner = [attributeDict objectForKey:@"text"]; >> > >> > NSLog(@"%@", thisOwner); >> > >> > } >> > >> > } >> > >> > >> >> I'm fairly sure that, if you are processing namespaces, elementName will >> not have the prefix when it comes in. Instead, the parser will maintain a >> mapping between the namespace URI and the prefix. You need to test that the >> passed in namespaceURI matches the URI you are interested in and the >> elementName is the element name you are interested in. >> >> qName will contain the prefix, but if you use that to do the test, you'll >> have to track how the prefixes are currently mapped (there's a delegate >> method to help you with that), parse out the prefix and look up its >> namespace. The reason is that for any given element you can't guarantee that >> the condition element will always be prefixed by "yweather", it depends on >> the previous xmlns mapping, nor can you guarantee that the yweather prefix >> always refers to the namespace for Yahoo weather XML, nor can you even >> guarantee there will even be a prefix e.g. >> >> <condition xmlns="http://yahoo.weather.namespace";>.... >> >> is perfectly acceptable. >> >> > _______________________________________________ >> > >> > Cocoa-dev mailing list ([email protected]) >> > >> > Please do not post admin requests or moderator comments to the list. >> > Contact the moderators at cocoa-dev-admins(at)lists.apple.com >> > >> > Help/Unsubscribe/Update your Subscription: >> > http://lists.apple.com/mailman/options/cocoa-dev/adc%40jeremyp.net >> > >> > This email sent to [email protected] >> >> >> ______________________________________________________________________ >> This email has been scanned by the MessageLabs Email Security System. >> For more information please visit http://www.messagelabs.com/email >> ______________________________________________________________________ >> > > > > -- > http://ericd.net > Interactive design and development > -- http://ericd.net Interactive design and development _______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
