关注WebWork(四)
生活随笔
收集整理的這篇文章主要介紹了
关注WebWork(四)
小編覺得挺不錯的,現在分享給大家,幫大家做個參考.
??????? 時間過得很快,《WebWork In Action》第三章的翻譯工作也接近尾聲了。這一章的標題是Setting up WebWork,主要講述了與WebWork緊密相關的配置以及如何運用這些配置讓我們的應用程序組織得更為模塊化,讓我們在設計上可以更加靈活機動。
??????? 在這一章中,我了解到了很多之前并不熟悉的配置,而這些配置所帶來的影響,我不得不為之贊嘆。以action為例,通常我們會根據邏輯來劃分action,譬如Login、Register、Search和Logout等等,這些從邏輯語義上獨立的部分都應該分別作為一個action,這一點是大家都認可的。在以上這些action的周邊仍然會有一些其他附屬功能,譬如在Login之前需要做的準備工作——PreLogin;在Search之后需要作進一步搜索的SearchMore。在面對這樣的功能時候,你或許會將它們獨立出來,作為一個新的action,同時也有可能想著將這些功能放到主邏輯功能當中去。如果你選擇了后者,然后興沖沖地打開IDE想往里面加方法的時候,或許你會犯愁了:方法加了進去,該在哪里調用呢?因為在應用程序運行的時候,WebWork框架只會調用繼承的execute方法,那么自己加進去的方法呢?難道真的要在execute中調用?這不是又跟其他功能扯上關系了嘛?不要著急,且聽我慢慢說來。
??????? 其實,以上說了那么多,只是想為大家勾勒一個應用場景而已。撇開那些復雜的場景不談,需要解決的問題實際就是:如何讓框架調用execute以外的方法。了解WebWork的您應該都十分清楚:我們通常所寫的action都會extend了ActionSupport類并且需要提供一個override的execute方法,然后在收到請求之后,WebWork框架會將請求分派給不同的action,由action的execute方法來處理這個請求。這就是框架所帶來的好處:更加有序地組織代碼;同時這也是一個限制。框架都會在限制與功能之間尋找一個平衡點,一個好的框架則會將這對矛盾處理得很好:有一定程度的限制,又不失靈活和強大功能,而WebWork就是這樣一個框架。正當你為無法調用execute以外的方法而懊惱的時候,你會驚喜地發現WebWork提供了一種靈活的方式,讓你只需修改一下配置文件就可以調用action中execute以外的方法,這樣就不需要為一些主邏輯的周邊功能而創建新的action類了,讓你在設計的時候有更多的選擇。要實現框架調用action中execute以外的方法,只需要設置好action節點的method屬性即可。如以下例子所示: <action?name="Login"?class="com.fantasysoft.Login">
????<result?name="success">userProfile.jsp</result>
????<result?name="input">login.jsp</result>
</action>
<action?name="PreLogin"?class="com.fantasysoft.Login"?method="preLogin">
????<result?name="success">login.jsp</result>
????<result?name="error">error.jsp</result>
</action>
??????? 以上例子中名為PreLogin的action節點配置就會調用Login action中的preLogin方法,而不是常見的execute方法了。這里還有一個十分靈活的地方需要注意的,如果preLogin方法找不到的話,WebWork并不會馬上拋出Exception,而是進而查找doPreLogin方法(注意大小寫)。這樣做的原因是為了避免方法名和Java的關鍵字沖突,譬如你想使用default這樣的方法名,那么你在配置文件仍然可以寫上method="default",然后在Java代碼中,你就不能用default做方法名了,因為default是Java的關鍵字。但是這并不意味著就要把配置文件中method的value給改掉,你只要把方法名換上doDefault就行了。從這里可以看出WebWork考慮入微的一面,當然,我不贊成使用這種方式,畢竟這是以損失效率為代價的。
??????? 除了以上方式之外,WebWork還提供了另外一種更為簡單的方式調用action中非execute方法:使用actionName!method.action樣式的URL。而這種方式并不需要在xwork.xml中增加新的action節點,它將會使用actionName已經定義好的配置。還是以上的例子,如果我們使用Login!preLogin.action這樣的URL就會調用Login action中的preLogin方法,也將使用名為Login那個action節點中的配置,同時PreLogin這個節點就可以省略了。這樣的方式的好處就是使得xwork.xml配置文件更加簡短,不過,兩個方法共享一個action配置也給這種方式平添了許多限制,畢竟兩個方法返回的結果碼不一定都是success和input,即使返回的結果碼相同,那么結果碼所對應的location呢?完全相同的配置需求確實還是比較少見的。不管怎樣,多一個選擇總比沒有選擇要好。
????????以上只是講述了WebWork在配置靈活多變的一面,但管中窺豹,WebWork的靈活性已經可見一斑。說完管中窺豹這個成語,另外一個成語在我的腦海中浮現——庖丁解牛。呵呵,真的很期待“以無厚入有間,恢恢乎其于游刃必有余”那種境界。
??????? 在這一章中,我了解到了很多之前并不熟悉的配置,而這些配置所帶來的影響,我不得不為之贊嘆。以action為例,通常我們會根據邏輯來劃分action,譬如Login、Register、Search和Logout等等,這些從邏輯語義上獨立的部分都應該分別作為一個action,這一點是大家都認可的。在以上這些action的周邊仍然會有一些其他附屬功能,譬如在Login之前需要做的準備工作——PreLogin;在Search之后需要作進一步搜索的SearchMore。在面對這樣的功能時候,你或許會將它們獨立出來,作為一個新的action,同時也有可能想著將這些功能放到主邏輯功能當中去。如果你選擇了后者,然后興沖沖地打開IDE想往里面加方法的時候,或許你會犯愁了:方法加了進去,該在哪里調用呢?因為在應用程序運行的時候,WebWork框架只會調用繼承的execute方法,那么自己加進去的方法呢?難道真的要在execute中調用?這不是又跟其他功能扯上關系了嘛?不要著急,且聽我慢慢說來。
??????? 其實,以上說了那么多,只是想為大家勾勒一個應用場景而已。撇開那些復雜的場景不談,需要解決的問題實際就是:如何讓框架調用execute以外的方法。了解WebWork的您應該都十分清楚:我們通常所寫的action都會extend了ActionSupport類并且需要提供一個override的execute方法,然后在收到請求之后,WebWork框架會將請求分派給不同的action,由action的execute方法來處理這個請求。這就是框架所帶來的好處:更加有序地組織代碼;同時這也是一個限制。框架都會在限制與功能之間尋找一個平衡點,一個好的框架則會將這對矛盾處理得很好:有一定程度的限制,又不失靈活和強大功能,而WebWork就是這樣一個框架。正當你為無法調用execute以外的方法而懊惱的時候,你會驚喜地發現WebWork提供了一種靈活的方式,讓你只需修改一下配置文件就可以調用action中execute以外的方法,這樣就不需要為一些主邏輯的周邊功能而創建新的action類了,讓你在設計的時候有更多的選擇。要實現框架調用action中execute以外的方法,只需要設置好action節點的method屬性即可。如以下例子所示: <action?name="Login"?class="com.fantasysoft.Login">
????<result?name="success">userProfile.jsp</result>
????<result?name="input">login.jsp</result>
</action>
<action?name="PreLogin"?class="com.fantasysoft.Login"?method="preLogin">
????<result?name="success">login.jsp</result>
????<result?name="error">error.jsp</result>
</action>
??????? 以上例子中名為PreLogin的action節點配置就會調用Login action中的preLogin方法,而不是常見的execute方法了。這里還有一個十分靈活的地方需要注意的,如果preLogin方法找不到的話,WebWork并不會馬上拋出Exception,而是進而查找doPreLogin方法(注意大小寫)。這樣做的原因是為了避免方法名和Java的關鍵字沖突,譬如你想使用default這樣的方法名,那么你在配置文件仍然可以寫上method="default",然后在Java代碼中,你就不能用default做方法名了,因為default是Java的關鍵字。但是這并不意味著就要把配置文件中method的value給改掉,你只要把方法名換上doDefault就行了。從這里可以看出WebWork考慮入微的一面,當然,我不贊成使用這種方式,畢竟這是以損失效率為代價的。
??????? 除了以上方式之外,WebWork還提供了另外一種更為簡單的方式調用action中非execute方法:使用actionName!method.action樣式的URL。而這種方式并不需要在xwork.xml中增加新的action節點,它將會使用actionName已經定義好的配置。還是以上的例子,如果我們使用Login!preLogin.action這樣的URL就會調用Login action中的preLogin方法,也將使用名為Login那個action節點中的配置,同時PreLogin這個節點就可以省略了。這樣的方式的好處就是使得xwork.xml配置文件更加簡短,不過,兩個方法共享一個action配置也給這種方式平添了許多限制,畢竟兩個方法返回的結果碼不一定都是success和input,即使返回的結果碼相同,那么結果碼所對應的location呢?完全相同的配置需求確實還是比較少見的。不管怎樣,多一個選擇總比沒有選擇要好。
????????以上只是講述了WebWork在配置靈活多變的一面,但管中窺豹,WebWork的靈活性已經可見一斑。說完管中窺豹這個成語,另外一個成語在我的腦海中浮現——庖丁解牛。呵呵,真的很期待“以無厚入有間,恢恢乎其于游刃必有余”那種境界。
總結
以上是生活随笔為你收集整理的关注WebWork(四)的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 变态题大串烧:微软面试问题 -- 二.没
- 下一篇: 搜索引擎设计实用教程(3)-以百度为例