使用基于组件的框架
在为传统的Web 应用编写HTML 页面的时候，页面作者手边只有非常有限的一套预定义GUI 组件，即HTML 表单元素。它们的特征集近10 年来几乎没有什么变化，与现代的GUI 工具集相比，它们是非常基础和令人失望的。如果页面作者希望引入树控件或者可编辑的栅格、日历控件或者动态的分级菜单之类的，就需要借助于基础文档元素的低层编程。这跟开发者使用组件工具集（例如MFC、GTK+ 、Cocoa 、Swing 或QT）来创建桌面GUI 的抽象级相比，似乎是非常差的选择。
1. Web UI 组件
基于组件的框架的目标是通过提供服务器端组件工具集（其API 类似于桌面GUI 组件集的API），来提高Web UI 编程的抽象级别。当桌面UI 组件呈现自身的时候，它们通常使用低层调用在一个图形上下文上绘图，来生成几何图元、位图或者类似的东西。当基于Web 的UI 组件呈现自身的时候，它们自动生成能在浏览器中提供相同功能的HTML和JavaScript 流，以减轻可怜的编程者在低层编程的苦差事。图5-4 展示了基于组件的Web 框架的结构。
图5-4 基于组件的框架的架构。应用被描述为一些组件的集合，它们通过向浏览器发送HTML和JavaScrpt流来呈现自己。除了搜集浏览器发送到单个组件的请求的较大的控制器和较大的领域模型外，每个组件还包含自己的小规模的模型、视图和控制器
很多基于组件的框架都使用桌面风格的隐喻来描述用户交互。也就是说，按钮组件应该有点击事件的处理函数，而文本域组件应该有valueChange 处理函数，等等。在大多数框架中，通过每一次用户交互触发一个请求，大部分的事件处理都委派给了服务器。更加聪明的框架则设法在场景的背后完成这样的任务，但是在有些框架中每一次用户事件都会刷新整个页面。这明显导致了笨拙的用户体验，因为一个设计成UI组件集的应用，相对于使用Model2 设计成页面集合的应用，通常会有大量细粒度的交互。
这些框架的重要设计目标是能够从一个单独的UI组件模型描述来呈现不同类型的用户界面。一些框架，例如，针对.NET和JSF（JavaServer Faces）的Windows 表单，已经能够做这件事了。
2. 与Ajax 互操作
那么基于组件的框架如何适应Ajax 呢？表面上看，两者都是从类似文档的界面向基于UI 组件的界面转化的，所以出现重叠应该是件好事。如果理解Ajax 的可插拔的呈现引擎能够开发出来，这种类型的框架会强大到足以生成客户端应用。这样做有相当大的吸引力，因为它可以避免对开发者进行再培训去学习JavaScript 的复杂性，并且它通过普通的旧式（plain-old）HTML 呈现系统，为较为陈旧的浏览器提供了一个替代品。
对于那些仅仅需要标准UI 组件类型的应用，这样的解决方案会工作得很好。然而，仅有一定程度的灵活性是不够的。例如Google Maps （参见第1 章）成功的很大原因就在于它定义了自己的UI 组件集，从可滚动的地图到用于缩放的滑动条、可弹出的气球提示和地图上的大头针等等。试图使用桌面UI 组件的标准集合来创建这些效果是非常困难的，即使最终创建出来了也可能不会令人满意。
也就是说，很多应用的确更容易适应传统范围内的UI 组件类型，这种类型的框架可以很好地为它们服务。在灵活性和方便性之间取得平衡对于很多基于代码生成的解决方案是相通的，也很容易理解。
为了给Ajax 应用提供完全的服务，框架也必须有能力提供必要的数据。这可能会有更多的问题，因为控制器紧紧地绑在了服务器层上，并且紧紧束缚在通过桌面隐喻来定义的机制上。有很好响应性的Ajax 应用需要更多的自由来确定它自己的事件处理函数，而不是服务器事件模型看起来允许的那样。尽管如此，在这些框架的背后还是有股相当大的动力。无疑，伴随着Ajax 越来越流行，更多的这类解决方案还会浮现出来。5.5.3 节将要引入的命令队列可能是向着JSF 及其类似框架发展的一种方法，虽然它并不是为了这个目的设计的。目前从我的喜好来看，这些框架将客户端绑的有点太紧了。
观察这些框架如何在将来适应Ajax 是一件很有趣的事情。Sun 的内部和一些JSF 厂商对于提供支持Ajax 的工具集已经产生了巨大的兴趣，.NET 表单已经可以支持一些类似于Ajax 的功能，并且承诺在即将来临的Atlas 工具集中提供更多的支持（参见本章“资源”一节以获得所有内容的URL）。
这也提出了一个问题：如果Web 框架专门为Ajax 来设计，那么它看起来应该是个什么样子？今天，这类框架还没有出现，我们在这里阐述的Web 框架终有一天会被认为是这类框架的先驱。