WEB开发网      婵犵數濮烽弫鍛婄箾閳ь剚绻涙担鍐叉搐绾剧懓鈹戦悩瀹犲闁汇倗鍋撻妵鍕箛閸洘顎嶉梺绋款儑閸犳劙濡甸崟顖氬唨闁靛ě浣插亾閹烘鈷掗柛鏇ㄥ亜椤忣參鏌″畝瀣暠閾伙絽銆掑鐓庣仭缁楁垿姊绘担绛嬪殭婵﹫绠撻、姘愁樄婵犫偓娴g硶鏀介柣妯款嚋瀹搞儱螖閻樺弶鍟炵紒鍌氱Ч瀹曟粏顦寸痪鎯с偢瀵爼宕煎☉妯侯瀳缂備焦顨嗗畝鎼佸蓟閻旈鏆嬮柣妤€鐗嗗▓妤呮⒑鐠団€虫灀闁哄懐濮撮悾鐤亹閹烘繃鏅濋梺闈涚墕濡瑩顢欒箛鏃傜瘈闁汇垽娼ф禒锕傛煕閵娿儳鍩f鐐村姍楠炴﹢顢欓懖鈺嬬幢闂備浇顫夊畷妯肩矓椤旇¥浜归柟鐑樻尭娴滃綊姊虹紒妯虹仸闁挎洍鏅涜灋闁告洦鍨遍埛鎴︽煙閼测晛浠滃┑鈥炽偢閹鈽夐幒鎾寸彇缂備緡鍠栭鍛搭敇閸忕厧绶炴俊顖滅帛濞呭洭姊绘担鐟邦嚋缂佽鍊垮缁樼節閸ャ劍娅囬梺绋挎湰缁嬫捇宕㈤悽鍛婄厽閹兼番鍨婚埊鏇㈡煥濮樿埖鐓熼煫鍥ュ劤缁嬭崵绱掔紒妯肩畺缂佺粯绻堝畷姗€濡歌缁辨繈姊绘担绛嬪殐闁搞劋鍗冲畷顖炲级閹寸姵娈鹃梺缁樻⒒閳峰牓寮崒鐐寸厱闁抽敮鍋撻柡鍛懅濡叉劕螣鐞涒剝鏂€闂佺粯鍔曞Ο濠囧吹閻斿皝鏀芥い鏃囨閸斻倝鎽堕悙鐑樼厱闁哄洢鍔屾晶顖炴煕濞嗗繒绠婚柡灞界Ч瀹曨偊宕熼鈧▍锝囩磽娴f彃浜炬繝銏f硾椤戝洨绮绘ィ鍐╃厵閻庢稒岣跨粻姗€鏌ㄥ☉妯夹fい銊e劦閹瑩顢旈崟顓濈礄闂備浇顕栭崰鏍礊婵犲倻鏆﹂柟顖炲亰濡茶鈹戦埄鍐ㄧ祷妞ゎ厾鍏樺璇测槈閵忕姈鈺呮煏婢跺牆鍔撮柛鏂款槺缁辨挻鎷呯粙搴撳亾閸濄儳鐭撶憸鐗堝笒閺嬩線鏌熼崜褏甯涢柡鍛倐閺屻劑鎮ら崒娑橆伓 ---闂傚倸鍊搁崐鐑芥倿閿旈敮鍋撶粭娑樺幘濞差亜鐓涢柛娑卞幘椤斿棝姊虹捄銊ユ珢闁瑰嚖鎷�
开发学院WEB开发Jsp 想动就“动”-Java也可以“动态”灵活 阅读

想动就“动”-Java也可以“动态”灵活

 2008-01-05 20:34:18 来源:WEB开发网 闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥堢亱闂佸湱铏庨崰鏍不椤栫偞鐓ラ柣鏇炲€圭€氾拷闂傚倸鍊搁崐椋庣矆娓氣偓楠炲鏁撻悩鎻掔€梺姹囧灩閻忔艾鐣烽弻銉︾厵闁规鍠栭。濂告煕鎼达紕校闁靛洤瀚伴獮鎺楀箣濠靛啫浜鹃柣銏⑶圭壕濠氭煙閻愵剚鐏辨俊鎻掔墛缁绘盯宕卞Δ鍐冣剝绻涘畝濠佺敖缂佽鲸鎹囧畷鎺戭潩閹典焦鐎搁梻浣烘嚀閸ゆ牠骞忛敓锟�婵犵數濮烽弫鍛婃叏椤撱垹绠柛鎰靛枛瀹告繃銇勯幘瀵哥畼闁硅娲熷缁樼瑹閳ь剙岣胯鐓ら柕鍫濇偪濞差亜惟闁宠桨鑳堕崝锕€顪冮妶鍡楃瑐闁煎啿鐖奸崺濠囧即閵忥紕鍘梺鎼炲劗閺呮稒绂掕缁辨帗娼忛埡浣锋闂佽桨鐒﹂幑鍥极閹剧粯鏅搁柨鐕傛嫹闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥堢亱闂佸湱铏庨崰鏍不椤栫偞鐓ラ柣鏇炲€圭€氾拷  闂傚倸鍊搁崐鐑芥嚄閼哥數浠氱紓鍌欒兌缁垶銆冮崨鏉戠厺鐎广儱顦崡鎶芥煏韫囨洖校闁诲寒鍓熷铏圭磼濡搫顫岄梺鍦拡閸嬪棝鎯€椤忓浂妯勯梺鍝勬湰濞叉ḿ鎹㈠┑濠勭杸闁哄洨濮烽悰銉╂⒒娴e搫甯跺鐟帮攻缁傚秴饪伴崼姘e亾閺冨牆绀冩い蹇庣娴滈箖鏌ㄥ┑鍡涱€楀褜鍠栭湁闁绘ɑ鐟ョ€氼喚绮绘ィ鍐╃厱妞ゆ劑鍊曢弸搴ㄦ煟韫囧鍔滈柕鍥у瀵潙螣閸濆嫬袝婵$偑鍊戦崹娲偡閳哄懎绠栭柍鈺佸暞閸庣喖鏌曢崶褍绨婚柟鍑ゆ嫹
核心提示:只要你愿意,严厉规矩的java也同样可以变得“动态”灵活起来,想动就“动”-Java也可以“动态”灵活,动有动的好处,静有静的好处,可以设置自定义的验证提示信息,比如你可以使用下面的方式来标识一个范围验证:@Validator(name="range",field="borndate&qu
  只要你愿意,严厉规矩的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来标识同样的验证提示信息。

Tags:Java 可以 动态

编辑录入:爽爽 [复制链接] [打 印]
赞助商链接