Skip to main content

[jsr362-experts:] Re: Portlet 3.0 Alternate Proposal - always use RENDER_PHASE

  • From: Martin Scott Nicklous < >
  • To:
  • Subject: [jsr362-experts:] Re: Portlet 3.0 Alternate Proposal - always use RENDER_PHASE
  • Date: Tue, 4 Feb 2014 13:15:45 +0100

Hi Neil,

The change you propose here addresses the cacheability concern by allowing
use of HTTP GET along with a partial render URL, but it still introduces
the complexity of deciding whether a full render or a partial render is to
be performed, and it also introduces more complexity by requiring a partial
render URL to be used under certain circumstances. Portal complexity
increases as well, since the portal would have to recognize when a partial
render URL is being processed in order to treat it like a resource URL and
avoid refreshing the entire page.

But there is also another reason why I believe serveResource() rather than
render() should be used. The render method is meant to be used to produce
markup that is aggregated by the portal to form a complete page that is
transmitted to the client, while the serveResource method was created to
serve fragments or binary resources for use by the portlet client code
running on the browser.

Within the render method, the portlet is not allowed to set character
encoding, locale, content type, HTTP status, or HTTP header information. It
is assumed that the portal does these things once for all portlets on the
page.

By contrast, the ResourceResponse allows all of these items to be set
through the setStatus (new to Portlet 3), setContentType,
setCharacterEncoding, setLocale, and setProperty / addProperty methods. So
serveResource allows a much higher degree of control and much more
flexibility than the render method.

You need this flexibility if you want to, for example, serve a dynamically
created image to the portlet client.

Naturally, it would be possible to allow use of these methods in the render
method in the case of a partial render, but that would basically morph the
render method into a "render or serveResource" method, duplicating
functionality we already have available and adding a great deal of
conditional processing in both the portlet and the portlet container.

Wouldn't it be easier and clearer just to use serveResource for the partial
response?

Also, if we just use the serveResource method directly, I don't believe you
would need to discern between a full render and a partial render at all.
Resource requests are by definition partial render requests and our portals
handle them that way today. All you would have to do after the partial
action request would be to call serveResource with the appropriate resource
parameters to pick up the appropriate partial response.

There are also cases where a portlet might need multiple resources to
update the UI (JSON data & and generated image, for example). With a JSR
286 portlet, you would address each resource using a resource URL with
differing resource parameters. If we introduce the concept of partial
rendering through the render method, we would need to vary the render
parameters on the partial render URL to achieve the same goal. While it
would be possible to generate partial render URLs with differing
parameters, it would be a big conceptual break with JSR 286, since varying
the render parameters on a render URL addresses a completely different
render state with a 286 portlet. With a resource URL, you have the basic
render state represented by the render parameters, portlet mode, and window
state that stays fixed. You vary the additional resource parameters on the
resource URL to obtain different resources for the same portlet render
state.

There would also be the difficulty of explaining when a programmer needs to
use a partial render URL as opposed to a resource URL. I think there would
be a lot of confusion and frustrated programmers.

So I think that generating data as a response to a stateful Ajax request
should always be done in the serveResource() method rather than in the
render() method. We should not introduce a concept of partial rendering in
the render method.  I recognize that using serveResource to serve the
partial response goes against current operation of the portlet bridge. In
spite of that, I think we will need to bite that bullet and change the
bridge (and optimally the bridge spec) in that regard.

regards,
Scott

Neil Griffin 
< >
 wrote on 30.01.2014 16:55:54:

> From: Neil Griffin 
> < >
> To: 
>  ,
> Date: 30.01.14 16:56
> Subject: [jsr362-experts:] Portlet 3.0 Alternate Proposal - always
> use RENDER_PHASE
>
> Hi everyone,
>
> During our call this week, Julian and Scott provided valuable
> feedback about the Portlet 3.0 Alternate Proposal. Specifically,
> they commented that the Portlet 3.0 Partial Lifecycle would invoke
> the RENDER_PHASE for Portlet A, but subsequent XMLHttpRequests from
> Portlet B and Portlet C would invoke the RESOURCE_PHASE. This works
> fine for frameworks like JSF, but Java/JSP portlet developers would
> find this confusing because the partial rendering logic would have
> to be duplicated in both doView() and serveResource().
>
> In order to incorporate this feedback, here is what I propose:
>
> 1. KEEP the following addition to the Portlet API:
> PortletRequest.isPartial()
>
> 2. DON'T ADD the following to the Portlet API:
> MimeResponse.createPartialActionURL()
> <portlet:partialActionURL />
>
> 3. INSTEAD, ADD the following to the Portlet API:
> MimeResponse.createActionURL(boolean partial)
> MimeResponse.createRenderURL(boolean partial)
> <portlet:actionURL partial="true|false" /> // Default false for
> backward compatibility
> <portlet:renderURL partial="true|false" /> // Default false for
> backward compatibility
>
> In order to illustrate this, I have updated Figure 4.1 (the Portlet
> 3.0 Partial Lifecycle Sequence Diagram). Here is a link to the
> updated diagram:
> http://www.portletfaces.org/downloads/jsr-362/partial-lifecycle-
> sequence-diagram-2.png
>
> The diagram illustrates that when an XMLHttpRequest targets a
> RenderURL with partial=true, it would ALWAYS be HTTP GET (never HTTP
> POST). This is because RenderURLs have always been associated with
> HTTP GET and it would be a little weird to use HTTP POST. In
> addition, HTTP POST *might* cause difficulties for WSRP. If an HTTP
> POST is necessary (as is the case with JSF) then a ResourceURL could
> be used, which is what the JSF Portlet Bridge does nowadays anyway.
>
> Best Regards to all,
>
> Neil



[jsr362-experts:] Re: Portlet 3.0 Alternate Proposal - always use RENDER_PHASE

Martin Scott Nicklous 02/04/2014

[jsr362-experts:] Re: Portlet 3.0 Alternate Proposal - always use RENDER_PHASE

Werner Keil 02/04/2014
 
 
Close
loading
Please Confirm
Close