在延長審限的功能擴展中碰到了一些問題，特此記錄
1.對延審數據的狀態設置。
在新建延審申請的時候，當進入input界面時，就需要提前將狀態設置好，001 新建狀態。 原因是：input.jsp界面承擔的功能不僅是新建，還有查看功能。爲此，需要在進入
界面之前設置好當前的狀態，保證進入後能夠分辨清楚顯示的格式。並且，在送審之前保持001的新建狀態，能夠進行對該申請的修改。
其次，進入input界面時，申請人和申請時間都會默認生成，數據爲當前登錄用戶和當前時間。 在界面上使用${online.userName}來接收當前登錄用戶的信息，時間就需要自己
使用js的方式去拼接，並且對位數進行處理。但是，界面的顯示歸顯示，數據存儲的時候還是需要使用隱藏域的形式去傳遞參數。
再次，當保存之後跳轉到list界面中。此時List界面中的顯示爲修改和送審兩個按鈕。 點擊送審時，使用confirm提示，保證良好的用戶體驗。送審實質上是調用的ajax的方式，
其中最主要的操作還是對狀態的改變，當提交之後需要在後臺對狀態進行處理。 變爲002，爲在再審狀態。
2.在案件審批下的操作。
進入案件審批的第一步是整個案件審批的關鍵，當點擊連接時，跳轉入listTwo.jsp。此時，需要顯示的不僅有延審的信息，還有案件的基本信息。所以，此時需要在service接口中聲明相應的方法，並最終在dao層中，完成對方法的完善。 此時使用的是連接查詢，並規定排序的方式等等。
在action中調用此方法獲取分頁後的列表，此時能夠正常顯示列表嗎？答案是否定的，listTwo.jsp源自案件基本信息列表，所以其中的name （案件對象.屬性信息）都需要
修改，所以在上一部的操作中還需要對連接查詢的東西重新賦表明，使用 select * from (連接查詢) t 。 此時，在界面中將案件對象全部修改爲t，才能正常接收信息。當然，隱藏域form中的url信息也需要修改。
讓我驚訝的是，原來關於案件信息的查詢條件竟然不需要修改。 查看源代碼得知： 例：${param['filter_EQS_caseProcedure']}。 在其中filter是查詢時的過濾條件，EQS是框架中對信息的處理條件：EQS表示是String的方式 EQ表示equals。 所以，真正處理的字段其實是caseProcedure。 那麼在DAO層中的sql語句中已經查詢到了這個字段，並且重命名爲t。 與框架中對字段處理時，默認使用t一致。 所以，才造成了這裏不需要修改的結果。
此時的查詢條件還不夠，只有案件信息中原來的查詢字段。所以，我需要添加一些關於延審的查詢條件。
還有一處錯誤：在listTwo界面的c:foreach循環中使用了Combox:Combox的循環方式，我沒有注意這裏的name屬性和inputTwo界面中該字段的name是一致的，造成無法正常顯示，原因是：此時循環中存儲的是數據庫中所有滿足一定條件的該字段的信息，是一個list。 而name一致的情況下，Struts2默認會調用的是listTwo界面傳過去的，是一個list。
所以才無法正常顯示，解決方式：只需要改掉其中一個的name就可以了