[GNOME] GXml: This Halloween, redundant code dies

XPath, Attr, and a tale most foul

 

I'm working on merging Adam Ples' patch for XPath support (branch: xpath), and I notice that a test failed because they were expecting the GXmlDocument to be able to translate from an xmlAttrPtr to a GXmlAttr.  (GXmlDocument remembers a mapping between xmlNodePtrs to GXmlNodes already to avoid duplicating its proxy nodes.)  The patch's expectation is reasonable, but for a variety of reasons, most of all that xmlAttr != xmlNode (except that they sort of do), GXmlAttrs are not considered "backed nodes" (unlike the other GXmlNode types (like GXmlElement) that have an xmlNodePtr behind them) so we don't map between them (and attrs are handled more just like strings (which we need to do, because there isn't really a xmlSetPropNode in libxml2, for instance).  Also, because at one point wanted to use a more familiar GLibHashTable to store an element's mapping of attribute names to attribute values, rather than the NamedNodeMap that the W3C DOM specifies.  However, perhaps it's worth changing how things are done to support the xpath's code's reasonable assumption.



So I looked over the GXmlAttr, GXmlElement, and GXmlDocument code and realised that if I do treat xmlAttrs as xmlNodes where it's safe to do so, I could greatly simplify a lot of code.  And, also, if I do implement the NamedNodeMap for accessing an element's attributes, I could also remove a complicated kludge in GXml which currently requires synchronising elements' attributes between the GLibHashTable they've been stored in and the libxml2 structures they need to be in when doing tasks like saving to disk or stringifying a node or document.



Consequently, there's a new branch in GXml called newattr where this is happening.  Attr.vala loses 85 lines of code, Element.vala loses 127, and Document loses 38.  NamedNodeMap.vala adds 130, with a big chunk of that being a copyright notice and comments, though. :)  Overall, there's a net difference of 119 lines removed (so it's not that massive, but!), including the complexity of syncing Elements at all (needing to remember to call a method to sync each time you might want to was error prone and a delayed performance penalty), and the reduction in parallel code between GXmlAttr and other nodes.  YAY!



I'm considering offering some GLibHashTable-style convenience methods to GXmlNamedNodeMap (like lookup and size) so anyone who has to port will have an easier time (they'd just wrap get_named_item and get_length, for example).  Let me know if you have an opinion on that!



GXml going forward



The next stable release is waiting for this to happen (since it will include API breaks from the summer anyway).  Also, Owen Taylor provided useful advice to me at the conclusion of the Summer of Code that has led to much more useful documentation regarding memory handling of GXml objects, which is already in git master.  The devhelp gtkdocs that valadoc generates have some oddities that I still need to investigate, but I don't think I'll let that be a blocker.  So, if you use the latest documentation and something's unclear, let me know (by filing a bug!)