DIV CSS 佈局教程網

 DIV+CSS佈局教程網 >> 網頁腳本 >> XML學習教程 >> XML詳解 >> 應用MSXML的DOM模型處理XML(1)
應用MSXML的DOM模型處理XML(1)
編輯:XML詳解     

DOM模型在MSXML類庫中的主要表現為把XML文件導入內存,形成一個IXMLDOMDocument,再把其中的每一個部件都用一個接口對應起來。因為還沒用MSXML進行過XSLT格式化XML文件,所以這相關的也只好避而不談了。先來個有XML基本部件的文本:

   (1)<?XML version='1.0' encoding='GB2312'?>
(2)<?XML-stylesheet type='text/xsl' href='/expert/Xsl/2.xsl'?>
(3)<body>
(4)<code1 id=”text”>文本</code>
(5)<code2 id=”cdata”>
(6)<![CDATA[
(7)這裡是CDATA的內容,可以放類似’<’等可能會和XML控制信息有沖突的內容
(8)]]>
(9)</code>
(10)</body>

為了表述方便,在第一列都放上了行號。首先從(1)~(10)夠成了一個Document,在MSXML中對應IXMLDOMDocument接口;(1)行、(2)行對應MSXML中的接口為IXMLDOMProcessingInstruction;(3)行到(10)行則為一個Root Element,對應的接口為IXMLDOMElement,(3)裡面包含的多個也是element,不過是body的下一層element。需要注意的是Root只能有一個,Root下面無論多深,理論上允許無數多個(?),且允許名稱重復;(4)和(5)裡面各有一個id=”?”這是一個attribute(注意:(1)和(2)行version;encoding;type;href等也是),對應MSXML裡的IXMLDOMAttribute;(4)裡面的“文本”看起來和(7)這一行是差不多的,都是文本信息,很多人以為都可以通過get_text()直接得到(不久以前我也以為),其實是錯的。對於“文本”是可以通過(4)這個element直接get_text()獲取,對應於IXMLDOMText,但如果在(5)這個element直接get_text()就會出錯,原因?CDATA是區別於“文本”的另外一種類型,對應於IXMLDOMCDATASection,如何獲取,後面再提。現在整個XML的基本框架似乎出來了:

<IXMLDOMDocument>
<IXMLDOMProcessingInstruction />
<IXMLDOMProcessingInstruction />
<IXMLDOMElement (根,只能有一個)>
<IXMLDOMElement IXMLDOMAttribute>
IXMLDOMText
</ IXMLDOMElement >
<IXMLDOMElement IXMLDOMAttribute>
IXMLDOMCDATASection
</ IXMLDOMElement >
<IXMLDOMElement>
</IXMLDOMDocument>

但是,看看很多關於MSXML的教程用到另外一個接口IXMLDOMNode,這個怎麼回事?和上面的IXMLDOMElement有什麼關系?前面用了這麼長時間的MSXML經常就是在這個地方弄混,以至無所進展,最近要在C++Builder5下面使用XML解析,可是沒有TXMLDocument控件,想自己封裝一下MSXML的一些使用才發現其中的奧妙。在DOM模型中把包括Document、ProcessingInstruction、Attribute、Element、TextNode、CDATASection等都看作是一個個Node,在MSXML中實現接口的時候表現為這些對象都是從Node派生出來的,要理解Node和這一些接口的關系關鍵是要看清楚各接口之間的派生關系。為什麼要添加這一個Node接口呢?目的是為了使XML各要素之間聯結起來,不至於松散。

再加上另外兩個接口IXMLDOMNodeList和IXMLDOMNamedNodeMap。其中IXMLDOMNamedNodeMap主要使用在聯結同一個Element的各Attribute,因為同一個Element的Attribute必須保證兩兩不能沖突,而IXMLDOMNodeList則用於聯結其他的幾個要素ProcessingInstruction、Element、TextNode、CDATASection等,而這幾個要素比如Element,在同一個層是允許相同名稱重復出現的。上面的聯結並沒有包括Document這個Node,因為Document是整個XML的第一個Node,不可能也不允許出現在IXMLDOMNodeList和IXMLDOMNamedNodeMap下面。這段說法我也算是經過代碼證實過的吧!把MSXML的Document作為第一個Node,然後通過NamedNodeMap編歷該層的所有Attribute,再通過NodeList遞歸循環下一層的所有Node。可以看到這樣的一個樹狀結構(其中的attribute在該行括號列出,縮進表示所在層):

#document
XML (version;encoding)
XML-stylesheet (type; href)
body
code1 (id)
#text
code2 (id)
#cdata-section

從上面打印出來的信息可以看出TextNode,CDATASection是當作Element的下一層Node來處理的。get_text()只是為了方便使用TextNode的一個捷徑,對CDATASection通過get_text()訪問會出錯,則可考慮通過下一層Node的第一個Node來獲取。方法:

MSXML::IXMLDOMNodePtr child;
child = parent->childNodes->get_item(0);
if (child != NULL)
text = child->get_nodeValue();

在遞歸循環的時候,通常我們並不能預知這一個Node是什麼類型的。為了知道這一個Node是Element還是TextNode,或者其他類型,可以通過IXMLDOMNode::nodeType來獲取,這是一個枚舉類型,有如下取值(從這也可以看出,上面這個XML文本並沒有涵蓋XML所有要素):

NODE_ELEMENT (1)
NODE_ATTRIBUTE (2)
NODE_TEXT (3)
NODE_CDATA_SECTION (4)
NODE_ENTITY_REFERENCE (5)
NODE_ENTITY (6)
NODE_PROCESSING_INSTRUCTION (7)
NODE_COMMENT (8)
NODE_DOCUMENT (9)
NODE_DOCUMENT_TYPE (10)
NODE_DOCUMENT_FRAGMENT (11)
NODE_NOTATION (12)

好了,下面應該可以把“XML文件的處理思考”裡面出現的一些問題一個個羅列出來了吧:

問題一:最大的問題,通過路徑來找到比較深入的一個節點

在這篇文章中通過遞歸調用函數來實現這個功能,完全沒有必要,算是多此一舉了。DOM模型中自身帶的IXMLDOMNode::SelectSingleNode和IXMLDOMNode::SelectNodes(XPath)實現了比這個遞歸調用更完美的功能。簡單說一下SelectSingleNode的使用方法(msdom是IXMLDOMDocument實例)

MSXML::IXMLDOMNodePtr parent, child;
parent = msdom->documentElement;
//child為code1類型Element
child = parent->selectSingleNode(“/code1”);
//child為code1的id類型Attribute
child = parent->selectSingleNode(“/code1@id”);
//child名為code1且Attribute id=’text’的那個Element類型Element
child = parent->selectSingleNode(“/code1@[id=’text’]”);

…其它高深點的用法待後研究,為XPath相關。

問題二:C++ Builder6裡面的TXMLDocument並不單純是對MSXML的封裝

為了在C++ Builder 5下面封裝出一個類似的控件來,找了一些相關資料,發現MSXML、OpenXML等DOM模型的解析器都是同一套接口(希望我沒有弄錯),只是內部實現不同。TXMLDocument通過設置Ventor可以設置使用不同的解析器,但是在C++Builder裡面使用方法卻是完全相同的。默認好像是使用MSXML解析,比較優劣,MSXML需在客戶端注冊較新的msxml.dll類庫;SAX的需要附帶較大的dll;OpenXML因為是直接使用一個.pas文件編譯,直接生成到了可執行文件。

問題三:在文章中遍歷NodeList使用了IEnum接口

有點殺雞用牛刀之嫌,現在的遍歷可以這樣:

for (int i = 0; i < nodelist->get_length(); i++)
{
child = nodelist->get_item((long)i);
name = child->get_nodeName();
}

想想原來做的時候應該也用過這個方法,不過當時不知道Node和Element之間的關系,胡亂執行下面這樣的轉換所以轉換出的element == NUL,就以為此路不通。

IXMLDOMElementPtr element = (IXMLDOMNodePtr)node;

問題三:到後來補的一段appendChild的操作,將createElement出來的Element直接轉換成Node再appendChild。其實,這應該是最基礎的一個C++知識,關鍵是要看清MSXML實現的Com裡面也帶有了C++的這種技巧。

現在再來看看C++ Builder 5裡面怎麼解決沒有TXMLDocument控件,要使用MSXML類庫有什麼辦法。

最開始想到的是使用import語句的方法,即

#import "C:Windowssystem32MSXML.DLL" named_guids

可是,import進來能生成tlb和tlh文件,進行編譯卻無法通過,總提示缺少了些什麼,或有一些函數未能導出來(對了,可以在VC++裡面import,然後復制生成的tlb和tlh到C++Builder項目)。於是,直接使用C++ Builder裡面自帶的TVariant類進行COM實例化,調用函數,屬性(OleFunction,OlePropertyGet,OlePropertySet)等。例:

TVariant varMSDOM = CreateOleObject(“MSXML.DOMDocument”);
varMSDOM.OleFunction(L“load”, L”c:tmp.XML”);
TVariant varDoc = varMSDOM.OlePropertyGet(“documentElement”);

直覺是這種調用方法是會比import進來的調用速度要慢。差別好像是import直接通過虛函數表查找函數指針進行調用;OleFunction這些則通過IDispatch接口的invoke函數,間接調用,而且不能調用import進來name_guids的那些函數,如get_nodeName(BSTR *)。不管怎麼樣,通過TVariant還是基本能夠滿足要求,函數的調用。

然後,突然發現C++ Builder的Project上有個Import From Type Library的菜單,也嘗試一下。tlb和tlh文件都生成了,加入工程編譯一下,能夠通過,不過tlh裡面的定義,和調用方法卻和VC裡面的import進來有些不同:

1. VC裡面的實例化直接用智能指針如:

MSXML::IXMLDOMDocumentPtr msdom;
msdom.CreateInstance(__uuidof(MSXML::DOMDocument));

C++Builder裡面的實例化,則通過另外一個編譯器封裝的對象來實現

TCOMIXMLDOMDocument i_XMLdocument = CoDOMDocument::Create();
IXMLDOMDocumentPtr msdom = (IXMLDOMDocumentPtr) i_XMLdocument;

TCOMIXMLDOMDocument的定義在MSXML2_TLB.h裡面可以找到

typedef TComInterface TCOMIXMLDOMDocument;

2. C++Builder裡面也有IXMLDOMDocumentPtr msdom,可是這個指針卻不能直接用於判斷是否等於NULL,編譯器會提示錯誤,而應改為:

if ((IXMLDOMDocument *)msdom == NULL)

上面在C++Builder下面使用MSXML的經驗,延伸到其它類型的COM的自動化(automation),應該是不會有什麼問題的!不是嗎?

XML學習教程| jQuery入門知識| AJAX入門| Dreamweaver教程| Fireworks入門知識| SEO技巧| SEO優化集錦|
Copyright © DIV+CSS佈局教程網 All Rights Reserved