[jsr362-experts:] Re: Minutes from 5 Nov are up; some comments
- From: Werner Keil <
- Subject: [jsr362-experts:] Re: Minutes from 5 Nov are up; some comments
- Date: Wed, 13 Nov 2013 12:52:22 +0100
Thanks a lot for the update. I joined the EC call yesterday and while Azul
couldn't make it again, based on Gil's schedule (and maybe some of the new
EC Members, guess it needs to be sorted out a bit more) Heather and others
proposed Tuesday for the important Individual Member WG of JCP.next. The
time I understood would overlap with this EG call. I hope, it can be
shifted slightly, better after it, otherwise I get troubles leaving too
early from work, as the phones here don't work, you remember[?]
In the unlikely event, that the 2 calls really ended up at the same time,
I'd have to establish some kind of alternation, e.g. even weeks JCP.next,
odd weeks this EG. Hope it can be avoided[?]
Bruno who aside from Heather (with a bit of help from myself and a few
others, e.g. Mike De Nicola) stirring this WG mentioned in yesterday's 2 EC
calls (one private, one public) the idea of a "JUG/Adopt/Community" WG to
explore how JUGs, but also interested companies could get more involved
with JSRs and Java. This is of course a good idea and last but not least
this JSR could benefit from its outcome if concrete efforts were to start
P.s.: I have at least one Board member of JUGS here in Stuttgart working at
Thales, so should we get together in Böblingen and there is a part of the
F2F not EG private, then why don't we try to invite some of those guys from
nearby JUGs? (especially those around iJUG)
I don't know myself, if I'll attend the mainly iJUG driven JavaLand in late
March (so far they accepted only talks by JUGs and a few from companies, my
"Responsive Web UI" topic around Apache DeviceMap is just on "standby"
while "PhoneGap" once again is written in stone already, hence it depends
on that if I go there) but should any of you coming from another country
consider attending, it could be scheduled close enough to allow you
attending it, too. Portlets are not "sexy" enough for those JUGs, I had the
discussion with e.g. Markus Eisele already, hence no real Portal topic will
be there, but e.g. a few people involved in JSF or Java EE will be there.
Didn't see Andy speaking, but maybe he plans to attend.
On Wed, Nov 13, 2013 at 11:58 AM, Martin Scott Nicklous <
> I put up the minutes from last week, see:
> 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
> 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
> eventing. So it's hard for me to see where the value of a general eventing
> framework provided by the portal would lie.
> 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
> 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
> Please let me know if you see other requirements / use cases.
Description: GIF image
Description: GIF image
Description: GIF image