Skip to main content

[jsr362-experts:] Minutes from 5 Nov are up; some comments

  • From: Martin Scott Nicklous < >
  • To:
  • Subject: [jsr362-experts:] Minutes from 5 Nov are up; some comments
  • Date: Wed, 13 Nov 2013 11:58:17 +0100


I put up the minutes from last week, see:
https://java.net/projects/portletspec3/pages/MeetingMinutes

There was quite a bit of discussion about how the current portlet
programming model matches with the the requirements placed by
client-centric programming. A suggestion was made that maybe something new
is needed that is not tied to the current portlet programming model and
portlet lifecycle.  The portal should provide for the initial page load and
provide a client-side eventing infrastructure that allows JavaScript
components to communicate among themselves.

I don't really see it that way. The current programming model fits in well
with the REST paradigm, with the action phase corresponding to an HTTP POST
and the render phase corresponding to the HTTP GET verbs. Portlet
rendering takes place based on the portlet state, which consists of the
portlet parameters, the portlet mode, and the window state. I believe that
it would be good to preserve that.

Or, phrased differently, I don't see the use cases that would require the
portlet specification to move away from the current Action / Render model.

I don't see the portlet specification as being the appropriate place to
define a general eventing framework that would allow arbitrary client-side
components to communicate with one another. Dojo, JQuery, and certainly
other JavaScript libraries already provide pub-sub systems to support
eventing. So it's hard for me to see where the value of a general eventing
framework provided by the portal would lie.

As it stands today, any portlet can include JavaScript code in its markup.
That JavaScript code can already use an existing library to coordinate with
other JavaScript entities on the page if it is so desired. JavaScript code
provided by a portlet already today can access resources on the server
through the resource request.

As far as I can see, there is only exactly one thing missing - the ability
for a portlet action request to be carried out in an Ajax manner. So I
think that we need to address this and no other problem, unless there are
other use cases that I have overlooked.

I see the requirements for the Ajax action request as follows:

1) Allow a portlet to submit an action request without causing a full-page
refresh.
2) On the server, the action request needs to execute the full action and
event phase processing, possibly affecting other Ajax portlets on the page.
3) The target portlet needs to be able to obtain updated markup for the new
portlet state as needed
4) Other Ajax portlets on the page that are affected by the portlet event
processing or through changes in public render parameters need to be able
to obtain updated markup.
5) JSF Ajax portlets need to be supported
6) Non-JSF Ajax portlets need to be supported
7) A mix of JSF and non-JSF Ajax portlets on the page needs to be supported
8) No restriction or requirement should be placed on use of a particular
JavaScript library

Please let me know if you see other requirements / use cases.

thanks,
Scott



[jsr362-experts:] Minutes from 5 Nov are up; some comments

Martin Scott Nicklous 11/13/2013

[jsr362-experts:] Re: Minutes from 5 Nov are up; some comments

Werner Keil 11/13/2013

[jsr362-experts:] Re: Minutes from 5 Nov are up; some comments

Neil Griffin 11/13/2013

[jsr362-experts:] Re: Minutes from 5 Nov are up; some comments

Martin Scott Nicklous 11/15/2013
 
 
Close
loading
Please Confirm
Close