On Wed, Mar 7, 2012 at 23:33, Fred Kiefer <[email protected]> wrote: > > Ah, now I see where the misunderstanding comes from. Here is your code for > replacementClassForClass: > > > +(Class)**replacementClassForClass:(**Class)cls > { > if(cls == [NSXMLElement class]) > { > return [OPMLOutlineXMLElement class]; > } > if(cls == [NSXMLDocument class]) > { > return [OPMLOutline class]; > } > return cls; > } > > As you can see you are not dealing with the class NSXMLNode itself. Now > the big difference is that the current GNUstep code comes up with other > nodes as the Apple code. Most nodes are NSXMLElement and get handled > correctly by your code, but some of them are normal NSXMLNode and these get > ignored. > Now what the message you get shows is that the parse or rather the whole > libxml2 has a slightly different view on nodes than Apples code has. In > libxml2 even the string value of a node ends up as a child node. What we > could try to do is to filter out these extra nodes in our wrapper code, but > this will be a huge amount of work. > > Does my explanation help you to come to a common understanding of what is > going on here? > > Fred >
Ah, I think I get it. I'll try fixing the pieces of code that don't count on the possibility of NSXMLNode appearing (probably one or two places, I remember seeing a lot of "isKindOfClass:[OPMLOutlineXMLElement class]" calls), and at some point, I'll examine the node trees under GNUstep and Cocoa to get a better understanding of what's going on. Thanks for all the great work! -- Ivan Vučica - [email protected]
_______________________________________________ Gnustep-dev mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnustep-dev
