![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
开始之前
要按照本教程所述进行操作，您需要以下软件：
- IBM Rational® Application Developer V6.0.1.1 或更高版本（以下称为 Application Developer）
- WebSphere Portal V6.0 或更高版本，本系列教程均需要此软件。如果使用的是 WebSphere Portal V6.0，还需要 WebSphere Portal V6.0 fix pack 1（请参见参考资料）。
- Web Content Management Version 6.0 或更高版本。Web Content Management 包含在您的 Portal server 安装中，采用的是有限许可。
在本系列前面的教程中，我们创建了应用程序对象来访问“当前”信息。Websphere Portal Personalization（以下称为 Personalization）还实现了一个列表，称为资源集合（在第 1 部分进行了介绍）。本部分将说明如何创建和使用资源集合来从 ATOM Feed 选择内容列表，以便能将其他个性化外部内容集成到门户中。开始本教程的学习前，请下载集合的示例代码和二进制文件。
资源集合使用 Abdera（Apache 的一个开源项目）来将 Feed XML 解析为 Java 对象。图 1 说明了外部内容源与 Web Content Management 的 Personalization 组件间的关系。ATOM XML 通过 HTTP 发送到 Feed 资源集合实现（包括在下载部分中）。
图 1. ATOM 充当外部内容源与 Web Content Management Personalization 组件间的通信传输机制
WebSphere Portal Personalization 在 Feed 上充当筛选器，而 Web Content Management 为 Feed 提供表示层。要将 Web Content Management 作为另一个内容源的表示层使用，直接为该内容创建 ATOM Feed 即可。
使用 Feed 作为通信协议可带来一系列优势。可以对各种源使用集合——任何已经生成 ATOM Feed 的源。可以在集合和 Feed 生成器之间使用 HTTP 缓存，还可以将生成器移到远程服务器上。
如果对 ATOM 进行扩展，也可以通过集合处理这些属性。可以将其作为资源集合的动态属性进行访问。
可采用两种方法查询或筛选资源集合；我们将在下面对这两种方法进行讨论。我们的示例集合类实现第二个方法，称为内存筛选。将查询一直解析到数据库当然具有优势。Application Developer 包括了用于为 SQL 数据库和 LDAP 目录生成资源集合代码的向导。这些生成的资源集合将查询传递给数据库和目录。请将 Application Developer 生成的代码作为示例，了解如何将规则的查询转换为数据库可以理解的表格。
图 2 显示了 Feed 生成器处理筛选的方法。椭圆表示数据或对象，矩形表示代码或组件的位。规则的查询被转换为查询字符串，并作为请求参数传递给 Feed 生成器。资源集合要负责将查询对象转换为采用 Feed Servlet 所预期的格式的查询字符串，如 SQL 或 Xpath。
图 2. 在 Feed 生成器中完成筛选的数据流
Feed 生成器将查询字符串传递给数据库或存储库并返回包含与查询字符串匹配的条目的 Feed。资源集合将 Feed 条目转换为资源。在此方法中，单个 Feed Servlet 可以处理所有请求。该 Servlet 将基于规则检索不同的请求。此方法的劣势在于，Feed 生成器必须理解查询字符串。因此，采用此方法构建的资源集合将仅能用于专门针对此资源集合设计的 Feed 生成器。
图 3 显示了内存筛选方法，其中资源集合会从生成器检索 Feed 内容，数据将在使用者的内存中进行筛选。椭圆表示数据或对象，矩形表示代码或组件的位。
图 3. 在资源集合中采用内存筛选的数据流
这对于筛选 100 个项左右的初始集能够正常工作，但对于大数据集将会失败。此方法的优势在于，此集合将完全基于标准。使用前一方法时，Feed Servlet 必须理解查询字符串格式，因此不能将第一个方法用于所有 Feed。
这些实际的限制并不意味着在数据集较大的情况下无法应用完全基于标准的内存筛选。不过，必须考虑 Feed 的生成。每个规则标识其将使用的 Feed。不同的规则可以使用不同的 Feed URL，每个不同的 Feed 可以在应用规则前对结果进行预先筛选。如果 Servlet 或 JSP 作为 Feed 生成器使用，该 Servlet 仍然可以接受请求参数来对 Feed 进行限制。
图 4. 缓存 Feed 响应
采用内存筛选时，Feed 的内容必须与希望在最终页面的特定位置显示的内容列表大致匹配。一个选择规则将使用一个 Feed。可以使用 Personalization 绑定规则组合 Feed 或排除特定的结果，但对 Feed 条目的排除和组合受到实际的内存和性能的限制。通常，一个 Feed URL 文档与采用内存方法的最终 Web Content Management 页面上的一个列表大体相同。
这两种 Feed 方法具有能对 Feed 进行预先呈现或缓存的优势。因此对 Feed 的请求并不一定会引发对 Content Manager 数据库的请求。可以在初始开发之后添加这些优化，还可以使用传统 Web Servlet 缓存，因为 Feed 实际就是一个通过 HTTP 访问的 XML 文档。图 4 显示了 Feed 生成器、资源集合和潜在 Web 服务器或代理缓存间的关系。
Personalization 资源集合仅将 Feed 中的数据向 Web Content Management 公开。因此，为了处理 Web Content Management 表示标记中的一些属性，必须将其包含在 Feed 中（使用标准属性或扩展属性）。需要对 Feed 的生成进行一定的考虑，以确保会进行此操作。
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。