今天下载了Jive 3.0来试用,准备研究一下Jive的新特性,为Jute下一步发展做一些参考。研究过程中的发现将会收集起来与大家一起分享。
标题:Jive3.0 Webwork和 Jute1.0 Action Mapping 之间的比较
作者:Rainmanzhu
时间:2002-11-29
来自:http://www.cjsdn.com
内容:
Jive3.0中,包含了一个webwork的框架,看命名就能理解是用来处理网页链接以完成一系列相关的任务。因为http协议是无状态的,所以如果任务是分步执行的就必须定义协议把多个链接串(chain)起来,一般情况下任务处理会有出错或成功的分支,比如新添话题这样一个任务,如果文章标题过长,就需要把出错页面显示给用户;如果成功加入话题,又需要提示用户发贴成功,在jive中,这个action是定义在actions.xml的:
<action name="PostAction" alias="post">
<view name="attach">attach!default.jspa</view>
<view name="cancel">doRedirect.jspa?url={last}</view>
<view name="error">postform.jsp</view>
<view name="input">postform.jsp</view>
<view name="login">loginform.jsp</view>
<view name="preview">viewpreview.jsp</view>
<view name="rejected">postform.jsp</view>
<view name="spellcheck">spell!default.jspa</view>
<view name="success">postform-success.jsp</view>
</action>
可以看到这个动作有很多个分支,并且有些分支是链起来的(加粗的地方),如attach。当然actions.xml中也定义了attach动作:
<action name="AttachAction" alias="attach">
<view name="input">attachform.jsp</view>
<view name="error">attachform.jsp</view>
<view name="success">postform-success.jsp</view>
<view name="cancel">post!default.jspa</view>
<view name="unauth">error.jsp</view>
</action>
cancel动作就使得能返回到发贴动作。action的name事实上是指向jive定义的一个类的,所以动作的逻辑均在该类中实现。action类的基类都是com.jivesoftware.webwork.action.Action,内有一抽象excute()方法。action的分发统一通过com.jivesoftware.webwork.dispatcher.ServletDispatcher来进行,ServletDispatcher通过url (*.jspa -jsp action?)来寻找相应的action,然后设置ActionContext(动作环境,所有参数都通过该类传递给action,传递是根据同一线程来进行的,方法非常之好!),最后执行action的excute()方法,方法返回值为view(如attach,cancel...),而view对应的jsp在actions.xml也定义好了!ServletDispatcher再通过RequestDispatcher转发给jsp页面,应用服务器再执行jsp生成html。
上面稍微分析了一下jive中的webwork是怎么回事,其实本文最重要的是分析jive为什么要引入webwork?从jive发展的历史来看,1.0的jive是用javabean+jsp的模式,两个jsp之间没有固定联系,而且都堆积在一个根目录下,这样维护是非常糟糕的,jive当时也支持skin,但可以看到每个skin都是写了一堆这样的jsp,几乎没有重用性!其实这种模式是2层的,缺乏了控制层,如判断用户登录状态等,每个需要的地方都需要调用api,jsp里出现了大量的java代码,所以每次jive升级,都可以看到先前的jsp几乎面目全非,这对一个快速发展的项目来说,是非常的一个阻碍因素,当时的jive重点在数据层的设计可能是一个原因。2.0以后的Jive我似乎看过,发现设计上没什么大改。但jive3.0带了一个make sense的三层结构,数据层仍然不变,中间层为action,表现层为使用标签的简化jsp。我认为这才是真正有意义的设计。顺便提一点,webwork定义了一组标签用于jsp:
如首页当中的:
<%-- Print info messages if they exist --%>
<ww:if test="infoMessages/hasNext == true">
<%@ include file="info-messages.jsp" %>
<br><br>
</ww:if>
通过标签的使用,jive界面的可控性变得良好起来。
稍后我会重点分析一下webwork的性能,希望能从中学到一些好方法。
Jute 1.0也是非常成熟的三层结构,中间层采用Servlet Mapping+Action Mapping,将不同功能组通过url前缀区分开来,同一功能组根据功能的复杂程度来选择定义新的Servlet或选择定义新的Action来分隔代码。采用继承和抽象方法来重用代码,Jute所有的Servlet都从JuteServlet继承。事实上其他Servlet都是定义Action组!每个Servlet都有perform(Context context, CGI cgi)方法,是缺省的action;然后可以定义其他action来完成不同的动作,Jute的CGI类类似Jive的ActionContext,Request,Cookie,Session都通过cgi对象获取,为了提高性能,CGI类是通过对象Pool创建的;Jive每次都创建新的ActionContext,并保存在ThreadLocal内!这点是偶以前没想到的,稍后研究一下。而Jute的Context类事实上是TemplateContext(hash结构),也可以用于保存控制层状态,但更多用于向界面层提供数据。
基类JuteServlet里有excuteAction方法,方法执行结束后返回界面模板,这点和jive非常类似!!!但区别也非常大!Jive是用静态映射action的,而Jute是运行时刻映射的,最终两者都通过cache来加快寻找action的,但Jive可以定义action chain,及action的各种view,并能保存上一个action,对于action执行过程中产生的错误也能保存在action中,并且通过修改配置扩展功能。而Jute的Action mapping,能通过cgi类来保存上一次状态,类似采用ASP.Net中的ViewState。创建action chain的时候比较麻烦,要注意保存每个过程的上一个状态,而这样url就变得非常长!Jive缺省可以嵌套10层。
Jive可以这样写:
<a href="<%= path %>/<ww:property value="previousURL" />">Go Back</a>来获取上一个url。
我觉得日后可以修改Jute来改进Http状态的保存。
Jute的返回界面没有象jive一样采用mapping方法,而是直接写在相应action方法中,因为界面和action关系紧密,一般不能变换,但在界面模板里可以通过include方法来嵌入子模板。
综上所述,Jive 3.0体系更加成熟,采用的设计模式更加丰富了,非常值得采用Servlet技术的网络应用开发者学习。相当于cgi,mod-perl,php,asp,asp+等技术,servlet功能更强大,更灵活,也容易开发出好的framework,目前java世界里的framework不计其数!而现在仍采用cgi技术开发显得比较落后,缺乏安全性保证;php只适合小型网站的快速开发,一但代码到达一定量,维护和升级就是很大的问题,也不容易进行代码的性能调节;早期的ASP技术(VBScript)也显得比较落后,ASP+已经取而代之,但ASP+的缺点是底层代码不公开造成自己来开发Framework比较困难,市面上缺乏成熟可靠的应用框架,我看过微软推荐的ASP.Net开源项目,其中应用的设计模式偶觉得远不如Java。而从Jive的发展我们可以看到采用Java技术带来的灵活性,在Jive的数据库层(包括Cache层)成熟后,Jive的开发者又着手优化上层的设计,虽然这一阶段代码修改量很大,但这样做是非常值得的,将来Jive可以有更快发展的!
Jute在系统架构上比较成熟是一个优势,但框架还比较简单,虽然已经满足了目前的开发需求,但仍需要完善整个框架。
Jive3.0 Webwork和 Jute1.0 Action Mapping 之间的比较
最新推荐文章于 2021-02-15 19:11:15 发布