Skip to main content

[jsr362-experts:] JSR 362 Ajax Proposal (alternate) - Resource URLs

  • From: Martin Scott Nicklous < >
  • To:
  • Subject: [jsr362-experts:] JSR 362 Ajax Proposal (alternate) - Resource URLs
  • Date: Mon, 3 Feb 2014 09:34:42 +0100



When a page is initially rendered, individual portlets can render resource
URLs into the markup. These resource URLs typically contain render &
resource
parameters and other portal / portlet state information that defines the
data
the portlet will receive when the resource URL is used.

Also, the resource URLs contain cacheability options, namely, PAGE,
PORTLET, SHARED and FULL. These cacheability options define the additional
data contained on the URL and define the circumstances
under which the data returned by the serveResource request can be cached.

For example, if a resource URL is created with CACHEABILITY_PAGE, the
resource URL can contain the complete state of the portal page. Markup
generated
within a serveResource request accessed through such a URL can contain
portlet render and action URLs. If the cacheability is not set to PAGE,
action and render URLs cannot be created within the serveResource method.

Well-written portlets will use the highest level of cacheability that is
consistent  with the purpose of the portlet.

When a resource URL is used with the HTTP GET method, the browser and HTTP
proxy caching infrastructure will cache the markup fragments or other data
returned by the serve resource request. This helps optimize performance for
the Ajax requests used to set up the page, since sometimes the user will
get
lucky and the data being requested will be available from the browser or
HTTP proxy cache.

At the risk of repeating myself, I want to stress that it is GOOD to
retrieve
markup fragments and other data for display on the UI through appropriately
defined resource URLs, since doing so enables caching of the data by the
browser
as well as through the HTTP caching infrastructure.

If a stateful action request is carried out or if the public render
parameters
are changed by a portlet action, the page state is changed. However, the
old
resource URLs contained in the original markup still contain the original
public and private render parameters and the original page state.

This means that the original resource URLs from the original markup cannot
be
used to retrieve data after a stateful Ajax request has been carried out,
since
they contain invalid parameters and page state.

So we need to have a method on the client side that allows the resource URL
to be recalculated or generated containing the appropriate resource &
render
parameters, the page state, and the cacheability options.

This need is met by the JavaScript API presented in Ajax Proposal 2b, but
is
not met by the alternative proposal.

regards,
Scott



[jsr362-experts:] JSR 362 Ajax Proposal (alternate) - Resource URLs

Martin Scott Nicklous 02/03/2014
 
 
Close
loading
Please Confirm
Close