Skip to main content

[jsr362-experts:] Re: [jsr362-observers:] Re: Extending the JSF partial-response

  • From: Ross Clewley < >
  • To:
  • Subject: [jsr362-experts:] Re: [jsr362-observers:] Re: Extending the JSF partial-response
  • Date: Tue, 22 Apr 2014 15:50:49 +0100
  • Organization: Oracle Corporation

Hi Scott, Neil

For it to remain an implementation detail of the portlet bridge it seems like that implies the Bridge, as well as encoding the state in the response, requires something in the portlet client to read that and push that state in the Portlet hub. Is that right?

This area of portlet state has been something that I'd mentioned before and that was still worrying me. In particular, I'm specifically talking about private render parameters and particularly when WSRP is in the picture. The private render parameters are part of the portlet's NavigationalContext opaqueState. The values in general can't be known or updated by the Portal, only by the portlet. The ajax proposals we had so far allow for the portlet client to update private render parameters and current proposals allow for that state to be (optionally) sent back to the portal. However, I'm not sure that this is sufficient. The Portal cannot, in the WSRP case, update the state of that private render parameter. It needs to get back to the remote portlet producer somehow and I'm not sure how that can happen. In general anything that requires the portal to either read or update that opaque navigational state is going to be problematic.

Now it seems that in this new proposal, the responsibility is where it needs to be, i.e. with the portlet. That's good news. Although, I'm not sure whether it has yet remove every occasion where the Portal / Portal Hub needs to read or update those private render parameters.


On 22/04/2014 15:25, Neil Griffin wrote:
Hi Scott,

Agreed -- the requirement of transmitting the page state to the client is meant to support JSF, but is not meant to be JSF specific. I also agree that the communication would be a black box from a Spec point of view.

I did not mean to imply that other frameworks or individual portlets should use XML to define the PortletState. Rather, I was simply trying to tell y'all the good news that the JSF Portlet Bridge can assume the responsibility of transmitting the PortletState to the Portlet Hub so that the JSF developer doesn't have to worry about it.

To answer your question -- yes indeed, the JSF Portlet Bridge could encode the PortletState as a byte array. But since this is all a black box, that could be an implementation detail of the JSF Portlet Bridge.

Best Regards,


On Apr 22, 2014, at 10:02 AM, Martin Scott Nicklous < <mailto: >> wrote:

Hi Neil,

The partial action idea with the corresponding requirement on the portlet
to transmit the page state to the client in order to update the portlet hub
page state is meant to support JSF, but is not meant to be JSF-specific.
Other frameworks or even individual portlets that want to make use of the
partial action concepts might not be XML-oriented, so it might not be as
easy for them to deal with the definitions you outline. Also, I would
prefer not to expose or define the structure of the actual page state data
so that communication between the portal on the server and its portlet hub
running on the client can remain a black box from a spec point of view.

Do you see a possibility of the JSF Portlet Bridge somehow accommodating
the portlet state as just being a byte array?

Mit freundlichen Grüßen, / Kind regards,
Scott Nicklous

WebSphere Portal Standardization Lead & Technology Consultant
Specification Lead, JSR 362 Portlet Specification 3.0
IBM Software Group, IBM Collaboration Solutions

Phone: +49-7031-16-4808 / E-Mail: <> / Schoenaicher
Str. 220, 71032 Boeblingen, Germany
IBM Deutschland Research & Development GmbH / Vorsitzender des
Aufsichtsrats: Martina Koederitz / Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen / Registergericht: Amtsgericht Stuttgart,
HRB 243294

Neil Griffin < <mailto: >> wrote on 22.04.2014 15:37:56:

From: Neil Griffin < <mailto: >>
To: <mailto: >,
Date: 22.04.2014 15:38
Subject: [jsr362-experts:] Extending the JSF partial-response

Greetings experts,

As Ed mentioned, the XML Schema for the JSF partial-response permits
an <extension>...</extension> element:

This would allow the JSF portlet bridge to add elements to the
response like the following:


The client-side JavaScript portion of the JSF portlet bridge would
then be responsible for parsing the XML and subsequently calling the
setPortletState(PortletState) JavaScript function.

Alternatively, the JSF portlet bridge could take advantage of the
<eval>...</eval> element to simply execute JavaScript:

   <eval>var portletState = { ... };setPortletState

The choice could be an implementation detail of the bridge.

Best Regards,


[jsr362-experts:] Extending the JSF partial-response

Neil Griffin 04/22/2014

[jsr362-experts:] Re: Extending the JSF partial-response

Martin Scott Nicklous 04/22/2014

[jsr362-experts:] Re: [jsr362-observers:] Re: Extending the JSF partial-response

Neil Griffin 04/22/2014

[jsr362-experts:] Re: [jsr362-observers:] Re: Extending the JSF partial-response

Ross Clewley 04/22/2014

[jsr362-experts:] WSRP Opaque Navigation State

Martin Scott Nicklous 04/23/2014

[jsr362-experts:] Re: WSRP Opaque Navigation State

Ross Clewley 04/23/2014
Please Confirm