Skip to main content

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

  • From: Werner Keil < >
  • To:
  • Subject: [jsr362-experts:] Re: Portlet 3.0 Alternate Proposal - always use RENDER_PHASE
  • Date: Tue, 4 Feb 2014 13:28:18 +0100

Thanks,

As we have Agile Kick-Off meeting today, it is unlikely I'll join the call
this week. If so, then maybe towards the end.

Did you hear more about the exact times of the F2F at JavaLand?

Regards,
Werner

On Tue, Feb 4, 2014 at 1:15 PM, Martin Scott Nicklous <
>
 wrote:

> 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