Skip to main content
This revision made November 13, 2013 09:49, by Martin Scott Nicklous

Expert Group Meeting Minutes

The JSR 362 Expert Group meetings take place every Tuesday, unless exceptions are made. After the meeting, I will update this page with the minutes.


05 November 2013

     Andy Bosch
     Edward Burns
     Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
     David Taylor
     Julien Viet
  • Discussed Ajax proposal
    • Revisit Kito's article on Ajax update
      • Ajax invocation of resource phase
      • We could fix resource phase to allow parameter updates
    • Proposal to have event-based updates on the client side for Ajax
      • Loosely-coupled pub-sub system
      • very flexible, portlet developers could decide whether or not to opt.in
      • "provides the plumbing, but not the house"
      • The JSF implementation seems to try to provide the "house"
    • May want to forget the portlet lifecycle; provide something taylored to JavaScript programmers
      • How about portlet state - how should that be handled?
      • No need to encode state in URL
      • People who work with Ajax UI don't expect back-button, bookmarking within Ajax page to work
      • Would be OK if back-button caused complete exit from page
      • On the other hand, not sure if that assumption holds. People like using the back-button and bookmarks
    • Portlet programming model
      • WSRP very oriented towards server-server communication
      • Portlet programming model oriented towards full-page refresh
      • Both seem to be not a great fit for client-centric programming
      • Question is whether portlet programming model could be easily adapted to support client-side programming
    • Idea: move the eventing / coordination completely to the client
    • Need to get back to use cases: Is use case of allowing Ajax action request valid?
      • Portlet lifecycle very valuable to aggregate initial page view
      • After initial render, portlet UI very much under control of client-side JavaScript
      • Web developer very reliant on JavaScript libraries like Dojo
      • Ajax action request good idea, but response should include markup for target portlet

29 October 2013

     Andy Bosch
     Edward Burns
     Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
     David Taylor
     Julien Viet
  • Discussed the need for a JSR 362 EG F2F meeting
    • Would be good to have a F2F early next year. Would help in firing up the group; closing on issues.
    • One possibility would be in around March/April after the major issues have all been at least addressed but maybe not closed upon.
    • Another possibility would be to have a meeting in January to talk about Ajax support and maybe other things, potentially with another meeting later on.
    • I would be happy to host the meeting in Boeblingen
    • ==> Put it up to the group; see what everyone would prefer to do.
  • Discussed timeline for completing the JSR 362 work
    • One firm date - need to get an early draft review out by Jan / Feb 2014, which should cover some major topics, but doesn't need to be complete. Could put out a follow-on draft or drafts later as well.
    • General goal taken from initial JSR proposal would be to have the spec complete by the the end of 2014.
    • Some would like to see it be finished sooner - maybe end of summer 2014.
      • That would be great, but would depend on how many people help with work, particularly with the reference implementation.
    • Neil volunteered to write up a proposal for the updates from the servlet 3.0 / 3.1 world, which would be very welcome.
      • Thanks, Neil!
  • Discussed Ajax proposal #2
    • Comments about objectives - shouldn't limit ourselves to the portlet model.
      • Developers sometimes don't like portlets because the lifecycle is too complex; needs too much explaining.
      • Portlets look like they're servlets, but there are major differences - confusing to programmers.
      • When designing new Ajax support, we shouldn't bring the old, difficult-to-understand structures forward into the new Ajax world.
      • We should remain open to new concepts; try to introduce very general support that would work with any kind of JavaScript library.
      • Try not to force people to use portlet-specific technology.
      • (Scott's comment, not discussed directly in call: If I understood the gist of the above arguments correctly, the suggestion would be that we introduce capability that would allow stateful Ajax updates without running through the portlet action-event-render lifecycle.)
      • On the other hand, we're writing a Java specification for portlets, so there would be a certain justification for being portlet-specific while being as open as possible.
        • The portal owns the page; provides data for initial load.
        • We can expect JavaScript portlet components on the page, but there might be other types of components as well.
      • We should look at existing frameworks; see if we can base on an existing standard.
        • But also here, it's difficult to pick winners & losers among JS frameworks - OpenAjax has terminated operations; Thought DoJo would sweep the world, but it didn't, really; Many people like Jquery instead.
        • The API described in the Ajax proposal document, by delegating the actual Ajax communication to the JS portlet, actually attempts to allow the JS portlet author to use pretty much any JS library.
    • Maybe we shouldn't define methods, but define events instead.
      • Would potentially be able to work better with existing & future JavaScript libraries.
      • Events fit in better with the JavaScript programming model than method definitions.
      • Could use a publish / subscribe model rather than method calls to do the necessary work.
      • See if there would be a JavaScript eventing framework that we could use
      • (another Scott's comment: JavaScript offers native support for custom events so this would be doable if we wanted to without an additional framework, see: w3c DOM4 spec.)
    • Proposal clashes with JSF Ajax support
      • JSF "takes control" of the XMLHttpRequest (the Ajax request); expects to carry out the Ajax communication and process the response.
      • In fact, looking at the Mojarra & MyFaces components, the actual handlers registered are not even core JSF handlers - they're implementation-specific.
      • JSF makes no provision for JavaScript programmers who wish to use a different JavaScript library for Ajax communication.
      • No provisions for plugging in another framework.
      • Hard to see how form submission through JSF would work together with the proposed Portlet.action() method.
      • JSF wants complete control of the XMLHttpRequest; won't understand portlet action
    • With the createResource URL call, there may be security implications.
      • Don't want to make a hole allowing cross-site-scripting attack
      • Need to review with regard to security
    • To move forward, I think we should collect use cases so that we can try to figure out how to meet them.
      • The current Ajax Proposal #2 adds stateful Ajax support to the portlet model; I think it would work as described.
      • Major unaddressed use case identified so far: support for JSF portlets
      • Others? please provide description ... thx!

22 October 2013

     Andy Bosch
     Edward Burns
     Ross Clewley 
 x   Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   David Taylor
 x   Julien Viet
  • Discussed Ajax support in the portlet specification - do we agree main goal should be to provide a stateful Ajax support?
    • Good use case, we should do it. However, supporting shared render parameters might be a blocker.
    • Didn't get into JSR 286 due to disagreement on scope
    • How to handle navigational state, private parameters & public render parameters in session?
      • Need to explore this; adapt in some manner if it is seen to be a blocker
    • Eventing model fits well to Ajax model; helps with communication
    • Need to align with Faces; make sure JSR 362 Ajax support can work with Faces
    • Currently, JSF.js is loaded once for each portlet that uses JSF Ajax support.
      • Requirement: Portlets need to be able to share resources & define dependencies on external modules like JSF.js or other JavaScript libraries
    • JavaScript programming needs good module definitions. Need to scope the JavaScript APIs. Look into acquire.js - very good.
  • Ajax support for JSR 286 portlets
    • Stateful support not defined by JSR 286 spec; shouldn't try to make stateful JSR 362 Ajax support work for JSR 286 portlets
    • Portal vendors may have their own proprietary solutions for JSR 286 portlets
  • Discussed JSR362AjaxProposal document
    • Document specifies JSON; good. However, JSF uses an XML format for messages between the server and the client.
    • Question: Do we need to specify the message format at all?
      • If the "portlet.js" layer on the client consists of an API definition & an implementation, can we say that the implementation, together with the messages exchanged with the server, is vendor specific and does not need to be specified?
      • It comes down to the question of whether interoperability between one vendor's implementation of "portlet.js" and another vendor' portal server is required
      • What about the WSRP case? Would an JSR 362 Ajax portlet loaded through WSRP require a (possibly different) "portlet.js" module?
      • JSF defines XML messages between client & server, but is very flexible in allowing extensions
      • Might be good if we define messages for stateful Ajax support as well.
    • Programmers would rather not have to deal with many new APIs ... do we really need a new ajaxRequest() method?
      • Seems to be not much different than the current processAction() method
      • Could we maybe just get by with the current Action method?
    • Need to be careful about overloading already existing methods
      • Might end up making the API much more confusing to use
      • Would probably be much cleaner to separate the Ajax stuff into a completely new set of interfaces
      • Focus on developer who wants to write "pure" Ajax portlet; define good programming model & APIs for that use case
      • Trying to do "mixed-mode" portlets trying to accomodate the JSR 286 model and also stateful Ajax support will likely get very complicated.
      • New type of portlet might need a new API

15 October 2013

     Andy Bosch
     Edward Burns
     Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
     David Taylor
 x   Julien Viet
  • Have been working with Pluto to gain understanding
    • Tried Pluto on TomEE, since TomEE already has complete JavaEE stack, including JSF
  • Began discussion of Ajax support
    • No concrete proposal yet ... I'll work on getting a proposal documented
    • My preference would be not to modify serveResource semantics to improve Ajax support
    • Potentially introduce new handling method for Ajax requests
      • Something like: processAjaxRequest(AjaxRequest request, AjaxResponse response)
      • Would be allowed to set parameters, fire events, etc., similar to processAction
      • May need to introduce new portlet phase to handle that
      • Would introduce corresponding URLs
      • Would (in some manner) return list of portlets on page whose markup is to be updated
      • May need to introduce some form of client-side interface that could be plugged into in order to obtain the update information
      • JSF has already addressed the problem of DOM updates, has defined client-side JavaScript library - may be able to reuse ideas
      • Mojarra & MyFaces JSF.js libraries both use OpenAjax library. However, OpenAjax eventing is not used
    • How far would we want to go in defining a client-side interface for Ajax support?
      • Would be nice to see how far we can go toward client API that allows for eventing, etc.
      • With corresponding IPC model, could even go so far as to allow for comminucation between portlets on different pages
      • Could support portlet communication with widgets
    • General comments on Ajax support:
      • Depending on how far we want to go, could be big change to portlet execution model.
      • Current execution model:
        • Portal is an actor on the server that contains portlets (portal applications) and mediates client requests
        • Receives client requests, drives portlet lifecycle, aggregates markup from portlets, delivers response to client
      • Addition of Ajax support could open up this model
        • For the Ajax request, portal acts a proxy to the targeted portlet
        • Portlet could change its state, communicate with other portlets that can also update their state
        • Resulting markup for affected portlets aggregated by the client
        • Unaffected portlets would not be re-rendered
        • Considerable departure from current model
      • Could allow inter-portlet communication on client
        • Possibly define JavaScript "Portlet-API" for client
        • Would need to be JavaScript Library agnostic
  • Discussed "PORTLETSPEC3-24: Allow GenericPortlet.doHeaders to throw a PortletException or IOException."
    • As mentioned in a previous call, I added the "throws" clause to doHeaders().
    • However, it was pointed out that by doing so, a a binary compatibility would be introduced for all portlets that extend doHeaders as defined by the JSR 286 spec
    • It seems that the fix for the issue will have to be rolled back
    • A possible alternative would be to introduce a new doHeaders() method as described in the issue comments.
    • However, this alternative may be of questionable value ... need to collect more information and revisit.
    • If no good alternative can be found, the fix will be rolled back and the issue closed as "won't fix"

01 October 2013

     Andy Bosch
     Edward Burns
     Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
     David Taylor
     Julien Viet
  • So far, we have dealt with items associated with errata and clarifications to the JSR 286 Spec
    • Decisions have been taken and corresponding changes have been made to the spec & API
    • This work is pretty much complete
    • We can begin work on new work items
  • Discussed which area we want to focus on next
    • Ajax Support
    • Alignment with JSF
    • Updates from the servlet world ... possibilities:
      • Part interface to support multi-part form data
      • Introduce portlet fragments analogous to servlet fragments
      • Error screen handling
      • Annotation support for the most commmon portlet configuration options
      • Dynamic registration of listeners & filters at context initialization time
      • Asynchronous support
      • ...
    • ARIA Support - do we need to standardize anything in this area?
    • CDI support
      • There might be low-hanging fruit here - work has already been done.
    • Do portlets eventually want to become part of a Java EE profile?
      • Would be desireable to work toward that goal
      • To begin with, could be thought of as an add-on to the Java EE Web Profile
      • In order to better couple with Java EE, would need to explicitly integrate with JSF
Difference compared to previous revision
=Expert Group Meeting Minutes The JSR 362 Expert Group meetings take place every Tuesday, unless exceptions are made. After the meeting, I will update this page with the minutes. ---- 05 November 2013 Andy Bosch Edward Burns Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan x Michael Freedman x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous David Taylor Julien Viet * Discussed Ajax proposal ** Revisit Kito's article on Ajax update *** Ajax invocation of resource phase *** We could fix resource phase to allow parameter updates ** Proposal to have event-based updates on the client side for Ajax *** Loosely-coupled pub-sub system *** very flexible, portlet developers could decide whether or not to opt.in *** "provides the plumbing, but not the house" *** The JSF implementation seems to try to provide the "house" ** May want to forget the portlet lifecycle; provide something taylored to JavaScript programmers *** How about portlet state - how should that be handled? *** No need to encode state in URL *** People who work with Ajax UI don't expect back-button, bookmarking within Ajax page to work *** Would be OK if back-button caused complete exit from page *** On the other hand, not sure if that assumption holds. People like using the back-button and bookmarks ** Portlet programming model *** WSRP very oriented towards server-server communication *** Portlet programming model oriented towards full-page refresh *** Both seem to be not a great fit for client-centric programming *** Question is whether portlet programming model could be easily adapted to support client-side programming ** Idea: move the eventing / coordination completely to the client ** Need to get back to use cases: Is use case of allowing Ajax action request valid? *** Portlet lifecycle very valuable to aggregate initial page view *** After initial render, portlet UI very much under control of client-side JavaScript *** Web developer very reliant on JavaScript libraries like Dojo *** Ajax action request good idea, but response should include markup for target portlet ---- 29 October 2013 Andy Bosch Edward Burns Ross Clewley
 
 
Close
loading
Please Confirm
Close