一种门户布局渲染方法与流程

技术领域

本发明涉及门户布局渲染技术领域，具体地，涉及一种门户布局渲染方法。

背景技术：

在企业中，一般有很多的应用系统为其提供管理和IT服务，随着企业的成长和信息的技术的发展，会有更多的系统加入。为方便用户使用这些系统企业一般会提供一个统一的入口服务—门户系统， 用户可以在门户布局中操作各业务系统的数据如：单据、消息、审批任务等，门户布局的渲染性能直接影响着用户的操控感受，尤其是大量的css 文件和js 文件需要加载，传统的页面加载模型很难满足用户满意度的需求，直接结果就是页面加载速度变慢，海量数据下布局某块区域执行复杂业务查询时页面响应速度会进一步下降。

为了解决企业级布局渲染的性能问题，一般采用前后端结合改进的方式，这种方式前端主要进行：资源文件压缩(对css和js文件进行G-zip)、css和js合并、前端缓存（LocalStorage），后端改进：优化业务代码、增加后端缓存等。这些方式虽然可以对布局的渲染性能有所提升，但其工作模式也使浏览器和服务端有一定闲置等待时间，且对已有旧系统的代码改造实施比较困难。

这种模式的缺陷：

1．流程中的操作有着严格的顺序：如果前面的一个操作没有执行结束，后面的操作就不能执行，即操作之间是不能重叠。

2.造成性能的瓶颈：服务器生成一个页面的内容时，浏览器是空闲的，显示空白内容；而当浏览器加载渲染页面内容时，服务器又是空闲的，时间与性能的浪费由此产生。

CN200710002299.4解决了有关门户视图呈现不足，响应时间不理想的问题。但使用了响应时间监视器耦合到门户服务器、响应时间补救处理器等复杂的实现机制，不宜实施且运维成本高。

CN200510081392.X通过一种高级的高速缓存组件来缓存动态门户页面减少了门户页面访问时间，但使用的页面渲染仍是传统的处理流程，效率不高。

技术实现要素：

本发明的目的在于，针对上述问题，提出一种门户布局渲染方法，以实现不仅能够不破坏和修改原来应用系统的代码，快速方便的实施，还可以明显提升用户操作页面满意度的优点。

为实现上述目的，本发明采用的技术方案是：一种门户布局渲染方法，主要包括：

步骤1：初始化，声明Channel，包括声明Channel的名称，BigpipeServlet的URL和是否跨域；

步骤2：为pipeURL注册一个Handler；

步骤3：开启Channel，包括开始为每个Chanel创建一个form和iFrame.form中的一个隐藏域jobs，将pipeURL地址转为json后，设置到jobs上，并POST到服务器端地址；

步骤4：在服务器端BigpipeServlet接收到请求的Job列表，根据Job信息进行pipeURL的forward，处理完成后以PostMessage形式将数据传递到父页面的onBlockReady，onBlockReady查找Handler进行回调；

步骤5：检查Channel的所有的Job是否已经结束，结束时标记Chanel已经关闭，销毁这个Chanel已经创建的Form和iFrame。

进一步地，所述步骤1还包括声明pipeURL。

进一步地，步骤4中根据Job信息进行pipeURL的forward，所述Job信息包括是否异步信息、优先级信息和缓存的eTag信息。

进一步地，若Job信息携带eTag信息，pipeURL的后端将收到If-None-Match，如果pipeURL返回了步骤4中的请求状态，则浏览器端将使用LocalStorage中的缓存来回调Handler。

进一步地，若步骤1中，Chanel跨域请求时先向宿主服务器发送请求，宿主服务器根据秘钥、时间戳和用户名加密出一个token，输出一个form，然后提交这个form到Chanel上；Chanel上的BigpipeServlet校验这个token，校验通过后调用注册的上下文处理Invocation RestoreHandler生成上下文；前端采用PostMessage方式进行处理；

所述宿主服务器中包括一个跨域Chanel列表，只有在这个列表中的才生成Form。

进一步地，步骤3之前中还包括对意外流程的处理，如果注册Handler的时候Channel已经关闭，若pipeURL已经声明过，从Channel中获取数据并且传递给Handler 如果没有声明过该URL，重新创建一个channel来处理；

如果注册Handler的时候Channel已经开启，若Channel开启前没有declare过该pipeURL，channel结束后重新创建一个channel来处理。

本发明各实施例的一种门户布局渲染方法，由于主要包括：首先client组件为布局中的每个pipeURL建立channel通道，向服务端发起请求，在服务端server组件会为每一个pipeURL设定一个job(包含优先级、etag等信息)，根据job信息进行pipeURL的forward，处理完成后以PostMessage形式到客户端client组件，client组件负责回调handler，当所有channel的job结束时关闭channel完成页面渲染；从而可以克服现有技术中工作模式也使浏览器和服务端有一定闲置等待时间，且对已有旧系统的代码改造实施比较困难的缺陷。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为本发明实施例所述的门户布局渲染方法原理图；

图2为本发明实施例所述的门户布局渲染方法流程图；

图3为本发明实施例所述的门户布局渲染方法中描述的跨域处理原理图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

具体地，一种门户布局渲染方法，主要包括：

步骤1：初始化，声明Channel，包括声明Channel的名称，BigpipeServlet的URL和是否跨域；

步骤2：为pipeURL注册一个Handler；

步骤3：开启Channel，包括开始为每个Chanel创建一个form和iFrame.form中的一个隐藏域jobs，将pipeURL地址转为json后，设置到jobs上，并POST到服务器端地址；

步骤4：在服务器端BigpipeServlet接收到请求的Job列表，根据Job信息进行pipeURL的forward，处理完成后以PostMessage形式将数据传递到父页面的onBlockReady，onBlockReady查找Handler进行回调；

步骤5：检查Channel的所有的Job是否已经结束，结束时标记Chanel已经关闭，销毁这个Chanel已经创建的Form和iFrame。

所述步骤1还包括声明pipeURL。

步骤4中根据Job信息进行pipeURL的forward，所述Job信息包括是否异步信息、优先级信息和缓存的eTag信息。

若Job信息携带eTag信息，pipeURL的后端将收到If-None-Match，如果pipeURL返回了步骤4中的请求状态，则浏览器端将使用LocalStorage中的缓存来回调Handler。

若步骤1中，Chanel跨域请求时先向宿主服务器发送请求，宿主服务器根据秘钥、时间戳和用户名加密出一个token，输出一个form，然后提交这个form到Chanel上；Chanel上的BigpipeServlet校验这个token，校验通过后调用注册的上下文处理Invocation RestoreHandler生成上下文；前端采用PostMessage方式进行处理；

所述宿主服务器中包括一个跨域Chanel列表，只有在这个列表中的才生成Form。

步骤3之前中还包括对意外流程的处理，如果注册Handler的时候Channel已经关闭，若pipeURL已经声明过，从Channel中获取数据并且传递给Handler 如果没有声明过该URL，重新创建一个channel来处理；

如果注册Handler的时候Channel已经开启，若Channel开启前没有declare过该pipeURL，channel结束后重新创建一个channel来处理。

形态和概念

1、形态

bigpipe-server组件以jar的形式提供给第三方

bigpipe-client 组件提供bp.js的浏览器客户端.

2、 概念

通道（Channel）channel规定了当前属于哪一个频道(大约对应应用服务器中的context). 比如/hr , /portal 或者http://www.nccloud.com/ipu因为要做服务器端forward.所以需要每个context中配置一下bigpipe的server端

URL（pipeURL）pipeURL是一个提供数据的特殊的网络地址，相对于普通的URL, pipeURL有以下不同：

1）仅支持GET方式

2）URL必须以channel开头.如果URL不能与任意一个channel开头匹配,将会被忽略,如果有多个匹配,取最大的匹配

3）返回结果必须是一个JSON.编码为UTF-8.仅支持Etag/If-None-Match头.其他缓存头将被忽略.

4）如果需要异步请求,需要在URL后面加入一个参数_bp_async_=1 ,如

5）如果需要调整执行的优先级,需要在URL后加入一个参数_bp_order_=0.参数值越高优先级越高

处理器（Handler）handler是客户端注册的处理数据的方法.由bigpipe回调.只有一个参数:data

任务（Job）服务器端会为每个pipeURL设定一个Job .这个Job中包含了pipeURL执行的优先级,是否同步执行.缓存的eTag信息. BigpipeServlet依据这些信息处理每个pipeURL。

结合图1，在WEB开发中，HTTP/1.1 支持的chunked编码，可以由浏览器接收到服务器发送的chunked块后，立即解析该块代码。因为chunked编码使消息主体成块发送，每块有自己的大小指示器，在所有的块之后会紧接着一个可选的包含实体头域的尾部。这种编码充许发送端能动态生成内容，并能携带能让接收端判断消息是否接收完整的有用信息

本发明采用“bigpipe-client” + “bigpipe-server”组件结合的方式提高布局的渲染效率。首先client组件为布局中的每个pipeURL建立channel通道，向服务端发起请求，在服务端server组件会为每一个pipeURL设定一个job(包含优先级、etag等信息)，根据job信息进行pipeURL的forward，处理完成后以PostMessage形式到客户端client组件，client组件负责回调handler，当所有channel的job结束时关闭channel完成页面渲染。

结合图2，主要过程如下：

下面是本方案的处理流程。

1.初始化:声明Channel，包括Channel的名称，BigpipeServlet的URL，是否跨域

2.初始化-预先声明: declare一下pipeURL(这个是,不是必须的.)

3.为pipeURL注册一个Handler

4.开启Channel: 开始为每个Chanel创建一个form和iFrame.form中一个隐藏域jobs，将pipeURL地址转json后，设置到jobs上.POST到服务器端地址。

5.在服务器端BigpipeServlet接收到请求的Job列表，根据Job信息(是否异步,优先级)进行pipeURL的forward，处理完成后以PostMessage形式将data传递到父页面的onBlockReady方法，onBlockReady查找Handler进行回调。

检查Channel的所有的Job是否已经结束，结束时标记Chanel已经关闭.销毁这个Chanel已经创建的Form和iFrame。

缓存、跨域、意外流程的处理是本方案的主要步骤，下面详细介绍这三个方面。

缓存

如果pipeURL的输出头中声明了eTag,那么这个请求将被onBlockReady方法存储在localStorage中.在bigPipe处理的时候将会在Job信息中携带eTag信息，pipeURL的后端将收到If-None-Match，如果pipeURL返回了304的请求状态,那么浏览器端将使用LocalStorage中的缓存来回调Handler。

缓存的一些问题:

1） 支持且仅支持http协议中的eTag.其他的缓存指令忽略(以不缓存处理)

2） 如果输出了eTag,在客户端将以用户-pipeURL-etag做key,将输出内容存储在localStorage中.这样不同的用户被隔离开，但是潜在的风险是这些信息存储在浏览器端,所以不要将敏感信息设置为缓存。

结合图3，在处理跨域的时候.需要向对方服务器端传送一个token信息，传送过程如下:

1.Chanel跨域请求时先向宿主服务器发送请求,宿主服务器根据秘钥 ,时间戳,用户名加密出一个token.输出一个form.然后提交这个form到Chanel上.

2.宿主机中包括一个跨域Chanel列表.只有在这个列表中的才生成Form

3.Chanel上的BigpipeServlet校验这个token,校验通过后调用注册的上下文处理InvocationRestoreHandler生成上下文.

4.前端处理的时候使用PostMessage方式.。

意外流程的处理：

1、注册Handler的时候Channel已经关闭

如果pipeURL已经declare过.从Channel中获取数据并且传递给Handler 如果没有declare过该URL,重新创建一个channel来处理

2、注册Handler的时候Channel已经开启

如果Channel开启前没有declare过该pipeURL,等等channel结束重新创建一个channel来处理(连接数限制)

至少可以达到以下有益效果：这种方案能够不仅能够不破坏和修改原来应用系统的代码，快速方便的实施，还可以明显提升用户操作页面满意度。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。