卓越的用户体验：IBM WebSphere Portal 中的 Web 2.0 主题与皮肤定制开发介绍

核心提示：传统门户页面聚合方式介绍Portal 的技术就是以松耦合的方式将 portlet 应用程序有机的聚合起来形成一个站点，其中，卓越的用户体验：IBM WebSphere Portal 中的 Web 2.0 主题与皮肤定制开发介绍，页面的聚合是最重要的平台能力之一，页面是 Portlet 应用呈现的容器，在门户项目中，适当

传统门户页面聚合方式介绍

Portal 的技术就是以松耦合的方式将 portlet 应用程序有机的聚合起来形成一个站点。其中，页面的聚合是最重要的平台能力之一。页面是 Portlet 应用呈现的容器。基于内容与展现分离的原则，可以理解为：portlet 是门户的内容，而主题皮肤则是展现。如图 1 所示。

图 1. 门户页面聚合

在 6.1 以前的 WebSphere Portal 版本中，只存在有一种的页面聚合方式：服务器端聚合（SSA）。这种聚合方式的原理是在服务器端将 portlet 的内容在服务器端完成编译后使用皮肤将这些内容有顺的加入到主题的页面中形成一个更大的 JSP 文件！这一文件在服务器端完成转换后（HTML），便会以应答的方式返回给客户端。

门户 Web 2.0 主题与皮肤框架介绍

客户端聚合（CSA）是在新版本门户（6.1.x）中呈现页面的一种新方式。它结合服务器端内容及客户端代码（javascript）的办法，将门户页面的各种内容：导航、工具栏、portlet 内容、菜单等以 REST 服务的接口向客户端代码开放。客户端使用新版本中内置的 javascript 引擎（基于 dojo 实现）加载页面各个部分的内容。利用 DOM 的方式将从 REST 取回来的内容填充到页面相应的位置上。当用户对页面进行操作，会激发这个引擎的事件处理机制。引擎继而定位要更新的页面部分，向服务器提出 REST 请求，再将返回的内容更新对应的部分。使得用户浏览门户页面的整体体验有了大幅提升。

图 2. CSA 架构

查看原图（大图）

如图 2 所示，CSA 框架是基于页面的 DOM 对呈现的元素进行控制。框架在页面下载的第一次进行初始化，将页面的元素定位及相应的事件注册完毕。CSA 负责与服务器端的 REST 服务 Servlet (Remote Model API) 通信。服务器端返回 ATOM (application/atom+xml) 格式的模型 Feeds。其中 portlet 间通信一类的交互将由 Portal Servlet 进行处理。整个架构包含有 2 个缓存，一个是客户端浏览器的缓存，一个是服务器端的中间缓存。对于 JS、CSS 一类的静态文件，相当程度是依赖于客户端浏览器提供的缓存机制提高其性能。服务器端的缓存则用于处理重复类型的请求，如导航、菜单等。

图 3. CSA 加载过程

客户端聚合的页面结构与原来的服务器端聚合方式非常相似，如图 3 所示，仍然以 Default.jsp 为入口，包括有 head.jspf、banner.jspf、topnav.jspf、sidenav.jspf 等主要的主题文件。但与服务器端聚合所不同的是，这些 jsp 代码的表段只会呈现一个具有占位符的页面框架。当这个页面框架加载完成以后，CSA 将会在页面 onload 的事件时被加载。CSA 继而向服务器请求每个页面元素的内容。这些内容是以 ATOM 的形式返回给 CSA，本地的 JS 代码则利用 XSLT 的方式将 Feed 转换成 HTML 片段并注册相应的 UI 事件。所有的 UI 事件又会重新触发 CSA 的处理。表 1 说明了服务器端方式与客户端方式使用文件的一个对比：

表 1. 2 种聚合方式对比

	服务器端聚合	客户端聚合
顶导航	topNav.jspf	xsl/topNavRender.xsl
侧导航	sideNav.jspf	xsl/sideNavRender.xsl
页面布局	Home.jsp /UnlayeredContainer*.jsp	xsl/mainContentRenderLayout.xsl
皮肤	Control.jsp	xsl/IBM.xsl, xsl/NoSkin.xsl

Web 2.0 主题与皮肤定制与开发

6.1.x 版本的 WebSphere Portal 产品会附带有一个基本的 Web 2.0 主题。这个主题会存放在 PortalWeb2 目录下面。最佳实践是复制这一目录并更名为自己的主题，在这个基础上进行定制与开发。通常情况下，需要考虑的定制元素包括有：页面的样式表单、企业的 logo、页尾、导航以及各 portlet 的皮肤。这些元素的定制方式各有不同，在下面的小节里会详细讨论。本文将对一个开源的页面设计为例对原有的主题皮肤进行定制。

这里，先来分析一下页面中主题皮肤的基本组成，如图 4 所示。对于大多数的门户项目，需要定制的部分包括有 banner 区域、顶导航、皮肤及页尾。我们的定制工作就是需要将出厂时开箱即用的这个主题皮肤模板定制化成为项目中客户所要求的样式，如图 5 所示。

图 4. 门户页面元素

查看原图（大图）

图 5. 主题皮肤定制目标

利用主题定制程序进行快速的主题修改

6.1.x 版本的 WebSphere Portal 产品中新增了一个主题定制程序的工具 portlet 供用户使用。该工具可以快速的对原厂主题进行一定程度的定制。其主要原理是新增或者修改主题策略以控制一个主题下不同的显示效果。如图 6 所示，这一工具允许开发人员或者业务人员对主题策略进行定制，其主要的功能有以下：

改变 banner：logo，颜色，排版，边缘线，背景；

改变排版布局：默认尺寸，颜色，颜色，标题尺寸，颜色和样式；

改变导航：导航方向，tab 页颜色（选中/未选），tab 页文本（选中/未选）；

改变颜色：页面颜色或者背景，高亮颜色；

改变按钮：文本，颜色，选中和未选状态。

图 6. 主题定制程序

查看原图（大图）

通过修改页面内容的选项，可以将页面上出厂时带有的元素简化。在许多门户的项目中，用户界面中并没有对 portlet 链接、人员链接等这些功能 UI 的需求。所以我们只需要利用新版本中自带的定制程序生成一个新的主题策略，即可以快速简化页面上的部件。如图 7 所示的例子则使这些额外的内容都不输出。

图 7. 定制页面元素


图 8. 选择主题策略

如图 8 所示，编辑页面的属性，选择对应的主题样式（主题策略）。

图 9. 精简元素后的门户页面

查看原图（大图）

如图 9 所示，返回页面则可以看到页面上的内容已经得到的精简。

主题元素的定制

这些需要定制的元素各有不相同的定制方式，因此，我们需要有一定的顺序进行主题的定制任务。一般，我们会从 web 设计人员或者美工手上获得相应的样式文件。这些文件应该包括有 css 文件、图片、js 文件（如果需要使用）、一个 html 的版面。以本文使用的样式为例，如图 10 所示使用 firefox 和 firebug 打开该 html，可以看到页面的结构。

图 10. 使用 Firebug 查看页面结构

查看原图（大图）

我们的定制任务就是要将样式中的页面结构在门户的主题及皮肤中还原。如图 11 所示，可以理解为是结合美工的设计与门户的主题框架进行的一次页面元素映射。

图 11. 页面元素映射

查看原图（大图）

对于这些元素的修改，包括有以下 4 个步骤：

引入 CSS 与 JS：

styles.jsp 中加入对应的 CSS 文件：

<%@　include　file="./css/style.css"　%>　
<%@　include　file="./css/ie7.css"　%>　

此样式中并没带有 JS 资源。如果使用的设计有需要，则需要在 js.jsp 文件中类似于：

<%@　include　file="js/Utilities.js"　%>　

这样的格式引入。

页头位置是在顶导航的上方，从 Default.jsp 文件中可以找到：<div id="wptheme-topnav"> 这一个层。在此层的上方，可以加入自己的 HTML 代码，如：

<div　id="container">　
<div　id="header">　
<img　src="http://tech.ddvip.com/wps/img/header_image.jpg"　/>　
<div　id="header_image">　
<p　style="font-size:12px;　padding:1px;">Support:</p>　
<p　class="ots1">Email:<a　class="ots1"　href="#">support@test.com</a></p>　
<p　class="ots1">Phone:　+12　345-67-89</p>　
<p　class="ots1">Mobile:　+12　987-65-43</p>　
</div>　
</div>　
<div　id="wptheme-topnav">　

页尾通常是放置一些版权及维护信息，可以在 Default.jsp 文件中找到：

<%@　include　file="./footer.jspf"　%>　

将其替换成自己的页尾。页面片段如下：

<%--　end　pageArea　div　--%>　
<portal-logic:if　portletSolo="no">　
<div　id="footer">　
　　<div　id="nav3">　
　　　　<ul>　
　　　　　　<li><a　href="#">ABOUT　COMPANY</a></li>　
　　　　　　<li><a　href="#">SOLUTIONS</a></li>　
　　　　　　<li><a　href="#">CONTACT　INFORMATION</a></li>　
　　　　</ul>　
　　<div　id="copyright">　
　　Design　by:<a　href="http://www.test.com/">free　web　templates</a>and　partners:　
　　<a　href="http://www.test.com/">web　hosting</a></div>　
　　</div>　
</div>　
</portal-logic:if></td></tr></table>　

如果页头或者页尾部分的代码较多不利于在同一页面中维护，则可以另外建立一个 jspf 的文件，使用引入的方式放置到相同的位置即可。

顶导航。在 Web 2.0 主题中，顶导航是由 xslt 完成呈现转换的。只需要修改对应的 xsl 文件即可。对于当前例子，找到 xsl 目录下的 topNavRender.xsl 文件。首先是要将顶导航原有的样式删除，找到如下代码并删除：

<xsl:if　test="not(string($topNavFirstRow))">　
　　<xsl:attribute　name="class">wpsPageBar</xsl:attribute>　
</xsl:if>　
<xsl:if　test="string($topNavFirstRow)">　
　　<xsl:attribute　name="class">wpsPageBarFirstRow</xsl:attribute>　
</xsl:if>　

检查第个节目的输出 HTML 代码是否与设计一致：

<xsl:template　match="atom:entry">　
　　<xsl:variable　name="renderMode"　
　　select="./atom:content/*/model:metadata[@name='RenderMode']/base:value/@value"/>　
　　<li>　
　　　　<xsl:attribute　name="id"><xsl:value-of　select="atom:id"　/></xsl:attribute>　
　　　　<xsl:attribute　name="menuLink">　
　　　　　　<xsl:value-of　select="atom:link[@portal:rel='contextMenu']/@href"　/>　
　　　　</xsl:attribute>　
　　　　<a>　
　　　　　　<xsl:attribute　name="href">　
　　　　　　　　javascript:com.ibm.portal.navigation　
　　　　　　　　.controller.NAVIGATION_CONTROLLER.setSelection(　
　　　　　　　　'<xsl:value-of　select="atom:id"　/>',　null,　null,　
　　　　　　　　'<xsl:value-of　select="$renderMode"　/>');　
　　　　　　</xsl:attribute>　　　
　　　　　　<xsl:value-of　select="atom:title"/>　
　　　　</a>　
　　</li>　
</xsl:template>　

需要使用设计的层对导航进行包含，通过 id 引用 CSS 定义的样式：

<div　id="menu"><div　id="wptheme-topnav">　……　</div></div>　

到这一步为止，如图 12 所示，就生成了一个基本的主题框架还原美工的设计。（注：在这里，导航的样式没有完全还原，本文只在框架上定制的展现。具体项目中需要美工的帮助调整样式设计）

图 12. 还原基本设计的页面

查看原图（大图）

皮肤的开发

上文已经讨论过 CSA 与 SSA 方式中文件的差异。对于皮肤而言，这种差异更为明显。在 SSA 方式下，皮肤均以 Control.jsp 方式存在并独立于主题的文件目录。在 CSA 的方式下，皮肤是以 XSL 文件存放在主题的目录下：<PROFILE_HOME>/installedApps/<NODE>/wps.ear/wps.war/themes/html/PortalWeb2/xsl。其文件名即为皮肤的名称。同时，皮肤的控制是由对应的 JS 完成的，这个 JS 是存放在固定的目录下面：<PROFILE_HOME>/installedApps/<NODE>/wps.ear/wps.war
/themes/dojo/portal_dojo/com/ibm/portal/aggregation。

需要定制新的皮肤，需要做 2 步：

创建皮肤使用的 JS。在 <PROFILE_HOME>\installedApps\wpsbvt\wps.ear\wps.war\themes\html\MyTheme\js 目录下创建自己命名的 JS 文件，如 myskin.js。将 <PROFILE_HOME>\installedApps\wpsbvt\wps.ear\wps.war\themes \dojo\portal_dojo\com\ibm\portal\aggregation\skin.js 文件中 com.ibm.portal.aggregation.IbmSkin 和 com.ibm.portal.aggregation.IbmSkinUIState 对象均拷贝到之前创建的 JS 文件中并将文件中所有 IbmSkin 替换为新的 skin 的名字如：MySkin。在 head_extras.jspf 文件中引入这个 JS：<script type="text/javascript" src='<portal-logic:urlFindInTheme file="./js/MySkin.js"/>'></script>。 并在同一个文件中找到 portalAggregator.page.addSkin(new com.ibm.portal.aggregation.IbmSkin("IBM",skinResourceRoot2Id["IBM"],"<portal-logic:urlFindInTheme file="xsl/IBM.xsl" />"),true); 在这段代码的后面加入一个自己的皮肤定义：portalAggregator.page.addSkin(new com.ibm.portal.aggregation.MySkin("MySkin",skinResourceRoot2Id["MySkin"],"<portal-logic:urlFindInTheme file="xsl/MySkin.xsl" />"),false);。从实际操作来看，也可以直接使用原厂提供的 JS 对象，则只需要在 head_extras.jspf 中如上位置加入一行：portalAggregator.page.addSkin(new com.ibm.portal.aggregation.Skin("MySkin",skinResourceRoot2Id["MySkin"],"<portal-logic:urlFindInTheme file="xsl/MySkin.xsl" />"),false); 此处使用的是不带有上下文菜单或者拖拽功能的 JS 对象。

皮肤 xslt 的定义。在本例子中，皮肤并没有需要使用到上下文的菜单或者拖拽的功能。因此，可以例用 NoSkin.xsl 为模板。定制化后主要的代码如下：

<!--　Control　-->　
<xsl:template　match="　
atom:entry[atom:content[model:layout-control[model:templateName='Control']]]"　>　
　　<img　src="http://tech.ddvip.com/wps/img/head.jpg"　class="img1"/>　
　　<h1　class="h1"><xsl:value-of　select="atom:title"/></h1>　
　　<div　class="wpsPortletBody">　
　　　　<xsl:attribute　name="id"><xsl:value-of　select="atom:id"/></xsl:attribute>　
　　</div>　
</xsl:template>　

需要将对应的图片及标题引入。即可以得到对应的效果，如图 13 所示。完整的主题与皮肤例子可以在文章最后的链接中找到下载。

图 13. 修改皮肤后效果

查看原图（大图）

部署架构

图 14. 门户部署结构

如图 14 所示，一般的门户部署（单机或者集群）会使用 3 层的架构。第一层是 web 服务器；第二层是门户服务器；第三层则是用户目录与数据库。

那么从用户访问的路线来看，最佳实践告诉我们可以把一些静态的文件，如大的图片、Flash、样式表、JS 文件等存放在第一层的 web 服务器上。因为很多企业的门户部署都会考虑到内外网的使用，而 web 服务器在通常情况下会被安装到 DMZ。而门户服务器则会被安装在内网。所以用户的请求最先到达的是 web 服务器。如果将一些大的静态文件放在 web 服务器上，它与门户服务器的数据量交换将会减少，从 I/O 的角度看，则可以提高门户服务器对业务的处理能力。本文例子中，则是在 wps.war 的文件目录下创建了对应于 CSS 文件中引用的图片存储目录，以作为示例。

主题皮肤作为一个框架是需要在门户服务器这一层运行的。框架里面有相当部分的内容是 jsp 的程序片段，这些片段都是必须在运行时获取到门户的上下文件进行呈现的。一个灵活的做法是将主题皮肤与样式进行分离。主题皮肤作为一个框架可以一次性完成。而页面的风格是可以在门户项目的发展过程当中随需而变的。其中设计的元素就是 css 的样式表单文件及其引用的相关资源，如图片、flash 等。这些文件均名要存放到 web 服务器一层，在切换主题皮肤时，只是需要改变对这些文件的引用路径，即可以不修改任何的代码实现门户页面风格的更替。

最佳实践

CSA 的聚合模式主要依赖于内置的 JS 引擎，在浏览器的支持方面需要开发人员及使用者注意。利用 CSA 的方式，在性能上可以得到一个良好的提升。但是，并不是所有的 portlet 都能够支持 CSA 的。例如 LWCM 本地呈现 portlet 就是其中的一个。当我们考虑到某一页面不适合使用这一种聚合方式的时候，可以通过设置页面的元数据添加 com.ibm.wps.web2.renderMode 的参数实现对页面一级的控制。同时，也可以将某些不支持 CSA 的 portlet 加入一个“黑名单”。有一些正常的浏览体验在 CSA 的方式下可能会遇到问题，如“后退”及“刷新”功能。在 CSA 方式下，“后退”只能发生在整个页面的重新刷新。而页面的“刷新”未必能把所有的状态清除，相当多的页面状态还是以 JS 及缓存的方式存放在了本地。这些都是开发人员需要在确定用户需求的时候要注意到的。对比 CSA 及 SSA 这两种聚合的方式，并不是所有的场景都适合使用 CSA。当页面上存在呈现速度差异较大的 portlet 时，使用 CSA 会显示出它的明显优势。而当页面上的 portlet 速度较快而且数量不太多时，使用 SSA 在用户体验上也可以得到良好的体现。在门户项目中，适当的选择使用 Web 2.0 的主题皮肤可以很好的提高门户的用户体验，得到用户的认可。