Java Struts2 （二）

2、封裝請求正文到對象中（很是重要）

1、靜態參數封裝

在struts.xml配置文件中，給動做類注入值。調用的是setter方法。

 

緣由：是由一個staticParams的攔截器完成注入的。

 

2、動態參數封裝：開發時用到的

經過用戶的表單封裝請求正文參數。

2.1、動做類做爲實體模型

實體模型：Entity，對應數據庫中表的記錄（注意類對應的是表結構，而對象對應的是一條記錄）

 

 

 

緣由：是由params攔截器完成的。

2.2、動做類和實體模型分開

 

問題：

因爲咱們沒有初始化user對象，默認爲null，一調用setUser方法，就空指針異常了。可是框架卻封裝進去值了。

緣由：

經過執行過程：

 

 

2.3、模型驅動：創建動做類和模型分開的前提下（開發中採用的方式）

  此處的學習目標：目前先記住怎麼寫，要想理解，必須等講完OGNL表達式以後。

 

緣由：是由一個modelDriven攔截器作的。

3、用戶註冊案例（重點）

1、數據建模（實體模型和數據庫）

 

2、創建業務層接口

 

3、創建持久層接口

 

4、數據源工具類

 

 

5、表現層使用Struts2框架實現

5.1、動做類：

 

5.2、配置文件

 

5.3、註冊界面和結果視圖

註冊界面：

 

結果視圖：

 

4、數據類型的轉換（明白原理，實際開發中幾乎不用）

1、開發中的狀況：

實際開發中用戶經過瀏覽器輸入的數據都是String或者String[]。

String/String[]————填充模型(set方法)————>POJO(plain old java object)  pojo中有java的數據類型。

POJO————————獲取(get方法)————>頁面展現：String

2、類型轉換狀況

寫數據：（增，刪，改）都是String或String[]數組轉換爲其餘類型。

讀數據：（查）其餘類型轉換爲String。

3、Struts2提供的經常使用類型轉換

a.基本數據類型自動轉換。

b.日期類型：默認按照本地日期格式轉換（yyyy-MM-dd）。

c.字符串數組：默認用逗號+空格，鏈接成一個字符串。

4、自定義類型轉換器（知道）

示例：把日期格式按照 MM/dd/yyyy的格式轉換

4.1、Struts2中的類型轉換器結構：

 

 

 

 

4.2、編寫類型轉換器（編寫一個類繼承StrutsTypeConverter，實現抽象方法）

 

 

4.3、註冊類型轉換器

局部類型轉換器：只能指定javabean中的屬性用

按照屬性來註冊。在屬性所屬的javabean的包下創建一個.properties文件。文件名稱：javabean名稱-conversion.properties

 

 

全局類型轉換器：（推薦）

按照要轉換的數據類型來註冊。

at the top op classpath，創建一個固定名稱xwork-conversion.properties的屬性文件。

 

 

5、轉換失敗後的處理（須要掌握）

當轉換失敗後，頁面提示：

 

解決辦法：配置回顯結果視圖

 

問題：

配置了回顯視圖後，當轉換失敗時，能夠回到請求頁面，可是表單數據都沒了？

 

 

 

顯示錯誤提示：藉助Struts2的標籤庫。

 

回顯數據：使用struts2的標籤庫生成表單。（建議使用）

 

 

 

錯誤信息中文提示：使用的是struts2的國際化。

 

 

問題：

類型轉換器當轉換失敗後，如何進入input視圖的？

緣由：

是由一個叫作conversionError的攔截器完成的。

注意：

要想使用類型轉換中的錯誤處理，在定義Action時必須繼承ActionSupport

5、數據驗證

用戶的輸入驗證，必須作，且工做量巨大。

1、驗證的方式

客戶端驗證：javascript

服務端驗證：邏輯驗證（咱們的代碼）

注意：若是客戶端和服務端二選一的話，服務器端的不能省。

實際開發中：客戶端+服務端

2、Struts2的服務端驗證

2.1、編程式驗證

前提：

動做類必須繼承ActionSupport

在代碼中編寫驗證規則。

a、針對動做類中的全部動做方法進行驗證：

在動做類中覆蓋public void validate()方法。

 

 

 

 

可是當咱們再寫一個動做方法時：

 

 

 

 

 

 

由此可知，該驗證方法會對動做類中的全部動做方法進行驗證。

b、針對動做類中的某個動做方法進行驗證

針對上面的問題，解決辦法1：給不須要驗證的動做方法添加一個@SkipValidation註解。

 

 

 

解決辦法2：validation方法遵照書寫規範。

 

 

 

解決辦法1和解決辦法2的使用時機：須要驗證的動做方法少，用解決辦法2。須要驗證的方法多，用解決方式1。（簡單一點：挑少的寫）

 全部編程式驗證的弊端：硬編碼。

2.2、聲明式驗證（推薦）

經過編寫驗證規則的xml文件。須要驗證時，編寫xml文件，不要驗證，就不寫。

優點：解決了2.1編程式驗證的弊端

a、針對動做類中的全部動做進行驗證：在動做類所在的包中，創建一個ActionClassName-validation.xml的文件，內容以下：

 

注意：它是針對動做類中的全部動做方法。

 

 

 

b、針對動做類中的某個動做進行驗證：在動做類所在的包中創建一個xml文件，名稱爲ActionClassName-ActionName-validation.xml。內容以下：

 

它是針對指定動做方法進行驗證：

 

 

 

 

2.3、Struts2內置的經常使用聲明式驗證器

2.3.1位置：

xwork-core-2.3.15.3.jar\com\opensymphony\xwork2\validator\validator\default.xml

 

2.3.2、驗證器注入參數

例如：咱們使用requiredstring，默認是去空格，當咱們不想去空格時，就能夠給驗證器注入參數。

基於字段的：

 

另外一種基於驗證器的：

 

 

3、經常使用驗證器示例

 

 

 

 

 

 

運行結果：