这些源代码不再需要额外的付出，任何人都可以下载，当作《Wicket开发指南》一书全文下载不方便的一些补偿吧。

下面是下载地址：
http://gocom.primeton.com/modules/newbb/titleflat_5087_41.htm

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

One World,One Dream。

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。