只要你願意，嚴厲規矩的Java也同樣可以變得“動態”靈活起來。動有動的好處，靜有靜的好處。俗話說得好，“沒有規矩不成方圓”，但“生命誠可貴，愛情價更高，若為自由故，兩者皆可拋”。那麼作為忙碌在程序藝術世界裡的子民們，我們何去何從呢？投奔動態語言陣營還是繼續在四平八穩的Java領域奮戰？ 在我看來，“動”或“不動”需要一個黃金分割點。
1、尋找“動”與“不動”的黃金分割點
兩年前，以Martin Fowler為代表的一群大師們忽然集體投奔到了動態語言陣營，手持RoR這個“核武器”，大喊著要滅了Java，要取代Java。現在回頭來看，動態語言給我們確實帶來了一些的革命性的思想，但同時我們也發現被大師們忽悠了一把。
對於強類型的Java語言來說，與真正的動態語言比起來，確實要受限制很多。在我看來，借某位大師的比喻，Ruby的靈敏相當草書，而java就是正楷。用Ruby，十個程序員寫出來的程序就是十種風格，這跟我們寫文章是一樣的。而Java就是規規矩矩宋體方塊字，橫是橫，豎是豎，先寫哪一筆後寫哪一劃，一切都是規定好了的。強類型的靜態語言從語法的底層就建立了一套較為穩固的規則體系，因此更加規范，從長遠來說，或者是對於大型項目來說，肯定是有規范並且規范嚴格的，較之規范不嚴格的表現起來從擴展性、可維護性等要優秀得多。
動態語言與強類型的靜態語言，他們各有自己的特長范圍。在企業級應用領域，JavaEE的優勢不是一天兩天建立起來的。而動態語言其實由來已久，最優秀我覺得應該算是javascript了，想想以前用ASP寫程序，服務器及客戶端腳本都用的js，對於小型的應用來說，確實很舒適。而近兩年由於Ajax概念股的走紅，javascript更加春風自得，prototype.js等一批的Ajax框架及引擎更是把javascript的OO及動態特性發揮到極致。對於來勢凶猛的RoR來說，在我看來最好先去跟PHP、Python這種同類的競爭者好好PK幾年，假如不被他們滅掉的話，然後再來研究要“花多少光年來滅掉java”這樣的命題。
對於小型的應用來說，小巧、靈活、簡單的動態語言，肯定在先機上占有一定優勢。但對於大型的企業級應用來說，動態語言的這種巧、活、隨意性恰好成為其劣勢。這其中的原因除了本身能力（多核、線程、系統資源等）有限以外，太“草”了也是限制其發展的原因。事實證實，動態語言能做到的，咱們靜態語言稍為動動腦子調整一下也能做到，比如Groovy；而靜態語言能做到的，動態語言打死也做不到，除非他自己變成靜態的強類型語言，比如多核線程、二階段分布式事務。假如做到了，他可能就不僅僅是動態語言了。
動有動的好處，靜有靜的好處。俗話說得好，“沒有規矩不成方圓”，但“生命誠可貴，愛情價更高，若為自由幫，兩者皆可拋”。那麼作為忙碌在程序藝術世界裡的子民們，我們何去何從呢？投奔動態語言陣營還是繼續在四平八穩的Java領域奮戰？
在我看來，“動”或“不動”需要一個黃金分割點。而在EasyJWeb之所以提供一些“動態”特性的支持，也就是尋找這樣一個分割點而做的，把動與靜的好處進行分析、權衡，然後讓JavaEE應用開發變得更加的輕易。努力尋找這樣的黃金分割點，對一些非常好的動態特性及思想提供給用級的支持，而對於一些必須規范才能產生效率的特性，則堅持推廣應用。Java社區中的很多人都在為尋找這個分割點而努力。Java本身也已經意識到這一點，在其新的版本中都增加了對一些優秀的動態語言特性的支持。
當然，對一直覺得“受約束、受限制”的我們來說，能“動”一點、想“草”的時候“草”兩下，這是一件非常快樂的事兒。因此，EasyJWeb在基於Java這樣一個具有規范的平台及環境作為基礎的前提下，做了一些工作，使得我我們在一定的范圍內也可以靈活的“動”起來，隨性地“草”起來，這樣使得我們可以放開手腳、輕松大膽的往前走。下面我通過一些例子來說明。
2、百變CmdAction－AbstractCmdAction
在EasyJWeb-.10新版本的Command類型的Action基類即AbstractCmdAction中，提供了足夠的靈活特性使你得可以像使密宗拳一樣書寫Java Web Action。可以根據你不同的應用場景，像用動態語言那樣書寫Action中的command。
假如我們在一個模塊中要執行一個名為create操作，下面的方法簽名都是合法的：
public Page doCreate(WebForm form,Module module)
public Page doCreate(WebForm form)
public Page doCreate(Module module)
public Page doCreate();
public void doCreate(WebForm form,Module module)
public void doCreate(WebForm form)
public void doCreate(Module module)
public void doCreate();
另外，把方法名稱改成create，系統也一樣能識別。如：
public Page create(WebForm form,Module module)
public Page create(WebForm form)
public Page create(Module module)
public Page create();
public void create(WebForm form,Module module)
public void create(WebForm form)
public void create(Module module)
public void create();
我們可以使用xxx.ejf？easyJWebCommand=create的方式來調用這個方法，也可以使用xxx.ejf？cmd=create的方式來調用，甚至我們還可以使用/ejf/xxx/create的形式來調用。
這種靈活的Action中的命名方法，一方面可以使代碼更加簡潔，易維護，同時也使我們的代碼看起來更cool。另外一個主要原因是其使我們可以非常輕易書寫這些方法的測試代碼，不需要任何Web容器，我們就能運行EasyJWeb的單元測試。
看看Struts那種每個方法都必須生搬硬套的生成下面的方法：
public ActionForward command(ActionMapping mapping, ActionForm form, HttpServletRequest request, HttpServletResponse response) ...{
…
}
對照EasyJWeb中提供的百變Command方法簽名，您是否感覺到這個世界正在前進呢？
3、更多的“動感”地帶
想動就動起來吧，不僅僅體現在方法的書寫方式上。在EasyJWeb中很多地方都用到了這種“動態”的特性，比如forward及go方法提供的多種調用方法，驗證標簽中以自然語言為主體的動態參數配置信息，都體現了EasyJWeb能“動起來”的特性。
以驗證為例，我們可以通過多種方式來告訴EasyJWeb我們需要進行驗證。比如我可以通過在@FormPO中針對一個或多個屬性指定驗證規則，看示例：
@FormPO(name="person",validators=...
{@Validator(name="required",field="name,sex,heigth,borndate"),
@Validator(name="range",field="borndate",value="min:1908-01-01;max:2008-01-01")})
public class Person...{
…屬性及getter/setter方法
}
你應該猜得出來，上面的標簽中我們指定Person對象的name,sex,heigth,borndate等屬性為必填屬性。在驗證數據范圍的RangeValidator中，你可以不用去管要驗證的目標類型是Integer還是BigDecimal或者是Date，只要他能比較，就可以應用該驗證器來對其值范圍進行驗證，確保我們的域模型得到的是一個合理的值。
在標識驗證的時候，可以設置自定義的驗證提示信息。比如你可以使用下面的方式來標識一個范圍驗證：
@Validator(name="range",field="borndate",value="min:1908-01-01;max:2008-01-01;min_msg:出生日期不能小於1908年;max_msg:出生日期不能大於2008年！")
除了min_msg及max_msg以外，你還可以使用基於java習慣的minMsg及maxMsg來標識同樣的驗證提示信息。
