- 浏览: 221182 次
- 性别:
- 来自: 广州
-
文章分类
最新评论
-
thebye85:
引用 另外一个需要注意的问题,就是SessionMap和隐藏对 ...
WebWork深度探索之Session -
lanxiaoshuang:
写的真好
说的都是概念——有关编程范式 -
lhz:
grep unique wc你需要的只是这么几个小工具而已
努力做个Pragmatic Programmer
大约一年前,我为一个小型项目选择框架的时候,WebWork第一次进入了我的视野,它优美的设计以及强大的功能,再配以平缓的学习曲线深深打动了我。在一番比较过后,我毫不犹豫地选择了WebWork并用它顺利完成了这个项目,并且在开发过程中写了不少总结性的文章。尽管WebWork有着这样那样的优势,但是它本身仍然存在着诸多的不足,社区不够活跃,更新速度太慢,最糟糕的就是文档太少且质量参差不齐,这些因素都使得WebWork并没有如期待那样流行,而我写的文章也鲜有人浏览就是明证。去年在写完了深入探索WebWork系列最后一篇之后,我就把WebWork暂时放到了一边。
时光飞逝,一年过去了,WebWork就在我不经意间悄悄地发展,从我最初使用的2.1.2到2.1.7再到现在2.2beta,而我写的《WebWork初体验》也悄无声息地爬上了阅读量的排行榜,扣除有关股票的那篇Post不计,这篇文章已经成为了技术方面最受关注的文章。在最近我也不时收到一些朋友给我发来的mail询问有关WebWork的问题,这也让我点受宠若惊。这个曾经让我如此心动的框架再次闯入了我的IT生活,牵动着我的心。随着WebWork2.2beta的发布,随着大家对WebWork关注程度的提高,随着《WebWork in Action》的出版,随着......我想是时候重新扬帆,为推广这个从过去到现在都让我赞叹的框架出一点点力了。而我最先想到的自然就是翻译《WebWork in Action》。
《WebWork in Action》是一本翘首企盼了很久的书,它的分量之重自然不需要多言了。我来翻译这样一本书,确实有点高攀了,但这是一本值得细细品味的书,翻译则是一个很好的驱动力,促使自己更加专注的研读每一段,每一字句。至于翻译的文字能否面世,则需要看机会了,但不管怎么样,我一定会完成这样一项工作,哪怕我的文字艰深晦涩,无人喝彩,我也会敝帚自珍,将这些译文好好收藏。呵呵~~~
好了,说了那么多废话,也该说说正题了。经过一个星期的努力,终于把该书的第一章给翻译完毕了,鉴于版权的问题,我不能把这些文字公布出来让大家扔鸡蛋,但是我仍然想说说自己在看完并译完第一章之后所得到的启发。
第一章是对WebWork的概述。在讲述WebWork的特性之前,作者花了相当的篇幅对MVC的作用以及发展做了介绍。通过这些介绍,你可以了解到MVC的产生是为了解决GUI应用程序中存在的紧耦合问题。这里的紧耦合是指域对象逻辑与显示逻辑之间的紧密耦合,为了能够将业务逻辑从显示层面的代码中剥离出来,MVC模式派上了极大的用场。然而这样一个具有历史意义的模式并不能直接应用到Web环境中,因为HTTP并不是有状态的连接协议,而Web应用程序都被抽象成了Request/Response形式。因此稍作改变的MVC才能很好地为Web应用程序所用,这变化的MVC通常有两种——Front Controller与Page Controller。对于这两个名词,很多朋友应该都不会陌生了,很多流行的J2EE框架使用的就是前者,而ASP.NET则是后者的拥趸。首先,Front Controller的出现是因为在Web环境下,View并不是一个可以独立更新的对象,而是一个由请求引发其本身render的画面,因此,在经典的MVC中Model与View直接通信的情况就不复存在了。取而代之的是Controller与View通信,而View则通过Request Dispatcher来匹配不同的Controller,由Controller更新Model,再由Controller返回一个值,根据不同的返回值render不同的View,同时Controller将需要显示的数据Push至View中。而Page Controller则经典MVC模式进化的另外一种方式。与Front Controller相比,Page Controller在结构上则要简单得多,并不存在Request Dispatcher这个部分。大家可以发现,在ASP.NET中,Browser请求的是.aspx资源,而一个.aspx则与一个Page类的派生类对应,其中可能包含了OnLoad, OnRender以及响应Control事件的自定义方法,由这些方法中的某一个来完成View的render工作,这个由Page类派生出来的子类就是Page Controller。Page Controller模式在解耦合方面不算称职,但是它的开发效率极高,在Visual Studio这类开发工具的支持下尤为突出。这两种模式各有优势,而WebWork对它们都提供了良好的支持,给开发者留下了可选择的空间。
在讲完了MVC之后,作者又对Framework和Container作了深入的阐述和比较。偶认为这一节的文字是第一章最为精彩,且最有价值的。文中引用了WebWork缔造者Rickard Oberg的妙语对框架做出解释:A framework's power comes not from what it allows, but from what it does not allow. Framework强调的是限制,其中有组织结构的限制,也有Flow的限制。这样的限制可能减少了你大展拳脚的机会,却会给你的应用程序带来清晰的脉络结构,更加重要的是可以使得一个团队进行协作开发,开发效率得到提高,软件的规模也会随之扩大。这就是框架所带来的巨大作用。与Framework相反,Container则不是专注在限制,其目的是提供一个环境来装载特定的对象,并增强这些对象的功能性,同时又不影响对象之间的独立性。Servlet Container和EJB Container,还有很hot的Inversion of Control Container都具有这样的特性。WebWork是两者的组合体,除了提供框架之外,还为开发人员提供一个Lightweight Container。在第一章剩下的篇幅里,作者还回顾了WebWork的发展史并展望了未来。嗯,未来真的很诱人。
好了,对第一章的感受就讲到这里了,但愿各位也能够随我一起关注WebWork吧!
时光飞逝,一年过去了,WebWork就在我不经意间悄悄地发展,从我最初使用的2.1.2到2.1.7再到现在2.2beta,而我写的《WebWork初体验》也悄无声息地爬上了阅读量的排行榜,扣除有关股票的那篇Post不计,这篇文章已经成为了技术方面最受关注的文章。在最近我也不时收到一些朋友给我发来的mail询问有关WebWork的问题,这也让我点受宠若惊。这个曾经让我如此心动的框架再次闯入了我的IT生活,牵动着我的心。随着WebWork2.2beta的发布,随着大家对WebWork关注程度的提高,随着《WebWork in Action》的出版,随着......我想是时候重新扬帆,为推广这个从过去到现在都让我赞叹的框架出一点点力了。而我最先想到的自然就是翻译《WebWork in Action》。
《WebWork in Action》是一本翘首企盼了很久的书,它的分量之重自然不需要多言了。我来翻译这样一本书,确实有点高攀了,但这是一本值得细细品味的书,翻译则是一个很好的驱动力,促使自己更加专注的研读每一段,每一字句。至于翻译的文字能否面世,则需要看机会了,但不管怎么样,我一定会完成这样一项工作,哪怕我的文字艰深晦涩,无人喝彩,我也会敝帚自珍,将这些译文好好收藏。呵呵~~~
好了,说了那么多废话,也该说说正题了。经过一个星期的努力,终于把该书的第一章给翻译完毕了,鉴于版权的问题,我不能把这些文字公布出来让大家扔鸡蛋,但是我仍然想说说自己在看完并译完第一章之后所得到的启发。
第一章是对WebWork的概述。在讲述WebWork的特性之前,作者花了相当的篇幅对MVC的作用以及发展做了介绍。通过这些介绍,你可以了解到MVC的产生是为了解决GUI应用程序中存在的紧耦合问题。这里的紧耦合是指域对象逻辑与显示逻辑之间的紧密耦合,为了能够将业务逻辑从显示层面的代码中剥离出来,MVC模式派上了极大的用场。然而这样一个具有历史意义的模式并不能直接应用到Web环境中,因为HTTP并不是有状态的连接协议,而Web应用程序都被抽象成了Request/Response形式。因此稍作改变的MVC才能很好地为Web应用程序所用,这变化的MVC通常有两种——Front Controller与Page Controller。对于这两个名词,很多朋友应该都不会陌生了,很多流行的J2EE框架使用的就是前者,而ASP.NET则是后者的拥趸。首先,Front Controller的出现是因为在Web环境下,View并不是一个可以独立更新的对象,而是一个由请求引发其本身render的画面,因此,在经典的MVC中Model与View直接通信的情况就不复存在了。取而代之的是Controller与View通信,而View则通过Request Dispatcher来匹配不同的Controller,由Controller更新Model,再由Controller返回一个值,根据不同的返回值render不同的View,同时Controller将需要显示的数据Push至View中。而Page Controller则经典MVC模式进化的另外一种方式。与Front Controller相比,Page Controller在结构上则要简单得多,并不存在Request Dispatcher这个部分。大家可以发现,在ASP.NET中,Browser请求的是.aspx资源,而一个.aspx则与一个Page类的派生类对应,其中可能包含了OnLoad, OnRender以及响应Control事件的自定义方法,由这些方法中的某一个来完成View的render工作,这个由Page类派生出来的子类就是Page Controller。Page Controller模式在解耦合方面不算称职,但是它的开发效率极高,在Visual Studio这类开发工具的支持下尤为突出。这两种模式各有优势,而WebWork对它们都提供了良好的支持,给开发者留下了可选择的空间。
在讲完了MVC之后,作者又对Framework和Container作了深入的阐述和比较。偶认为这一节的文字是第一章最为精彩,且最有价值的。文中引用了WebWork缔造者Rickard Oberg的妙语对框架做出解释:A framework's power comes not from what it allows, but from what it does not allow. Framework强调的是限制,其中有组织结构的限制,也有Flow的限制。这样的限制可能减少了你大展拳脚的机会,却会给你的应用程序带来清晰的脉络结构,更加重要的是可以使得一个团队进行协作开发,开发效率得到提高,软件的规模也会随之扩大。这就是框架所带来的巨大作用。与Framework相反,Container则不是专注在限制,其目的是提供一个环境来装载特定的对象,并增强这些对象的功能性,同时又不影响对象之间的独立性。Servlet Container和EJB Container,还有很hot的Inversion of Control Container都具有这样的特性。WebWork是两者的组合体,除了提供框架之外,还为开发人员提供一个Lightweight Container。在第一章剩下的篇幅里,作者还回顾了WebWork的发展史并展望了未来。嗯,未来真的很诱人。
好了,对第一章的感受就讲到这里了,但愿各位也能够随我一起关注WebWork吧!
发表评论
-
在String的面前丢脸
2004-06-18 00:39 1231重返C++的世 ... -
Summary of function parameter
2004-07-14 02:33 1123对C++这位入 ... -
此Vector非彼Vector
2004-08-05 15:51 1011在学习STL的过程中,我发现了一个熟悉的面孔— ... -
模板——泛型和STL的基础
2004-08-07 01:01 1294所谓泛型,从字面上可以猜想,就是泛化的类型(型 ... -
让人头痛的Vector(提问篇)
2004-08-07 16:55 1202在写完了此Vector非彼Vector这篇随笔 ... -
我该怎样shuffle呢
2004-08-10 01:47 1106在STL的Algorithm中有着这样的一种算 ... -
WebWork初体验
2004-08-11 17:43 1229在这篇ASP.NET ... -
WebWork深度探索之盲人摸象
2004-08-12 23:54 1064昨天尝试着利用WebWork做了一个小功能[1 ... -
WebWork深度探索之号外
2004-08-14 09:03 1005昨天开始对WebWork进行了一些初步的探索[ ... -
WebWork深度探索之标签库
2004-08-15 00:28 1501由于WebWork本身提供了一套自定义的标签库 ... -
什么是Law of Demeter
2004-08-15 14:22 1178今天一如昨日,继续对WebWork进行小打小闹 ... -
所谓的Dumb Question
2004-08-15 17:16 989为了能够更 ... -
WebWork深度探索之标签库(续)
2004-08-16 15:58 1091昨日对WebWork的标签库进行了小小的研究[ ... -
WebWork深入探索之初见端倪
2004-08-19 16:35 858使用WebWork进 ... -
建网站的小Tips
2004-08-20 23:58 989这几天都在忙着做一个小网站,从网页美工到后台处 ... -
URL与RequestDispatcher
2004-08-21 23:58 969今天照例继续自己的网站建设之旅,原本以为可以大 ... -
WebWork深度探索之Pitfall
2004-08-25 14:31 935在使用WebWork进行开发的过程中,她的种种 ... -
WebWork深度探索之Session
2004-08-26 15:38 1493昨天上午刚 ... -
搞笑的textarea标签
2004-08-31 18:17 1560很久没有用 ... -
两天四疑问
2004-09-03 10:56 9479月份的前两天,我仍然做着网站开发的工作。在开 ...
相关推荐
webwork +是一个针对数学方程式提供直观输入的第三方Chrome扩展。虽然主要用于WebWork,但它可以在其他网站上运行,只要CSS不会发生冲突。WebWork +在WebWork上自动启用。要在另一个站点上启用它,请单击工具栏中的...
WebWork 当然也提供了很友好的拦截器来实现对文件的上传,让我们可以专注与业务逻辑的设计和实现,在实现上传和下载时顺便关注了下框架上传下载的实现。 1. 包装 Request 请求 •每次客户端请求 Action 时,都会...
Struts能充分满足应用开发的需求,简单易用,敏捷迅速,在过去的一年中颇受关注。 Struts把Servlet、JSP、自定义标签和信息资源(message resources)整合到一个统一的框架中,开发人员利用其进行开发时不用再自己...
a) Struts2是以web work优秀的设计思想为核心,吸收了struts1的部分优点,建立了一个基于webwork和struts1的MVC框架。 二、 优点: a) 结构清晰,使开发者只关注业务逻辑实现即可。 b) 提供了丰富的标签,大大提高了...
尽管这些技术在国外都已进很流行了,但在国内能够将Hibernate、 Struts、Spring、DBUnit、Ant、Log4J、Struts Menu、Xdoclet、SiteMesh、Velocity、JUnit、JSTL、WebWork这些技术集成到一个框架中的还不多见,所以...
众所周知,Struts2是以Webwork2作为基础发展出来,WebWork是一个强大的基于Web的MVC框架, 它构建在一个命令模式框架XWork之上。 WebWork真正的优势在于它强调简洁和协作能力的根本理念. 使用WebWork将有助于最小化...
控制反转是一种设计原则,用于减少代码间的耦合,而AOP则是一种编程范式,允许开发者将横切关注点(如事务管理、安全等)从业务逻辑中分离出来。 2. **关键策略**:Spring框架的关键策略包括低侵入性编程、松耦合和...
关键词:SSH集成框架 Web 1主流Web开发框架分析 1.1 MVC结构模式和WebWork框架 2012年王欢认为MVC的工作原理是,使用MVC时,当用户向Web容器发送一个请求后, Web容器会根据请求和地址去调用一个Servlet进行处理,...
* 实现 MVC 模式,结构清楚,使开发者只需关注业务逻辑的实现。 * 有丰富的 tag 可以用,能大大提高开发效率,缩短开发时间。 * 页面导航。通过一个配置文献,即可把握整个系统各部分之间的联系,这对于后期的维护有...
2. Spring的优点包括使用AOP可以创立非行为性的关注点、IOC允许创立一个可以构造对象的应用环境等。 本文涵盖了Java工程师三大框架的面试题,包括Hibernate、Struts、Spring三个方面,涵盖了框架的原理、优点、流程...
这是一项正在进行的调查的一部分,旨在找到我喜欢的前端开发方法和框架。 多年来,我的旅程和偏好是: 标准 Web(例如 WebWork、Cocoon、Spring MVC) Java Swing(和 WebStart) Adobe Flex(和 Air) 使用 ...
随着技术、经验的不断积累,你会逐步关注分析、设计等更高层次的知识,这时候,你可进一步学习相关的UML、模式等知识(积累了一定经验,你就可以安排自己学习这些知识了)。 6. 小结 永远记住:自始至终,实践是学习...