tory320

Design Principle
Identify the aspects of your application that vary and separate them from what stays the same.
Here's another way to think about this principle: take the parts that vary and encapsulate them, so that later you can alter or extends the parts that vary without affecting those that don't.
As simple as this concept is, it forms the basis for almost every design pattern. All patterns provide a way to let some part of a system vary independently of all other parts.

Each set of class will hold all the implementations of their respective behavior. For instance, we might have one clss that implements quarking, another implements squaking, and another that implements silence.

To separate thest behaviors from the Duck class, we'll pull both methods out of the duck class and create a new set of class to represent each behavior.

This is in contrast to the way we were doing things before, where a behavior either came from a concrete implementation in the suprerclass Duck, or by providing a specialized implementation in the sub class itself. In both cases we were relying on an implementation. We were locked into using that specific implemetation and there was no room for changing out the behavior.

And the same is true for the duck's flying behavior.

Okay, now that we've done the deep dive on the duck simulator design, it's time to come back up for air and take a look at the big picture.

Below is the entire reworked class structure. We have everything you'd expect: ducks extending Duck. fly behavior implementing FlyBehavior and quack behavior implementing QuackBehavior.

Notice also that we've started to describe things a little differntly. Instead of thinking of the duck behaviors as a set of behaviors, we'll start thinking of them ad a family of algorithms. Think about it: in the SimUDuck design, the algorithms represent things a duck would do , but we could just as easily use the same techniques for a set of classes that implement the ways to compute state sales tax by different states.

escape() & encodeURI() & encodeURIComponent()這三個函數都可以用來對URI進行encode或過濾特殊字符（#/$&+=?/等）。我的經驗是最好用encodeURIComponent()（需要IE 5.5以上，FireFox當然沒問題），因為對UTF-8支持比較好，不會遇到中文亂碼問題，否則還需要進行編碼轉換，很麻煩的。使用其它兩個函數都會發生丟失特殊字符的問題,例如空格變+號或者空格,引號,&=?等丟失的問題, 至少使用 JSP 作為服務器端的話會發生這種情況, 有興趣的朋友可以將本文最后的例子代碼中的編碼部分修改后做個測試.

下面是MSDN上對這三個函數的解釋：

escape(charString)

The escape method returns a string value (in Unicode format) that contains the contents of charstring. All spaces, punctuation, accented characters, and any other non-ASCII characters are replaced with %xx encoding, where xx is equivalent to the hexadecimal number representing the character. For example, a space is returned as "%20."

Characters with a value greater than 255 are stored using the %uxxxx format.

Note?? The escape method should not be used to encode Uniform Resource Identifiers (URI). Use encodeURI and encodeURIComponent methods instead.

http://msdn.microsoft.com/library/en-us/script56/html/js56jsmthescape.asp

?encodeURI(URIString)

The encodeURI method returns an encoded URI. If you pass the result to decodeURI, the original string is returned. The encodeURI method does not encode the following characters: ":", "/", ";", and "?". Use encodeURIComponent to encode these characters.

http://msdn.microsoft.com/library/en-us/script56/html/js56jsmthfencodeuri.asp

encodeURIComponent(encodedURIString)

The encodeURIComponent method returns an encoded URI. If you pass the result to decodeURIComponent, the original string is returned. Because the encodeURIComponent method encodes all characters, be careful if the string represents a path such as /folder1/folder2/default.html. The slash characters will be encoded and will not be valid if sent as a request to a web server. Use the encodeURI method if the string contains more than a single URI component.

http://msdn.microsoft.com/library/en-us/script56/html/js56jsmthencodeuricomponent.asp

AJAXFormer.zip4KB

將源碼解壓縮到JSP服務器的任意目錄下即可, 例如 $TOMCAT_HOME\webapps\ROOT 下, 然后在瀏覽器里鍵入:
http://localhost:8080/ajax_form_submit.htm

作者: beansoft@126.com?2006.12.25

?<form?action="Login.action"?method="post">
?? < table? cellspacing =0? width ="100%" >
???? < tr >
?????? < td > Login?ID:
???????? < input? type ="text" ?name ="loginId" ?width =100? /> &nbsp;&nbsp;
??????????Password:
???????? < input? type ="password" ?name ="loginPassword" ?width =100? /> &nbsp;&nbsp;
???????? < input? type ="submit" ?value ="Login" ? />
?????? </ td >
?????? < td? align =right>
????????? Hello,?<ww:property?value ="loginId" ? />
?????? </ td >
???? </ tr >
?? </ table >
</ form > < SPAN>

????????需要注意的地方就是form的action屬性的寫法了；
??????? 2、在xwork.xml中增加相應的處理action的節點

?<action?name="Login"?class="fantasysoft.webwork.Login">
??? < result? name ="error" ?type ="dispatcher" > index.jsp </ result >
??? < result? name ="success" ?type ="dispatcher" > index.jsp </ result >
</ action >

????????這里需要注意的是action節點中name的值要與index.jsp中定義的action的名字要嚴格匹配，對于大小 寫是敏感的。在action節點中還包含了節點，以說明處理action之后會可能出現的不同結果(name)和相應的處理方式(type)。譬如說，如果Login的這個action處理success了，則使用dispatcher將結果分(dispatch)到相應的頁面。而在WAF框架中并沒有這樣的定義，因為在默認情況下如果不成功則會返回當前頁面，不過可以定義FlowHandler，并擁有類似的功能且更加靈活；
??????? 3、實現類Login的代碼：

package?fantasysoft.webwork;

import?com.opensymphony.xwork.ActionSupport;

public ? class ?Login?extends?ActionSupport {
???? private ?String?loginId;
???? private ?String?loginPassword;

???? public ?String?getLoginPassword()? {
???????? return ?loginPassword;
????}
???? public ? void ?setLoginPassword(String?loginPassword)? {
???????? this .loginPassword? = ?loginPassword;
????}
???? public ?String?getLoginId()? {
???????? return ?loginId;
????}
???? public ? void ?setLoginId(String?loginId)? {
???????? this .loginId? = ?loginId;
????}
???? public ?String?execute()?throws?Exception {?????????????
???????? if ?(!checkUserId() )? return ?ERROR;? // checkUserId is the method that will be implemented
???????????? else ? return ?SUCCESS;
????}
}

????????在代碼中，你會發現有兩個繼承變量ERROR與SUCCESS。這兩個變量是定義在Action這個接口的，而ActionSupport則實現了Action接口。在接口Action的代碼中，我們可以看到ERROR = "error"、SUCCESS = "success"。我們可以發現這兩個變量的值與xwork.xml中result子節點中的name的值是相匹配。除此之外，在代碼中，我也找不到了原來在開發中經常要用到的一個API：getParameter。事實上，將表單中數據析取出來的工作是由webwork這個唯一定義的servlet去完成的，而這個類會調用Login類中set的方法將用戶輸入的數據賦給Login類的屬性：loginId和loginPassword。在這里，我們也要跟前面index.jsp中的包含的標簽聯系起來。當數據被dispatch回index.jsp的時候，在index.jsp頁面render的過程中是調用了get的方法去獲取相應的數據的。
??????? 最后，我們可以總結一下，整個Web應用程序的處理流程了：
??????? 首先，當用戶提交了表單(form)至Login.action后，由web.xml中定義的唯一的一個servlet：webwork去處理這個請求。webwork會以action的name：Login到xwork.xml中尋找相應的處理action的類，于是就找到了fantasysoft.webwork包中的Login類，由Login類中的execute方法來處理提交的form的數據了；
????????然后，根據execute方法的返回值，再到xwork.xml中對應的action節點中去找匹配的result子節點；
??????? 最后，根據result子節點的定義，將處理結果分發(dispatch)或者重定向(redirect)至下一個頁面^[3]。
????????
????????[1] 準備工作可以參考 WebWork?Getting Started ；
??????? [2]?web.xml文件的具體內容，可以參考 WebWork Tutorial Lesson 2 ? ；
??????? [3] 對于result的Type的更多介紹，可以參考 WebWork Tutorial Lesson 3 ?????

重載overloading和覆寫overriding哪個更早執行-- visitor幫助篇

重載overloading和覆寫overriding哪個更早執行--?? visitor幫助篇
一：問題提出
雖然我們經常寫程序用到重載和覆寫，但是很少會考慮他們的執行順序。下邊的內容就是關于，他們同時出現時
哪個先起作用：
二：問題分析
Java是"動態單分派靜態多分派語言"，這個定義已經多次提起，如果你不了解這些概念，看這里"visitor模式準備"
所以就注定了重載(靜態多分派)要早于覆寫(動態單分派)，因為靜態分派是編繹期實現的，動態分派是執行期實現的。
三：驗證
簡單驗證一下，順變提高記憶

?1 public ? class ?Parent? {
?2 ???? public ? void ?run(Object?o) {
?3 ????????System.out.println( " in?Parent?+param:object " );
?4 ????}
?5 ???? public ? void ?run( int ?i) {
?6 ????????System.out.println( " in?Parent?+?param:int " );
?7 ????}
?8 }
?9
10 public ? class ?Child? extends ?Parent? {
11
12 ???? public ? void ?run(Object?o) {
13 ????????System.out.println( " in?Child?+param:Object " );
14 ????}
15 ???? public ? void ?run(String?str) {
16 ????????System.out.println( " in?Child?+?param:String " );
17 ????}
18 ???? public ? static ? void ?main(String[]?args)? {
19 ????????Parent?p? = ? new ?Child();
20 ????????String?str? = ? new ?String();
21 ????????p.run(str);
22 ????}
23 }

運行結果是什么？
in Child +param:Object
inChild是確認的，但是為什么是object，而不是String，我們放入的就是String啊。
首先來分析執行過程。
定義韋類型Parent p在執行run(Str)的時候，

1，如果是先執行重載，然後是執行覆寫的過程
重載時因為找不到對應的String參數的函數，所以定位到接受父類的run(Object o)函數，
覆寫時因為傳入時父類告訴子類的對象類型是Object，所以執行run(Object o);
正是我們看到的結果，所以在Java中執行的順序是這樣的。

2，為了對比，說一下先覆寫后重載的過程
如果是先覆寫，再重載
覆寫時因為確定對象實際是子類，所以直接覆寫到Child，然後重載，發現有對應的String為參數的函數
執行，run(String str);
應該輸出的結果:in Child +param:String
但我們看到結果顯然是1，所以驗證了Java是先重載后覆寫的。

最后的部分：

看完本文，如果你對visitor模式有更多的興趣，想了解更多請看如下幾篇文章。
1,靜態分派，動態分派，多分派，單分派 --------------?? visitor模式準備
2,訪問差異類型的集合類 ------------------------?? visitor模式入門
3,visitor模式理論及學術概念-------------－-----?? visitor模式深入
4,visitor模式和其它模式的比較和關系-------------?? visitor模式總結?
5，重載overloading和覆寫overriding哪個更早執行--?? visitor幫助篇 （本文）
雖然排列順序是1,2,3,4,5 但是我個人建議的學習方式是2,1,3,4,5因為這個順序更方便一般人理解

JAXP 專述 Sun 的 Java API for XML 語法分析

? ? 未顯示需要 JavaScript 的文檔選項 ?

級別: 初級

Brett McLaughlin , Enhydra 策略顧問, Lutris Technologies

2000 年 11 月 01 日

這是篇細探 JAXP，Sun 的 Java API for XML 的文章，幫助解除了有關 JAXP 本質和服務目的的疑惑。本文講解了 JAXP 的基本概念，演示 XML 語法分析為什么需要 JAXP，并顯示如何輕易更改 JAXP 使用的語法分析器。本文還進一步講述了 SAX 和 DOM 這兩個流行的與 JAXP 相關的 Java 和 XML API。

Java 和 XML 在每一個技術領域都制造了新聞，并且對于軟件開發人員來說，似乎是 1999 年和 2000 年最重要的發展。結果，Java 和 XML API 的數量激增。其中兩個最流行的 DOM 和 SAX 還引起極大興趣，而 JDOM 和數據綁定 API 也接踵而來。只透徹理解這些技術中的一個或兩個就是一項艱巨任務，而正確使用所有這些技術就會使您成為專家。但在去年，另一個 API 給人留下了深刻印象，它就是 Sun 的 Java API for XML，通常稱為 JAXP。如果考慮到 Sun 在其平臺上還沒有任何特定于 XML 的產品，那么這個進展就不足為奇。而令人驚奇的是人們對 JAXP 了解的缺乏。多數使用它的開發人員在他們所用的這個 API 的概念理解上都有錯誤。

什么是 JAXP？

本文假設您有 SAX 和 DOM 的基本知識。這里實在沒有足夠篇幅來解釋 SAX、DOM 和 JAXP。如果您是 XML 語法分析的新手，那么可能要通過聯機資源閱讀 SAX 和 DOM，或者瀏覽我的書。（ 參考資源 一節中有至 API 和我的書的鏈接。）獲得基本知識后再看本文會比較好。

回頁首

API 還是抽象？

在講解代碼之前，介紹一些基本概念很重要。嚴格地說，JAXP 是 API，但是將其稱為抽象層更準確。它不提供處理 XML 的新方式，不補充 SAX 或 DOM，也不向 Java 和 XML 處理提供新功能。（如果在這點上理解有誤，則本文正好適合您！）它只是使通過 DOM 和 SAX 處理一些困難任務更容易。如果在使用 DOM 和 SAX API 時遇到特定于供應商的任務，它還使通過獨立于供應商的方式處理這些任務成為可能。

雖然要分別講述所有這些特性，但是真正需要掌握的是：JAXP 不提供語法分析功能 ！沒有 SAX、DOM 或另一個 XML 語法分析 API，就 無法分析 XML 語法 。有很多人曾讓我將 DOM、SAX 或 JDOM 與 JAXP 進行對比。但進行這些對比是不可能的，因為前三個 API 與 JAXP 的目的完全不同。SAX、DOM 和 JDOM 都分析 XML 語法。而 JAXP 卻提供到達這些語法分析器和結果的方式。它自身不提供分析文檔語法的新方法。如果要正確使用 JAXP，則一定要弄清這點。這將使您比其它 XML 開發人員領先一大截。

如果仍然懷疑（或認為我故弄玄虛），請從 Sun 的 Web 站點下載 JAXP 分發（請參閱 參考資料 一節），然后就會知道基本 JAXP 是什么。在包括的 jar ( jaxp.jar ) 中 只有六個類 ！這個 API 會有多難哪？所有這些類（ javax.xml.parsers 包的一部分）都位于現有語法分析器之上。這些類中的兩個還用于錯誤處理。JAXP 比人們想象的要簡單得多。那么，為什么還感到困惑哪？

回頁首

Sun 的 JAXP 和 Sun 的語法分析器

JAXP 下載時包括 Sun 的語法分析器。所有 parser 器類作為 com.sun.xml.parser 包和相關子包的一部分位于 parser.jar 檔案中。應該知道，該語法分析器（代碼名為 Crimson） 不 是 JAXP 自身的一部分。它是 JAXP 版本的一部分，但不是 JAXP API 的一部分。令人困惑嗎？有一點。換這種方式想想：JDOM 與 Apache Xerces 語法分析器一起提供。該語法分析器不是 JDOM 的一部分，但由 JDOM 使用，所以包括它，以確保 JDOM 可以單獨使用。JAXP 也是如此，但不象 JDOM 那樣好表達：JAXP 與 Sun 的語法分析器一起提供，以便可以立即使用。但是，很多人將 Sun 的語法分析器中包括的類當成 JAXP API 的一部分。例如，新聞組中一個常見的問題是：“怎樣使用 JAXP 中的 XMLDocument 類？其目的是什么？”這個答案可有些復雜。

首先， com.sun.xml.tree.XMLDocument 類不是 JAXP 的一部分。它是 Sun 語法分析器的一部分。所以，這個問題從一開始就給人以誤導。其次，JAXP 的整個意義在于在處理語法分析器時提供供應商獨立性。使用 JAXP 的同一代碼可以與 Sun 的 XML 語法分析器、Apache 的 Xerces XML 語法分析器和 Oracle 的 XML 語法分析器一起使用。而使用特定于 Sun 的類是個壞主意。這與 JAXP 的整個意義相背離。現在看出來這個問題怎樣混淆概念了嗎？語法分析器和 JAXP 發行版本（至少是 Sun 的版本）中的 API 被混為一談，開發人員將其中一個的類和特性當成是另一個的了，反之亦然。

回頁首

舊和新

關于 JAXP，最后需要指出的是：使用 JAXP 有一些缺陷。例如，JAXP 只支持 SAX 1.0 和 DOM 第一層規范。SAX 2.0 從 2000 年 5 月起就完成，DOM 第二層規范支持甚至在大多數語法分析器中存在更長時間。DOM 第二層規范還沒有完成，但確實足夠穩定以用于生產。這兩個 API 的新版本都有重大改進，最明顯的是對 XML 名稱空間的支持。該支持還允許“XML Schema 確認”，這個與 XML 相關的另一熱門技術。公平地說，當 JAXP 發布 1.0 最終發行版時，SAX 2.0 和 DOM 第一層規范都還沒有完成。但是，由于沒有包括這些新版本，確實為開發人員帶來很大不便。

還可以使用 JAXP，但是也可以等待 JAXP 1.1，它支持 SAX 2.0 和 DOM第二層規范 。否則，將發現，JAXP 提供的優點以 SAX 和 DOM 最新版本中的功能為代價，并使應用程序更加難以編碼。無論是否等待下一個 JAXP 發行版，都要留意這個問題。如果將 JAXP 與語法分析器一起使用，而語法分析器支持的 DOM 和 SAX 版本比 JAXP 支持的要高，則可能會有類路徑問題。所以，事先留意一下，并且，一旦有 JAXP 1.1，馬上升級。基本理解 JAXP 之后，讓我們看一下 JAXP 依賴的 API：SAX 和 DOM。

回頁首

從 SAX 開始

SAX （Simple API for XML）是用于處理 XML 的事件驅動方法。它基本由許多回調函數組成。例如，每當 SAX 語法分析器遇到元素的開始標記時就調用 startElement() 。對于字符串，將調用 characters() 回調函數，然后在元素結束標記處調用 endElement() 。還有很多回調函數用于文檔處理、錯誤和其它詞匯結構。現在知道這是怎么回事了。SAX 程序員實現一個定義這些回調函數的 SAX 接口。SAX 還實現一個名為 HandlerBase 的類，該類實現所有這些回調函數，并提供所有這些回調方法的缺省空實現。（提到這一點是因為它在后面講到的 DOM 中很重要。）SAX 開發人員只需擴展這個類，然后實現需要插入特定邏輯的方法。所以，SAX 的關鍵在于為這些不同的回調函數提供代碼，然后允許語法分析器在適當的時候觸發這些回調函數中的每一個。

因此，典型的 SAX 過程如下：

• 用特定供應商的語法分析器實現創建一個 SAXParser 實例
• 注冊回調實現（例如，通過使用擴展 HandlerBase 的類）
• 開始進行語法分析，然后在觸發回調實現時等待

JAXP 的 SAX 組件提供執行所有這些步驟的簡單方式。如果沒有 JAXP，SAX 語法分析器要直接從供應商類（如 org.apache.xerces.parsers.SAXParser ）進行實例化，或者必須使用名為 ParserFactory 的幫助類。第一個方法的問題很明顯：不獨立于供應商。第二個方法的問題在于類廠需要一個自變量，即要使用的語法分析器類的字符串名稱（還是那個 Apache 類 org.apache.xerces.parsers.SAXParser ）。可以通過將不同語法分析器作為 String 傳遞來更改語法分析器。使用這種方法不必更改任何 import 語句，但是還是要重新編譯類。這顯然不是最佳解決方案。如果能夠不重新編譯類而更改語法分析器，可能會簡單得多，是不是這樣呢？

JAXP 提供了更好的替代方法：它允許將語法分析器作為 Java 系統屬性來提供。當然，當從 Sun 下載版本時，將得到使用 Sun 語法分析器的 JAXP 實現。可以從 Apache XML Web 站點下載在 Apache Xerces 上構建其實現的相同 JAXP 接口。因此（無論哪一種情況），更改正在使用的語法分析器需要更改類路徑設置，即從一種語法分析器實現更改到另一個，但是 不要求重新編譯代碼。這就是 JAXP 的魔力，或抽象性。

SAX 語法分析器一瞥

JAXP SAXParserFactory 類是能夠輕易更改語法分析器實現的關鍵所在。必須創建這個類的新實例（等一會將講到）。創建新實例之后，類廠提供一個方法來獲得支持 SAX 的語法分析器。在內部，JAXP 實現處理依賴于供應商的代碼，使您的代碼不受影響。這個類廠還提供其它一些優秀特性。

除創建 SAX 語法分析器實例的基本工作之外，類廠還允許設置配置選項。這些選項影響所有通過類廠獲得的語法分析器實例。JAXP 1.0 中兩個可用的功能是設置名稱空間敏感性 ( setNamespaceAware (boolean awareness))，和打開確認 ( setValidating (boolean validating))。請記住，一旦設置了這些選項，在調用該方法之后，它們將影響 所有從 類廠獲得的實例。

設置了類廠之后，調用 newSAXParser() 將返回一個隨時可用的 JAXP SAXParser 類實例。這個類封裝了一個下層的 SAX 語法分析器（SAX 類 org.xml.sax.Parser 的實例）。它還防止向語法分析器類添加任何特定于供應商的附加功能。（還記得以前對 XmlDocument 的討論嗎？）這個類可以開始進行實際的語法分析。以下清單顯示如何創建、配置和使用 SAX 類廠。

												
														import java.io.File;
import java.io.IOException;
import java.io.OutputStreamWriter;
import java.io.Writer;

// JAXP
import javax.xml.parsers.FactoryConfigurationError;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.SAXParserFactory;
import javax.xml.parsers.SAXParser;

// SAX
import org.xml.sax.AttributeList;
import org.xml.sax.HandlerBase;
import org.xml.sax.SAXException;

public class TestSAXParsing {

 public static void main(String[] args) {
 try {
 if (args.length != 1) {
 System.err.println ("Usage: java TestSAXParsing [filename]");
 System.exit (1);
 }

 // 獲得SAX 語法分析器類廠
 SAXParserFactory factory = SAXParserFactory.newInstance();

 //設置設置名稱空間敏感性選項，關掉確認選項
 factory.setValidating(true);
 factory.setNamespaceAware(false);

 SAXParser parser = factory.newSAXParser();
 parser.parse(new File(args[0]), new MyHandler());

 } catch (ParserConfigurationException e) {
 System.out.println("The underlying parser does not support " +
 " the requested features.");
 } catch (FactoryConfigurationError e) {
 System.out.println("Error occurred obtaining SAX Parser Factory.");
 } catch (Exception e) {
 e.printStackTrace();
 }
 }
}

class MyHandler extends HandlerBase {
 //通過 DocumentHandler, ErrorHandler等實現的SAX回調函數
}

												
										

請注意，在這段代碼中，在使用類廠時可能發生兩個特定于 JAXP 的問題：無法獲得或配置 SAX 類廠，以及無法配置 SAX 語法分析器。當無法獲得 JAXP 實現中指定的語法分析器或系統屬性時，通常會發生第一個問題 FactoryConfigurationError 。當正在使用的語法分析器中的特性不可用時，會發生第二個問題 ParserConfigurationException 。這兩個問題都容易處理，應該不會對 JAXP 的使用造成任何困難。

在獲得類廠、關閉名稱空間并打開“確認”之后，將獲得 SAXParser ，然后開始語法分析。請注意， SAX 語法分析器的 parse() 方法取得前面提到的 SAX HandlerBase 類的一個實例。（可以通過完整的 Java 清單 查看該類的實現 。）還要傳遞要進行語法分析的文件。但是， SAXParser 所包含的遠不止這一個方法。

使用 SAX 語法分析器

獲得 SAXParser 類的實例之后，除了向語法分析器傳遞 File 進行語法分析之外，還可以用它做更多的事。由于如今大型應用中的應用程序組件之間通信方式，“對象實例創建者就是其使用者”這樣的假定并不總是安全的。換句話說，一個組件可能創建 SAXParser 實例，而另一組件（可能由另一開發人員編碼）可能需要使用那個實例。由于這個原因，提供了一些方法來確定語法分析器的設置。執行此任務的兩個方法是 isValidating() ，它通知調用程序：語法分析器將要、或不要執行“確認”，以及 isNamespaceAware() ，它返回一個指示，說明語法分析器可以或不可以處理 XML 文檔中的名稱空間。雖然這些方法能提供有關語法分析器可以執行功能的信息，但是無法更改這些特性。必須在語法分析器類廠級別執行該操作。

另外，有多種方法來請求對文檔進行語法分析。除了只接受 File 和 SAX HandlerBase 實例，SAXParser 的 parse() 方法還能以 String 形式接受 SAX InputSource 、Java InputStream 或 URL，所有這些都要與 HandlerBase 實例一起提供。所以，不同類型的輸入文檔可以用不同方式的語法分析來處理。

最后，可以直接通過 SAXParser 的 getParser() 方法獲得和使用下層的 SAX 語法分析器（ org.xml.sax.Parser 的實例）。獲得這個下層實例之后，就可以獲得通常的 SAX 方法。下一個清單顯示 SAXParser 類（這個 JAXP 中 SAX 語法分析的核心類）的各種使用示例。

												
														 //獲得SAXP的一個實例
 SAXParser saxParser = saxFactory.newSAXParser();

 //查看是否支持 Validate 選項
 boolean isValidating = saxParser.isValidating();

 //查看是否支持 namespace 選項
 boolean isNamespaceAware = saxParser.isNamespaceAware();

 // 運用一個File 和一個SAX HandlerBase 的實例進行多種形式的語法分析
 saxParser.parse(new File(args[0]), myHandlerBaseInstance);

 // 運用一個 SAX InputSource實例 和一個 SAX HandlerBase 實例
 saxParser.parse(mySaxInputSource, myHandlerBaseInstance);

 //運用一個 InputStream 實例和一個SAX HandlerBase 實例
 saxParser.parse(myInputStream, myHandlerBaseInstance);

 // 運用一個 URI 和一個SAX HandlerBase 實例
 saxParser.parse("http://www.newInstance.com/xml/doc.xml", myHandlerBaseInstance);

 //獲得底層的（封裝）SAX 語法分析器 
 org.xml.sax.Parser parser = saxParser.getParser();

 //利用底層的語法分析器
 parser.setContentHandler(myContentHandlerInstance);
 parser.setErrorHandler(myErrorHandlerInstance);
 parser.parse(new org.xml.sax.InputSource(args[0]));

												
										

目前為止，關于 SAX 已經講了很多，但是還沒有揭示任何不尋常或令人驚奇的東西。事實上，JAXP 的功能很少，特別是當 SAX 也牽涉進來時。這很好，因為有最少的功能性意味著代碼可移植性更強，并可以由其他開發人員與任何與 SAX 兼容的 XML 語法分析器一起使用，無論是免費（通過開放源碼，希望如此）還是通過商業途徑。就是這樣。在 JAXP 中使用 SAX 沒有更多的東西。如果已經知道 SAX，那么現在已經掌握大約 98% 的內容。只需學習兩個新類和兩個 Java 異常，您就可以開始了。如果從沒使用過 SAX，那也很簡單，現在就可以開始。

回頁首

處理 DOM

如果要休息以迎接 DOM 挑戰，那么先別休息。在 JAXP 中使用 DOM 的過程與 SAX 幾乎相同，所要做的全部只是更改兩個類名和一個返回類型，這樣就差不多了。如果理解 SAX 的工作原理和 DOM 是什么，則不會有任何問題。

DOM 和 SAX 的主要差異是它們的 API 結構。SAX 包含一個基于事件的回調函數集，而 DOM 有一個內存中的樹狀結構。換句話說，在 SAX 中，從不需要操作數據結構（除非開發人員手工創建）。因此，SAX 不提供修改 XML 文檔的功能。而 DOM 正好提供這種類型的功能。 org.w3c.dom.Document 類表示 XML 文檔，它由表示元素、屬性和其它 XML 結構的 DOM 節點 組成。所以，JAXP 無需觸發 SAX 回調，它只負責從語法分析返回一個 DOM Document 對象。

DOM 語法分析器類廠一瞥

基本理解 DOM 以及 DOM 和 SAX 的差異之后，就沒什么好說的了。以下代碼看起來與 SAX 代碼類似。首先，獲得 DocumentBuilderFactory （與 SAX 中的方式相同)。然后，配置類廠來處理確認和名稱空間（與 SAX 中的方式相同)。下一步，從類廠中檢索 DocumentBuilder （它與 SAXParser 類似）（與 SAX 中的方式相同. . . 啊，您都知道了）。然后，就可以進行語法分析了，產生的 DOM Document 對象傳遞給打印 DOM 樹的方法。

												
														import java.io.File;
import java.io.IOException;
import java.io.OutputStreamWriter;
import java.io.Writer;

// JAXP
import javax.xml.parsers.FactoryConfigurationError;
import javax.xml.parsers.ParserConfigurationException;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.parsers.DocumentBuilder;

// DOM
import org.w3c.dom.Document;
import org.w3c.dom.DocumentType;
import org.w3c.dom.NamedNodeMap;
import org.w3c.dom.Node;
import org.w3c.dom.NodeList;

public class TestDOMParsing {

 public static void main(String[] args) {
 try {
 if (args.length != 1) {
 System.err.println ("Usage: java TestDOMParsing [filename]");
 System.exit (1);
 }

 // 獲得 Document Builder Factory
 DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();

 //打開確認選項，關掉名稱空間敏感性選項。
 factory.setValidating(true);
 factory.setNamespaceAware(false);

 DocumentBuilder builder = factory.newDocumentBuilder();
 Document doc = builder.parse(new File(args[0]));

 // 從DOM 數中打印文檔，并加一初始空格
 printNode(doc, "");

 // 在這里也可以對 DOM 文檔進行修改
 } catch (ParserConfigurationException e) {
 System.out.println("The underlying parser does not support the requested features.");
 } catch (FactoryConfigurationError e) {
 System.out.println("Error occurred obtaining Document Builder Factory.");
 } catch (Exception e) {
 e.printStackTrace();
 }
 }

 private static void printNode(Node node, String indent) {
 // 打印 DOM 樹
}

												
										

此代碼中可能會出現兩個不同的問題（與 JAXP 中的 SAX 類似）： FactoryConfigurationError 和 ParserConfigurationException 。每一個的原因與 SAX 中的相同。不是實現類 ( FactoryConfigurationError ) 中有問題，就是語法分析器不支持請求的特性 ( ParserConfigurationException )。DOM 和 SAX 的唯一差異是：在 DOM 中，用 DocumentBuilderFactory 替代 SAXParserFactory ，用 DocumentBuilder 替代 SAXParser 。就這么簡單！（可以 查看完整代碼清單 ，該清單包括用于打印 DOM 樹的方法。）

使用 DOM 語法分析器

有了 DOM 類廠之后，就可以獲得 DocumentBuilder 實例。 DocumentBuilder 實例可以使用的方法與 SAX 的非常類似。主要差異是 parse() 的變種不需要 HandlerBase 類的實例。它們返回表示語法分析之后的 XML 文檔的 DOM Document 實例。另一唯一不同之處是：為類似于 SAX 的功能提供了兩個方法：用 SAX ErrorHandler 實現來處理語法分析時可能出現的問題的 setErrorHandler() ，和用 SAX EntityResolver 實現來處理實體解析的 setEntityResolver() 。如果不熟悉這些概念，則需要通過聯機或在我的書中學習 SAX。以下清單顯示使用這些方法的示例。

												
														    //獲得一個 DocumentBuilder 實例
 DocumentBuilder builder = builderFactory.newDocumentBuilder();

 //查看是否支持 Validate 選項
 boolean isValidating = builder.isValidating();

  //查看是否支持 namespace 選項
 boolean isNamespaceAware = builder.isNamespaceAware();

 // 設置一個 SAX ErrorHandler
 builder.setErrorHandler(myErrorHandlerImpl);

 // 設置一個 SAX EntityResolver
 builder.setEntityResolver(myEntityResolverImpl);

 // 運用多種方法對 file 進行語法分析
 Document doc = builder.parse(new File(args[0]));

 // 運用 SAX InputSource 
 Document doc = builder.parse(mySaxInputSource);

 // 運用 InputStream
 Document doc = builder.parse(myInputStream, myHandlerBaseInstance);

 // 運用 URI
 Document doc = builder.parse("http://www.newInstance.com/xml/doc.xml");

												
										

是不是感到 DOM 這一節有些令人厭煩？有這種想法的不止您一個，寫 DOM 代碼有些令人厭煩是因為它是直接取得所學的 SAX 知識，然后將其用于 DOM。因此，和朋友、同事打賭吧，說使用 JAXP 只是小菜一碟。

回頁首

更改語法分析器

最后要探討的主題是 JAXP 輕易更改類廠類使用的語法分析器的能力。更改 JAXP 使用的語法分析器實際意味著更改 類廠，因為所有 SAXParser 和 DocumentBuilder 實例都來自這些類廠。既然確定裝入哪個語法分析器的是類廠，因此，必須更改類廠。可以通過設置 Java 系統屬性 javax.xml.parsers.SAXParserFactory 來更改要使用的 SAXParserFactory 接口實現。如果沒有定義該屬性，則返回缺省實現（供應商指定的任何語法分析器)。相同原理適用于 DocumentBuilderFactory 實現。在這種情況下，將查詢 javax.xml.parsers.DocumentBuilderFactory 系統屬性。就這么簡單，我們已經學完了！這就是 SAXP 的全部：提供到 SAX 的掛鉤，提供到 DOM 的掛鉤，并允許輕易更改語法分析器。

回頁首

結束語

如您所見，沒多少復雜的東西。更改系統屬性，通過類廠、而不是語法分析器或構建器來設置“確認”，以及弄清楚JAXP實際上不是人們通常所認為的那樣，這些是使用 JAXP 的最困難部分。除了沒有 SAX 2.0 和 DOM第二層規范支持之外，JAXP 在兩個流行的 Java 和 XML API 之上提供一個有幫助的可插入層。它使代碼獨立于供應商，并允許不編譯語法分析代碼而更改語法分析器。那么，從 Sun、Apache XML 或其它方便之處下載 JAXP，并使用它吧！繼續關注 JAXP 1.1，并增加對 SAX 2 和 DOM 2、XSLT 及更多內容的支持。您將在這里獲得第一手新聞，所以，請關注 developerWorks。