欢迎您访问程序员文章站本站旨在为大家提供分享程序员计算机编程知识!
您现在的位置是: 首页

免费发布《Wicket开发指南》一书(266页) wicketTapestryASP.netDelphiSwing 

程序员文章站 2022-06-07 19:25:00
...
首先回答问题:
1、这本书的所有章节在GoCom上都可以免费看(Html格式)。
2、这本书是有PDF版本的,在GoCom上有的下!(可能是实名会员能下载吧)
3、元旦前后,我会根据Wicket的新版本以及提交的反馈信息更新该书,书中所有的内容都会做成PDF来下载。(所有人都可以免费下载PDF版本,或者是Word版本)

其实我个人也希望有更多的人来看这本书,学习Wicket,不过我这样做也有自己的原因(并非金钱方面的原因,因为GoCom愿意提供空间,Blog,论坛,还有以后我开源软件的CVS),只能说希望大家谅解了。唯一可以保证的是:尽快和GoCom商量为所有人提供免费的PDF下载。


最近完成了一本关于Wicket的书
感于自己得益于许多开源软件,以及许多的免费书籍,所以这本书也免费开放。
该书266页,约18万字。
你可以在
http://gocom.primeton.com/
这个地址查看该书(谢谢普元的GoCom提供的空间和论坛)
(感觉有点做广告的嫌疑)

你也可以在这个论坛上提出问题,我会尽快回复
http://gocom.primeton.com/modules/newbb/viewforum41.htm

One World,One Dream。


楼下的建议不错。
我把前两节放在下面作为介绍。
因为书的内容比较多,而且GoCom答应提供空间和论坛,所以我也不好在这里直接上传,请谅解,而且GoCom也答应提供PDF版本下载,我也会在元旦前后更新此书,然后免费提供给所有人员。

Wicket前生后世篇
Wicket是什么?简单点说,它就是一个基于Java的Web开发框架,与Struts,WebWork,Tapestry相类似。其特点在于对Html和代码进行了有效的分离(有利于程序员和美工的合作),基于规则的配置(减少了XML等配置文件的使用),学习曲线较低(开发方式与C/S相似),更加易于调试(错误类型比较少容易,而且容易定位)。如果你不对微软并不反感,可以把它看作Java平台上的ASP.NET。
Wicket现在是Sourceforge上一个非常活跃的项目,开发源码基于Apache协议(也是最宽松,对商业最友好的的源码协议),项目位于http://wicket.sourceforge.net,另外它还有一个独立的域名网站http://www.wicketframework.org/。最新的消息则是,Wicket已经成为Apache孵化器中一个项目,可以通过http://incubator.apache.org/projects/wicket.html来访问。但SourceForge上的网站仍然可以访问。
Wicket出现时,著名的J2EE网站TSS(即http://www.TheServerSide.com,以后简称TSS),对该项目也进行了讨论,有一段旷日持久的论战(地址:http://www.theserverside.com/news/thread.tss?thread_id=28162:),论战主力当然就是Wicket的主要作者Jonathan Locke和Tapestry的作者Howard Lewis Ship ,争论的内容十分广泛,从URL的格式到系统结构,从扩展性到界面开发,如果有时间的话,我尽量将其中部分内容翻译过来,还是很精彩的。(TSS上很多的讨论都非常精彩,如果英文好的话,建议经常上去看看,国外的牛人就是多啊。有时候我也觉得很奇怪,这些人都不用睡觉的吗,看他们的帖子,完全覆盖了24小时,感觉他们的老板真是宽容啊)。
Wicket的作者中有几个是原Sun公司Swing小组的开发人员(现在可能大部分已经不是了),因此Wicket的框架中带有浓厚的C/S色彩。而他们的开发计划中,还包括了Swing,Flash平台的支持,也就是说使用Wicket不仅可以可以输出Html,而且可以支持Swing和Flash,不过和朋友经过讨论后,觉得这个计划看起来有一点不切实际,毕竟Html,Swing,Flash之间的差别还是很大,恐怕想要无缝移植,还是有点难度的。单是一个JavaScript,恐怕就够头痛了。
Wicket带有强烈C/S结构的UI色彩,这一点有助于美工和程序人员的分工,与Delphi的开发方式非常类似(Delphi使用.frm文件保存UI控件的定义,而用.pas文件存储代码,从而对控件进行操作)。Wicket则是使用Html描述UI,并将具有特殊标记的Html元素定义为UI控件,在java文件中则直接使用代码操作这些UI控件,控制其输出及行为,样式等。这一点和Tapestry,以及.NET平台上的ASP.NET极为相似,也怪不得与Tapestry的作者争论了这么久,毕竟两者的用户群有很多的重复。其实从结构上看来,无论是Tapestry,ASP.Net,Wicket估计都借鉴了Applet平台上的WebObjects,还有Delphi。(不要忘了,Delphi的创建者Anders Hejlsberg就是.net框架的架构师,所以C#和Asp.net怎么看都带着Delphi的影子。
Wicket目前最新的版本是1.2.2版,已经支持了AJAX,但感觉这个框架的发展时间毕竟还是短了一点,尽管设计思想很不错,但还是有许多问题存在的,包括控件的数量,BUG较多等,希望2006年它可以尽快的成熟起来。

关于重新发明*的争论
谈到Wicket,恐怕第一个感觉就是在Java的Web开发中又多了一个*,这一点国内外的程序员好象都是一样。
有一个国外的Blog专门写了一篇关于*的文章,说明了重复发明*的必要性。我个人对于这种*是持一种欢迎的态度,因为没有人会去写一段功能完全一样的东东,总是要修正了原有*的不足,这样就不能简单当作一种重复。
即使是功能重复,就不需要*了吗?JSP能完成Struts到所有功能,而Tapestry能做到的,Struts也全部可以做到,但Struts,Tapestry就不需要了吗?Struts的MVC结构比JSP更加优秀,在很大程度上减轻了开发人员开发量,而Tapestry基于组件的开发方式,则是开创了一种新的Web开发方式,对于多语言的支持也有了新的方式。以往开发多语言页面时,往往使用properties保存字符串资源,但是页面通常都没有什么变化。而Tapestry可以通过不同的Html为不同的国家指定不同的页面。
Wicket吸收了Tapestry的一部分内容,但我最喜欢的就是,它是基于规则的,而并非XML配置的方式,这不仅有利于程序员学习,对系统的维护及开发规范都很有效,毕竟XML的编写并不见得就比写一段程序来得更容易。(这里插一句题外话,我觉得XML文件用来表示数据和资源,而不是行为,更不是业务,所以对于XML我只用来存放多语言资源或者用来做数据交换。象Spring这种大量使用XML方式,我并不欣赏,Spring也意识到了这一点,在2.0版本中努力的简化Xml的配置,但是并不尽如人意)。如果使用简单的规则来配置或者管理一个系统,用户就会很容易的查找到自己需要的内容。而通过配置文件,不管这样的一个配置文件的结构如何好,也需要在其中查找自己需要的内容,开发效率肯定要低一些。
因此对于这种有创新性的*,多几个,或许Java世界可以跑得更快一些。
去年就听说不少Web框架的开发人员要联合起来开一个Web框架,在Yahoo上还有一个讨论组,上去看了一下。但是这个事件对我的第一感觉就是晕,第二感觉就是特别的晕,虽然目前Java世界的Web框架一通混战,但这样一个联盟,所给出的东西很可能是第二个EJB。