[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.