gnustep-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unresolved Issues with libxml2


From: Ivan Vučica
Subject: Re: Unresolved Issues with libxml2
Date: Thu, 8 Mar 2012 17:40:15 +0100

On Wed, Mar 7, 2012 at 23:33, Fred Kiefer <address@hidden> 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 - address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]