XX项目-基于liferay+icefaces的总结

这个项目是公司的二次开发项目，属于portlet的开发。

 

1.JSR168标准

 

 

Portal 的组成可以分为三部份 (1) Portal Server (2) Portlet Container (3) Portlet

 

1)  Portal Server 的定义是

 

 一个 Portal（门户网站）就是指一个 Web-based 的系统，通常都会提供个人化设置、单一登陆、以及由各种不同来源或不同网站取得各式各样的信息，并且将这些信息放在网页之中组合而成的呈现平台，门户网站会有精巧的个人化设置去提供定制的网页，当不同等级的使用者来浏览该页面将获得不同的信息内容。

 

2) Portlet Container 的定义是

 

 

portlet container 是提供 portlets 执行的环境，包含了许多 portlets 并且管理他们的生命周期，他也会永远保存着 portlets 的喜好设置，一个 portlet container 接收到来自 portal 的请求后，接着将这个请求传递给存在 container 的 portlet 执行。portlet container 没有义务去组合 portlets 产生的信息內容，这个工作必须由 portal 来处理。portal 和 portlet container 可以放在一起视为同一个系统的组件，或者分开成为两个独立的组件。

 

3）Portlet 的定义是

 

一个 Portlet 是以 Java 技术为技术的 Web 组件，由 Portlet Container 所管理，专门处理客户的 request 以及产生各种动态的信息内容。Portlets 为可插式 ( pluggable ) 的客户界面组件，提供呈现层成为一个信息系统。

 

2.liferay

简介

 

项目之前使用的是liferay5.2的版本，在我们接手时已经出现了liferay6所以我们进行了一次升级，升级过程相对比较容易，没有出现什么巨大的不兼容，唯一不能兼容的就是主题。

 

在liferay6中的dockbar已经变成了以个portlet，所以与之前的主题肯定存在冲突，但是由于PM觉得这个问题不是很严重，所以开发过程中我们采用了默认的主题。

 

liferay就是JSR168中的portal server及porlet container。

 

安装，使用

原来liferay是glassfish作为应用服务器的，后来我们发现用不惯netbeans（当初认为无法DEBUG），在升级为liferay6时，同时将开发环境换为了eclipse，但是换为eclipse的代价也还是很高的，因为NetBeans得项目文件结构eclipse是无法识别的，所以在下载了liferay的eclipse SDK后还要采用虚拟文件映射的方式（为此我们还专门做了一个视频）

 

以下为liferay5.2在NetBeans中的添加方法：

 

当初给我们的是：liferay-portal-glassfish-windows-5.2.3.jar这个jar文件

 

1.先用java -jar -Xmx512M liferay-portal-glassfish-windows-5.2.3.jar 进行解包

2.然后进入glassfish目录，执行 ant -f setup.xml进行build

3.然后进入NetBeans，安装portalpack_3_0_3_all和iceface的NetBeans plugin（注意必须使用NetBeans6.8，应为在使用NetBeans6.9时，某个插件无法安装）

4.进入glassfish\bin目录，在cmd中运行asadmin start-domain（必须先运行一遍，否则NetBeans无法识别autodeploy的目录）

5.进入NetBeans，添加一个liferay的服务器，应该不会有什么问题。

 

至于liferay的6的eclipse相对比较容易，因为下载来的是tomcat-bundle及eclipse的sdk这里就不累赘了。

 

3.icefaces

这次开发的系统是一个portlet，而且是二次开发，发现最主要的是使用icefaces这个组件。

 

那么icefaces是什么呢？

 

在我看来，icefaces是一个表现层的组件，他扩展了JSF，最大的特点就是"Direct-to-DOM Rendering"

 

 

ICEfaces® is the industry’s first standards-compliant AJAX-based solution for rapidly creating

pure-Java rich web applications that are easily maintained, extended, and scaled, at very low cost.

 

 

 写道

The major elements of the ICEfaces architecture include:
• Persistent Faces Servlet: URLs with the “.iface” extension are mapped to the Persistent Faces
Servlet. When an initial page request into the application is made, the Persistent Faces Servlet is
responsible for executing the JSF lifecycle for the associated request.
• Blocking Servlet: Responsible for managing all blocking and non-blocking requests after initial
page rendering.
• D2D ViewHandler: Responsible for establishing the Direct-to-DOM rendering environment,
including initialization of the DOM Response Writer. The ViewHandler also invokes the Parser for
initial page parsing into a JSF component tree.
• D2D Parser: Responsible for assembling a component tree from a JSP Document. The Parser
executes the JSP tag processing lifecycle in order to create the tree, but does this once only for
each page. The standard JSP compilation and parsing process is not supported under ICEfaces.
• D2D RenderKit: Responsible for rendering a component tree into the DOM via the DOM Response
Writer during a standard JSF render pass.
• DOM Response Writer: Responsible for writing into the DOM. Also initiates DOM serialization for
first rendering, and unblocks the DOM Updater for incremental DOM updates.
• DOM Serializer: Responsible for serializing the DOM for initial page response.
• DOM Updater: Responsible for assembling DOM mutations into a single incremental DOM update.
Updater blocks on incremental DOM update requests until render pass is complete, and DOM
Response Writer performs an unblock.
• Component Suite: Provides a comprehensive set of rich JSF components that leverage AJAX
features of the bridge and provide the basic building blocks for ICEfaces applications.
• Client-side AJAX Bridge: Responsible for ongoing DOM update request generation and response
processing. Also responsible for focus management and submit processing.

 

 icefaces的特性还是很多，直观的来说，就是感觉服务器与客户端（浏览器）是实时双向通信的（注意blocking Servelet，这个是主要实现底层原理）

 

配置文件说明

faces-config：jsf的manager-bean配置文件，用于将managerbean的名称与具体的实现类绑定

liferay-display：在liferay页面中有添加新的应用，我们的portlet就是从这里添加进来的，这个文件就是“目录”

liferay-portlet：这个就是具体的portlet，我们开发的portlet的名称列表就在这里面，其中某些字段需要符合icefaces的要求

portlet：如果说liferay-portlet是列表，那么这个文件就是对每个portlet的具体内容了

 

<portlet>
        <description>ProgramList</description>
        <portlet-name>ProgramList</portlet-name>
        <display-name>ProgramList</display-name>
        <portlet-class>com.icesoft.faces.webapp.http.portlet.MainPortlet</portlet-class>
        <init-param>
            <name>com.icesoft.faces.portlet.viewPageURL</name>
            <value>/page/trainning/programListFace.iface</value>
        </init-param>
        <expiration-cache>0</expiration-cache>
        <supports>
            <mime-type>text/html</mime-type>
            <portlet-mode>VIEW</portlet-mode>
        </supports>
        <portlet-info>
            <title>Program List</title>
            <short-title>Program List</short-title>
        </portlet-info>
    </portlet>

 

 

剩下就是具体的iceface页面+manager-bean的开发了。

 

项目特点

这个项目的特点很明显，比如有两个portlet，一个是用户列表（A），另一个是用户的具体信息（B）。

 

需求：点击用户列表中的某一用户后，用户具体信息的portlet能够同步显示该用户的信息。

 

分析：这个如果抛开什么portlet，icefaces，想到的就是ajax。但是如果是在portlet中开发，就其实麻烦了很多。

 

首先A portlet点击后需要得到选中用户的识别，然后要有种机制能够在服务端“主动”刷新B，由于http协议本身是被动的，所以这里就用到了blocking servlet技术（类似于长寻回吧long polling）

 

而这些需求icefaces就能够原生的提供（icefaces增加了一个portlet session级别的作用域，可以给icefaces的应用共享，这样就提供了不同icefaces portlet的信息交换的底层）

 

问题

最大的问题就是performance了，而且我存在很多困惑。

 

1.项目数据源层使用的JPA，toplink作为实现（由于对hibernate比较熟，toplink实在不熟），所以对于其缓存原理不是很清楚

2.测试发现由于使用icefaces，每次操作（比如鼠标点击）就会产生很多次的数据库查询，由于这是icefaces的机制，所以不清楚是否可以优化（除非禁止或者换掉体验）

 

3.尝试在业务层中自己实现了一层cache发现效果挺好的（当然有很多副作用，主要在同步性发面），但是实在不明白为什么JPA的缓存似乎没有起什么作用

 

===============================================

 

先总结到这里，有跟进再更新吧