Skip to main content

[jsr362-experts:] Re: JSR 362 Ajax Proposal (Alternate)

  • From: Neil Griffin < >
  • To: Kito Mann < >
  • Cc: " " < >
  • Subject: [jsr362-experts:] Re: JSR 362 Ajax Proposal (Alternate)
  • Date: Tue, 28 Jan 2014 13:49:54 -0500

Hi Kito,

Thanks for the kind words. Answers to your questions are embedded below.

-- Neil

On Jan 28, 2014, at 1:11 PM, Kito Mann 
< >

> Hello Neil,
> First of all, I'd like to say I really like this proposal. It's fairly 
> simple and covers the existing user stories well. I have a few 
> questions/comments that we didn't have time to discuss in the call today:
> * In the JS API, what exactly is the portlet ID?

For the sake of simplicity in the proposal, the value of portletId was shown 
to be "PortletA", "PortletB", or "PortletC". Right now the proposal leaves it 
up to the portlet developer to provide a value, but we could require them to 
use the value of <portlet:namespace /> as a unique id if we find it to be 

>  Is it something they developer can retreive programmatically, or is it 
> arbitrary?

The portal vendor and/or the developer would have the opportunity to iterate 
over portlet.registry and retrieve it programmatically like this:

        for (var portletId in portlet.registry) {
                var registeredPortlet = portlet.registry[portletId];

> * In the JS API, what is the portletType? I see "Java" as an example..not 
> really sure how this would be used.

The portletType is simply metadata that the portal vendor and/or the 
developer may reference if necessary. At this time, there are no hard 
requirements or features in the proposal that reference portletType. Just 
seemed like a nice idea (as a just in case).

> * We should consider a more descriptive name for portletState event; 
> perhaps portletStateChanged?

I'm happy to go with a different name if necessary. I chose the term 
'portletState' because that was the term that Scott used in the IBM proposal. 
Broadcasting the 'portletState' event does not necessarily mean that state 
has changed -- it is simply broadcasting the values of the current portlet 
state after the partial lifecycle executes.

> * The portletState object in the example response looks good, but I don't 
> see why the portlet container wouldn't automatically send the updated 
> parameters and fire the portletState event instead of leaving it up to the 
> developer/framework

Currently the Portlet API keeps the contentType and content of the response 
very much up to the developer. I didn't want to impose any rigid requirements 
on the response where the Portlet API currently provides flexibility. During 
the call I mentioned that we could add a method like 
PortletRequest.getPortletState() that could return a PortletState object. 
Perhaps PortletState could have toJavaScript() or toJSON() methods. That 
would make it easier for the portlet developer to broadcast the 
'portletState' event.

> ___
> Kito D. Mann | @kito99 | Author, JSF in Action
> Virtua, Inc. | ;| JSF/Java EE training and consulting
> ;| @jsfcentral
> +1 203-998-0403
> * Listen to the Enterprise Java Newscast:
> * JSFCentral Interviews Podcast: 
> * Sign up for the JSFCentral Newsletter:
> On Mon, Jan 27, 2014 at 12:57 PM, Neil Griffin 
> < >
>  wrote:
> Dear Colleagues,
> Here is a link to a new 229kb PDF document titled "JSR 362 Ajax Proposal 
> (Alternate)":
> (I tried to upload it to ;
> but must not have adequate permission)
> Scott is graciously giving me time during tomorrow's call in order to 
> verbally lead you all through the document.
> Best Regards to all,
> Neil

[jsr362-experts:] JSR 362 Ajax Proposal (Alternate)

Neil Griffin 01/27/2014

[jsr362-experts:] Re: JSR 362 Ajax Proposal (Alternate)

Werner Keil 01/27/2014

[jsr362-experts:] Re: JSR 362 Ajax Proposal (Alternate)

Martin Scott Nicklous 01/28/2014

[jsr362-experts:] Re: JSR 362 Ajax Proposal (Alternate)

Kito Mann 01/28/2014

[jsr362-experts:] Re: JSR 362 Ajax Proposal (Alternate)

Neil Griffin 01/28/2014
Please Confirm