next line character a huge influence on xmlparser?
Posted
by jovany
on Stack Overflow
See other posts from Stack Overflow
or by jovany
Published on 2009-08-06T10:34:47Z
Indexed on
2010/06/09
0:02 UTC
Read the original article
Hit count: 380
I have question about a basic xml file I'm parsing and just putting in simple nextlines(Enters). I'll try to explain my problem with this next example. I'm( still) building an xml tree and all it has to do ( this is a testtree ) is put the summary in an itemlist. I then export it to a plist so I can see if everything is done correctly.
A method that does this is in the parser which looks like this
if([elementName isEqualToString:@"Book"]) {
[appDelegate.books addObject:aBook];
[aBook release];
aBook = nil;
}
else
{
[aBook setValue:currentElementValue forKey:elementName];
NSString *directions = [NSString stringWithFormat:currentElementValue];
[directionTree = setObject:directions forKey:@"directions"];
}
[currentElementValue release];
currentElementValue = nil;
}
the export for the plistfile happens at the endtag of books.
Below is the first xmlfile
<?xml version="1.0" encoding="UTF-8"?>
<Books><Book id="1"><summary>Ero adn the ancient quest to measure the globe.</summary></Book><Book id="2"><summary>how the scientific revolution began.</summary></Book></Books>
This is my output
http://img139.imageshack.us/img139/9175/picture6rtn.png
If I make some adjustments like here
<?xml version="1.0" encoding="UTF-8"?>
<Books><Book id="1">
<summary>Ero adn the ancient quest to measure the globe.</summary>
</Book>
<Book id="2">
<summary>how the scientific revolution began.</summary>
</Book>
</Books>
My directions key with type string remains empty...
http://img248.imageshack.us/img248/5838/picture7y.png
I never knew that if I just put in an enter it would have such an influence. Does anyone know a solution to this since my real xml file looks like this.
ps. the funny thing is I can actually see ( when debugging)my directions string (NSString directions ) fill up with the currentElementValue in both cases.
© Stack Overflow or respective owner