why wicket

为什么是Wicket？

    如果您正在寻求使用Java开发Web应用程序，目前，您有很多的选择。实际上，存在如此众多的Web应用程序框架显得有点搞笑。来自于互联网一个博客站点的问题：您能说出多少Java Web应用框架的名字？他们展现的结果如下：

    框架，到处都是框架，参看后面附带的表格。

    为什么要“重新发明轮子”？

    从这个角度看，您对于“另一个Web应用程序框架有多好”这个问题总是耿耿于怀？确实，为什们要“重新发明轮子”呢？对这个古老的谚语的答复是：因为这一次可以使轮子更圆！

    但是对于高质量的期待并不是构建Wicket框架的唯一动因。甚至有很多的观点，认为没有其他的Web工具集填补这一空白，而Wicket做到了。实际上，Wicket与上面提及的众多框架不太一样。

    与Wicket最相近的或许是Tapestry和Echo，但是这种相似性也很有限。和Tapestry一样，Wicket使用特定的HTML属性来标识组件（Components）声明，这可以方便使用一般的HTML编辑器进行文件编辑。和Echo一样，Wicket拥有一流的组件模型。但是基于 Wicket的应用程序和那些基于Tapestry和Echo的应用程序不一样，这是因为从Wicket框架中两方面都可以受益。您获得了一流的组件模型和对HTML没有干扰所带来的益处。在很多情况下，这种复合的好处可以带来非常重要的开发优势。

    理解了构建Wicket的动机有助于您理解为什么Wicket会表现的不一样。
  
    动机
   目前存在的大多数Web框架对于服务端的状态管理都仅仅提供了较弱的支持。

   这就意味着在Web应用程序中存在着很多特殊的代码来处理和维护繁复的状态管理机制。虽然Wicket并不允许对服务端的状态完全不考虑，但是它在状态管理的简便性和透明化方面做了很多的工作。

   在Wicket中，所有服务端的状态都被纳入了自动的管理。您始终不需要直接使用HttpSession对象或者类似的封装对象去存储状态信息。相反，状态信息已经都与组件关联起来，而在组件后端的数据模型都是传统的Java对象（POJO）。Wicket在每个用户会话期内维护着页面的映射表（Map）。这个页面映射表（以及每个一面内的组件层次）的目的在于使得框架隐藏了组件以及数据模型访问的细节。您只需要处理简单而熟悉的Java对象，而Wicket则处理诸如URL、会话期标识以及GET/POST请求的任务。

   您接着也会发现这种结构良好的服务端状态使得解决令人恐惧的“后退按钮问题”变得十分的容易。实际上，针对页面内组件数据模型的结构性变化带来的数据过期，Wicket提供了通用而且健壮的解决方案，这个方案可以有效地对浏览器缓存页面进行甄别和过期检测。

   最后，Wicket在设计的时候就考虑与诸如JDO和Hibernate的普通Java对象（POJO）序列化框架协同工作。这一点使得构建数据驱动的Web应用程序显得非常简单。

   对于很多应用程序来说，必须在额外服务端状态导致服务器负载增加和其带来的好处之间进行权衡，服务端状态管理可以降低开发成本、减少维护成本、加快对市场的响应时间以及生产高质量的软件。这里提出的基本观点是：软件是十分昂贵、复杂的，而来自于E-machines和Dell的服务器则相对便宜。

在效率和生产性方面，Wicket对JSP的优越性则犹如Java语言对C语言一样。您使用Wicket可以实现的功能使用JSP也都可以实现。甚至于在内存和CPU消耗方面效率也非常的高。但是使用JSP开发应用程序则需要耗费您更多的时间。最后，因为在JSP中进行状态管理时使用了特别的方式，您可能发现不少的安全问题，也能看到到处蹦出来的错误。上面提及的大部分框架在这方面仅仅提供了有限的辅助。

    大部分现存的框架需要特定的HTML代码

   JSP具有最深的侵入性，它允许将Java代码直接嵌入Web页面中。但是，上面列示的框架（除了Tapestry）都不同程度地针对HTML代码引入了特殊的语法。

   因为特殊语法改变了单纯而简单的HTML标记的实质，而Web设计者对于这一点是十分的熟悉，所以特殊语法并不是十分得人心。而且预览、编辑和理解这种包含特殊语法的HTML也是十分困难的事情。

   Wicket并没引入任何新的HTML语法。相反，它通过Wicket命名空间（namespace）的标准兼容方式扩展了HTML，这完全兼容 XHTML标准。这意味这您可以使用Macromedia Dreamweaver、Microsoft Frontpage、Word、Adobe Go Live以及其他现有的HTML编辑器来编辑您的Web页面，并且可以和Wicket的组件协同工作。为了实现这个目标，Wicket始终在Wicket 命名空间内使用单个id属性（“wicket:id”）来标识那些需要框架进行特殊处理的标签。如果您并不喜欢将有Wicket命名空间修饰的标签和属性展示给您的最终用户，通过简单的设置就可以完全消除它们，从而得到普通的与标准兼容的HTML代码。

   HTML中没有特殊的语法意味着设计者可以直接模拟页面，而您可以在开发的过程中直接使用这些页面。向HTML页面中添加Java组件就和设置组件的名称属性一样简单。然后，您可以直接将这些页面交给Web设计人员，他们可以充满信心地对其进行修改。

   与其他的应用框架相比，Wicket在各方面的分离上提供更多的支持。Web设计者在对应用程序代码不甚了解的情况下就可以编辑HTML（当然，他们不能移除组件名称标签，而且不能任意改变组件嵌套的层次，其他的事情都是可以的）。另一方面，编程者只需要关注与HTML混在一起的Java组件，而不需要了解页面的最终陈现是什么样子。通过这种职能清楚的工作方式，每个人都可以工作得更为顺畅。

    现存的框架易用性不好

   目前存在的大部分框架工具在对象模型方面做得不够。在一些框架中，对象模型是通过特定的XML来定义的。这些语法令人生厌，而且还需要特定的工具来编辑这些配置信息。由于这些框架并不是单一的Java类库，您就不能使用包含编辑器、调试器和编译器的IDE工具来编辑它们。

   Wicket是化繁为简的代表。在学习Wicket的过程中不需要了解任何配置文件。Wicket就是组件结构良好的普通的类库。在Wicket中，您的 Web应用程序与普通的Swing应用程序类似，而不是JSP应用程序。如果您熟悉Java（特别是如果您熟悉Swing），那么您就已经对Wicket 有不少的了解了。

    现存的框架可复用性不好

   Tapestry和JSF虽然有可以重用的组件模型，但是您将发现与Wicket相比这并不是特别容易做到的事情。Wicket从设计之初就十分地注重组件的复用。在Wicket中，从现有的组件扩展编制诸如SignInPanel或者AddressForm的复合组件是十分简单的事情。相对来说，针对浏览器的新特性编制新的组件也是十分容易的事情。Wicket的组件可以使用JAR格式进行打包，直接通过库引用的方式就可以实现重用——不需要任何配置文件！

   Web编程应该更关注编程乐趣！

   这就是我编写Wicket的个人方面的目标。现存的框架在实现开发的直接性、快捷性和简易性方面真正地吸引我。我希望Wicket在Web应用程序开发的建议性和乐趣方面能够迈出重要的一步。

    目标

    基于上面的这些动机，下面是Wicket的目标：

简单（易用性、一致性、易懂性）
  以POJO为核心
所有代码均使用Java编写
最小的概念域
避免过度地使用XML配置文件
全面解决“向后按钮”问题
最大限度地类型安全以及编译检查
最大限度地分析运行时错误
对特定工具集的最小依赖
组件、容器和惯例始终保持一致性
复用
使用Wicket编制的组件具备高度的复用性
可复用的组件可以使用JAR文件发布
无侵入
HTML以及其他标记性文件不会编程语法所干涉
在标记方面只有一个简单的标签
  与任何普通的HTML编辑器兼容
  图形开发人员很容易识别并避免修改框架标签
  如果设计者不小心删除了标签，则很容易恢复它
安全
默认情况下代码都是安全的
在页面和URL中，只有显式的声明的链接才能公布数据状态
具备最大限度类型安全逻辑
很容易集成到Java安全框架
富有效率，可伸缩性
在不牺牲其他目标的前提下保证效率和轻量级
可依附的优选会话期支持集群
通过与可分离模型的协作，会话复制形成的集群很容易实现和调整
完整
Wicket团队乐于为开发Java Web应用贡献可用的且特性齐全的框架。核心框架是由本篇文档的作者Jonathan Locke编写和贡献的。目前的团队包括了很多经验丰富的程序员，他们中的一些人还是上面提及的其他框架的开发者，他们也都拥有构建大型Java Web应用的经验。我们对自己的处境十分的了解，因此也更能从框架使用者的角度来开发Wicket。