[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [wsrp-wsia] [I#26] Would a isRefresh be valuable for delegated markupgenerat ion?
Status:
Postponed (until discussions with JSR-168)
Topic:
interface
Class:
Technical
Raised by:
Alejandro Abdelnur
Date Added:
4-Sep-2002
Document
Section: Interfaces/6
Description:
defer until
168 discussions. send to mailing list:
It would
allow a portlet to differentiate, within the getMarkup call,
between a request targeted to the portlet and from a request that is a refresh (targeted to another portlet). This flag
is particularly useful for portlets that do not use
performInteraction, it will help the portlet to handle the replay problem. Many existing technologies (Servlets, JSPs, CGIs, etc.) have a single entry point for their request handling. These technologies can not leverage the WSRP two phase request handling. They commonly avoid the replay problem by using redirections, but this is not possible from within a getMarkup call. The isRefresh flag will help identity a refresh request from a real request and handle the replay problem. One of
JSR168 goals is to leverage and enable the use of these
technologies from portlets. The JSR168 portlet API, as part of the PortletRequest interface provides a isRefresh() method. Currently that information is not present in the WSRP protocol. Navigational state can not be used for this purpose because it does
not
change on refresh requests (that is its purpose). Session
state could be use for this but it would be error prone when
there a client request fails/aborts half way through (i.e: performInteraction succeeds and getMarkup does not get called, the next getMarkup will find the bit in the session). Also it would require the producer to have a session to keep this state. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC