JSR168 Portlet related

最新推荐文章于 2020-07-09 00:53:57 发布

原创最新推荐文章于 2020-07-09 00:53:57 发布 · 348 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#portlet #processing #action #parameters #application #browser

portal 专栏收录该内容

16 篇文章

订阅专栏

本文深入探讨了PortletRequest的概念及其在Portlet容器中的作用，解释了RenderParameters的功能，以及如何通过JSFBridge解决Faces应用中请求范围不一致的问题。

1. portlet request divide into action request and render request

Render parameters allow the portlet to store its navigational state.
Render parameters stay the same for subsequent render requests and only change when the portlet receives a new action. This enables bookmarkability and solves the browser back button problem.

2. portlet request: a call from from the client (portal server) to process some information or render some markup. A portlet request is received and managed by a portlet container. The portlet container executes the targeted portlet to process the request. There are two things that distinguish portlet requests from typical http (web requests): the client sending the portlet request is a portal application not an end user (browser) and multiple (two) requests are sent to submit data and render a markup response.

3. portlet request scope: the duration of a request processed by the portlet container. Because portlets separate action processing and rendering in two distinct requests, client state stored in the request scope does not carry forward from a portlet's action to its render.

4. JSF Bridge

As Faces executes in the context of an underlying container its request scope is restricted by that provided by the container. However, the Faces model is based on the servlet model and hence expects a single request for processing both user interactions and rendering. Because this isn't the behavior in a portlet container, Faces does not execute properly if the Faces application depends on request scoped data established during action processing and referenced during rendering.

the bridge preserves data stored at request scope so that it can be restored on subsequent render requests. I.e. where in a regular portlet environment, each action and render request processing starts with an empty data set in its request scope and any data added to this scope during processing is destroyed when the request completes, the bridge preserves this state and restores it into the request scope on subsequent render requests.