在表單中填寫日期是個很常見的情況。

在Struts 1的ActionForm中，可以根據要提交的表單資料建立對應的ActionForm Bean屬性，屬性的型別支援Java的基本資料型別及其包裝類，還有字串，也就是說如果你將ActionForm Bean的屬性型別設為(int)，Struts會自動將無法正常轉換為int型別的資料都轉換為0（如果屬性型別為包裝類，則可能得到null），可以用於實現第一層次的表單資料過濾。

但是我們應該明白，表單資料本質上全部都是文字字元，Struts只不過是幫我們做了一步自動轉換。當然只是簡單的資料型別轉換，但如將一個字串"2007-12-5"轉換為java.util.Date型別，Struts則沒有提供直接的支援了，再說日期字串的解析本身就是一個情況複雜的事情，因為這個“日期字串”也沒有固定的模式（當然我們最常見的模式在Java中應該是"yyyy-MM-dd"了）。

於是我們若要在表單中處理日期型別的資料，必須自己設計一種解決方案。

方案1：在ActionForm Bean中，日期直接當作字串處理。
這樣做的話，在每次從ActionForm Bean中取資料時，都需要手動進行一次日期字串的解析，非常麻煩

方案2：在ActionForm Bean中，對應表單的屬性型別仍作字串處理，但提供一對輔助Getter/Setter方法，分別提供對此屬性的解析/格式化處理。
這樣做又能保持ActionForm Bean的相容性（所有的屬性資料型別都是Struts自動轉換所支援的），又能很方便地取得解析後的日期型別的資料。

方案3：直接提供java.util.Date型別的屬性及其Getter/Setter。但是這樣做在提交表單的時候會出錯，因為Struts無法將一個字串引數傳給一個需要java.util.Date型別引數的Setter。所以我們稍作改造，將Setter引數型別改為java.lang.String，並在其方法體中進行日期字串的解析。

下面比較一下3種方案的利弊：

方案1做法沒有什麼不妥，就是麻煩了點。當然如果你的專案不大，處理資料時直接採用SQL語句，或者是資料庫中本來就是使用VARCHAR等型別來儲存“日期”的，那麼這樣做也可以，無需進行型別解析轉換。

方案2則優點較多：屬性本身採用字串型別，能夠儲存表單提交的原始資料。需要日期型別時只需根據情況呼叫輔助用的Getter，呼叫輔助用Setter時，又可以自動格式化日期字串。同時仍然可以使用屬性原配的Getter/Setter來處理實際提交的字串。不足之處：對應每個日期屬性都需要多增加兩個方法（不過是一次編寫，可反覆呼叫：），然後日期的解析是否會帶來執行效率問題？（我感覺幾乎可以完全忽略……）

方案3只是效果能夠實現，缺點多多：表單提交的原始資料丟失，因為在呼叫Setter的時候便進行了解析，如果解析不成功，我們必須要捨棄非法格式的資料，並給日期型別的屬性對應的成員變數一個“預設值”，那麼這個“預設值”使用什麼好呢？null？1900-1-1？這裡可不能丟擲異常，否則Struts在提交表單的時候問題可大了。還有你見過Getter和Setter型別不一致的Bean屬性嗎？好像不符合規範，又讓人感覺怪怪的，很是罪過，我們要剔除掉奇怪的程式碼以免影響開發人員的心情！

最後，因為方案2儲存了原始資料，所以可以很方便地在validate方法中判斷原始輸入是否合法；而方案3則難以處理判斷了，因為它在Set的時候就已經把原始資料給過濾了。
有人說Struts配套的外掛Validator框架？那個我就不考慮了，它預設的日期模式是“yyyy/MM/dd”不合我意，然後其驗證過程仍然是呼叫Getter然後解析字串，並不能給我提供將字串轉換為日期的便利方式。

所以我推薦方案2！

ps:日期的解析和格式化請參考“java.text.SimpleDateFormat”