[Experience Summary] Using MSXML to copy nodes between different Dom trees

First, let's look at a piece of code:

 

// Copy the XML node <br/> bool Protocol: copyxmlnode (ccomptr <ixmldomdocument> spdocsrc, <br/> const cstring & strxpathsrc, <br/> ccomptr <ixmldomdocument> spdocdest, <br/> const cstring & strxpathdest) <br/>{< br/> ccomptr <ixmldomnodelist> spnodelistsrc; // content source node set (multiple nodes may be obtained) <br/> ccomptr <ixmldomnode> spnodedest; // The node to be filled in the template </P> <p> // The text () function must be added when strxpathsrc is used to get the attribute knot, otherwise, the node cannot be obtained. <br/> spdocsrc-> selectnodes (Ccombstr) strxpathsrc, & spnodelistsrc); <br/> If (null = spnodelistsrc) <br/> return false; </P> <p> spdocdest-> selectsinglenode (ccombstr) strxpathdest, & spnodedest); <br/> If (null = spnodedest) <br/> return false; </P> <p> long ilength; <br/> spnodelistsrc-> get_length (& ilength); </P> <p> for (INT I = 0; I <ilength; I ++) <br/>{< br/> ccomptr <ixmldomnode> spchildnode; <br/> spnodelistsrc-> get_item (I, & Spchildnode); // obtain the child node <br/> assert (spchildnode! = NULL); </P> <p> // because of the appendchild function <br/> // hresult appendchild (<br/> // ixmldomnode * newchild, <br/> // ixmldomnode ** outnewchild); <br/> // features: If newchild has an existing parent, the node is automatically removed from that parent before being inserted into its new location. <br/> // copy the node before adding the node <br/> ccomptr <ixmldomnode> spclonenode; <br/> spchildnode-> clonenode (variant_true, & spclonenode ); <Br/> assert (spclonenode! = NULL); </P> <p> spnodedest-> appendchild (spclonenode, null); // Add nodes across Dom trees (retain namespaces) <br/>}</P> <p> return true;

The purpose of writing this code is to extract information from different XML/html files and splice it into a print page (HTML), similar to the report printing function. Use the XPath statement to extract all the child nodes in the Source Path and add them to the target path. There are two difficulties in implementation. The first is that ixmldomdocument does not support namespaces. That is to say, ixmldomdocument file node objects do not support path navigation with namespaces. Microsoft is doing something very strange. // the path of xpath can go deep into the path with a namespace for search. This is not consistent with the XPath standard, however, namespace nodes can be easily extracted using methods such as // anynode. Selectnodes is used. Therefore, you must add a text () function at the end of the extraction attribute. In addition, you must add a dot (.) to the access path from the current node. Otherwise, the access will start at the root node. Every two difficulties span the DOM tree to add nodes. I didn't expect appendchild to directly support this function, but the call method is special. I have to add a null parameter later. Namespace of the added Node
Unchanged.

Recently, MSXML is often used. Compared with libxml, this API is easy to design, but Microsoft does not open source code because it has always been a tradition, many detailed documents are unclear or are not mentioned at all, so 1/3 of the implementation process is struggling with these unknown details. I still miss the days when I used libxml. I spent one afternoon studying the basic data structure of the libxml library. In the past, I was able to solve the problem and call the API flexibly according to the actual situation. Because it is open-source, you can be aware of its data structure and implementation methods, and then have a gap in your mind.

Suddenly I remembered Eric Raymond's pig: "Everything is more time-consuming and painful than he thought. In the shiny sample program of the library, reusable components seem to be unpredictable or destructive in some boundary situations-and these boundary situations are often encountered in his code. Small soldiers often wonder what the guys who write the library think. But he cannot know, because the component documentation is incomplete-those documents are written by technical clerks. They are neither programmers nor the way they want problems. He also cannot read the source code to understand what the program is, because the library is an opaque target code under a proprietary license. "

Windows programmers have a lot of trouble (coding efficiency and quality), just like piaobing. These problems are ultimately transparent. The APIS provided by Microsoft lack transparency. Many people are complacent about msdn, but do not know where the project disaster comes from. We can't fix the issue. In fact, the source code cannot be correctly used for APIs of larger scale. Only documents are supported, and practices cannot be guided. The document does not convey all the nuances of the code, but the "devil" happens to be hidden in details.

Complaints are all complaints and work is still good. The closed-Source Development Method for Windows should also have a certain pattern. Next we need to see how others do it.