On Wed, Mar 7, 2012 at 23:33, Fred Kiefer <fredkie...@gmx.de> 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 - i...@vucica.net
_______________________________________________
Gnustep-dev mailing list
Gnustep-dev@gnu.org
https://lists.gnu.org/mailman/listinfo/gnustep-dev
