只要你愿意，严肃规矩的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来标识同样的验证提示信息。
[挑战MVC极限]让代码与视图模板的分离
