Skip to main content
This revision made December 18, 2013 09:41, 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.


17 December 2013

     Andy Bosch
 x   Edward Burns
     Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
     Werner Keil
 x   Kito Mann
 x   Scott Nicklous
 x   Andrew Petro
     David Taylor
     Julien Viet
  • Discussed Ajax proposal #2b & Ajax Slides 2b
    • Continued from where we left off last week
    • General comment: Try to get use cases written down
      • would make it much easier to understand what is meant; what is to be accomplished
    • Slide #8: Diagrams on pages 8-12 are confusing at first glance.
      • Hard to tell what work is done by portal & what work done by portlet
      • Suggestion: use 3-tier diagrams like those used for WSRP
      • Suggestion: use an interaction diagram format that clearly shows the scope of a method
    • Slide #9: Why does the proposal focus on changing the state before doing the actual Ajax call?
      • Seems counterintuitive, Ajax call should result in state change, not the other way around
      • But this slide illustrates flow when private render parameters are changed.
        • This is the equivalent of using a different render URL in a traditional portlet - HTTP GET semantics.
        • The model is that setPortletState() is used by the JS portlet to set information that is usually part of the URL
        • The JS portlet woulld use setPortletState() to set parameters, etc, and then use getResourceUrl() to obtain the URL containing that state information
        • The JS portlet would then use that resource URL to retrieve information from the server
        • The setPortletState() method is used to set information on a URL for use with the HTTP GET semantic
    • Slide #10: Proposal 2b attempts to administer portlet state on the page and keep the server up-to-date
      • But at what cost? Synchronizing page / portlet state with the server will cost server round-trips and performance
      • Two problems: 1) Network latency can lead to delays. 2) Many server round-trips may also lead to delays
      • This is a concern because it may lead to an unresponsive UI due to the large amount of server communication
      • May also mean that different portlets on the page receive information at different times - this would need to be handled properly, especially if the portlets coordinate with one another
    • Slide #12: After the Action processing on the server, why not just go ahead and (partially) render the portlets?
      • Data from the rendering could be provided to the portlets without additional server round-trips, which would help address the performance concerny outlined previously
      • Similarly to the JSF partial action request
      • But some portlets might not need new data, event if their state changed
        • Yes, but the partial action rendering could handle that case by allowing a no-op for portlets that have no new data to contribute
      • Moving to this type of model would be more intuitive for developers
        • Developers expect to make a request and get data directly in the response
      • Moving to this type of model would make it easier to support JSF, CDI, & potentially other frameworks
        • Could potentially avoid scoping issues that result from the separation of the Action/Event phases from the Render phase
      • There is concern that the model outlined in proposal 2b would be unintuitive and hard to explain to developers
        • Would potentially turn them off to portlets
        • We should have the goal of making the portlet / JS portlet programming model very easy to use in order to attract developers
    • Consider use of WebSocket technology in this scenario
      • Would potentially have advantages allowing the server to push rendered portlet data and/or page state to the client
      • Would WebSocket use be visible to the JS portlet developer?
        • Would likely be more of an implementation detail of the PortletHub - Portal communication
        • However, may want to provide a possibility of allowing the JS portlet / portlet developer to influence whether web socket support is used
      • Since the target Java EE version for the portlet spec v3 is Java EE 7, we should have the server infrastructure available
      • Depends also on browser support for WebSockets
        • Older browsers & some mobile browsers don't provide support for WebSockets
        • However, by the time portlet spec 3 is finished, the situation should improve
      • May need to allow for graceful degradation to allow use of WebSockets when the technology is available, but work without it when it is not available
  • This was the last meeting of this year, so I wish everybody happy holidays!!
    • Looking forward to working with you next year beginning on 7 Jan 2014!
    • Note: I will be out with no access to my mail 18. Dec 2013 - 6. Jan 2014
      • However, I will try to read the mailing list at least occasionally

10 December 2013

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen - (represented by Iliyan Peychev and Brennan Singleton) (pls correct my spelling if incorrect) 
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   Andrew Petro
     David Taylor
 x   Julien Viet
  
  • Organizational
    • Next week last meeting of the year, since the final two Tuesday fall on Christmas Eve & New Year's Eve.
    • First meeting 2014 will take place on 7 January 2014
    • I will send out meeting invitations for 2014
  • Face to Face
    • Quite a few EG members mentioned that they would be unable to attend in January due to general travel difficulties
    • New proposal: Hold F2F in the framework of the Javaland meeting that takes place in Brühl, Germany on 25-26 March
    • Maybe the Javaland conference would also be an opportunity to recruit help from one or more JUGs - look into this
    • Who would be able to attend a meeting if held in Brühl - say 27-28 March?
  • Discussed Ajax proposal #2b & Ajax Slides #2b
    • Slightly updated version as compared to version 2a from last week
    • Comment on naming: the term "JavaScript Portlet" for client-side code is confusing as it sounds as though the portlet would actually be running in JavaScript on the client, which is not the case
      • We should look for a better name
      • The basic idea should be formalized. What we are referring to is client-side JavaScript code provided by the portlet to handle the portlet UI
    • Look into use of Open Ajax hub
      • Ed will provide description on use of Open Ajax Hub in JSF
      • (note: it has since been determined that Open Ajax has shut down formal work, so this point now seems to be less relevant)
    • It would be good to provide use cases for what we are trying to achieve with Ajax support for portlets in order to better illustrate the concepts
    • Suggestion: It would be better to separate portlet mode and window state from the portlet parameters rather than having a combined PortletState object containing portlet mode, window state, and the portlet parameters
      • (Note: I must say that I didn't understand the reasoning behind this suggestion - it would be great if clarification could be provided)
    • Suggestion: The JavaScript functions provided by the portlet hub should be promise-based to aid error handling & fit in better with JavaScript async concepts
      • Promised-based API is easier to use
    • Suggestion: Add an additional flag to designate the first onStateChange method call as an init call
      • It looks like we need a way to allow JS Portlets to do initialization
    • Question about setPortletState() - does that correspond in any manner to JSF state saving
      • No. The concept of portlet state as used in this proposal is unrelated to the JSF concept of state

03 December 2013

     Andy Bosch
     Edward Burns
     Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
     Michael Freedman
 x   Neil Griffen
     Werner Keil
 x   Kito Mann
 x   Scott Nicklous
 x   Andrew Petro
     David Taylor
 x   Julien Viet
     
  • Discussed the projected Face-to-Face meeting early next year
    • As it stands today, we wouldn't have enough participants
    • Action: email EG members individually to solicit thoughts
  • Discussed Ajax proposal #2a (see both the "proposal" and "slides" 2a documents from 20131126)
    • Slide #2 - Standardization at the JavaScript API level seems reasonable
      • Will allow portal implementations freedom in implementation
      • The JS API will be subject to TCK testing in order to assure proper semantics & portlet interoperability
    • Slide #3 - Does use of portlet state (portlet mode, window state, & parameters) on the client as proposed seem useful
      • Yes, that would seem like a reasonable approach; seems like a good idea or at least a good starting point
      • Although there would be a question as to how often JS portlets would actually need to update their mode or window state
    • Slide #7 - Will an action request require an additional Ajax request to obtain markup?
      • Yes, it would. Steps performed:
        1. Portlet calls the JS action() method
        2. Portlet Hub transmits stateful Ajax request to portal
        3. Portal drives the action & event portions of the portlet lifecycle and returns the resulting new page state to the client.
        4. Portlet Hub parses the new page state and informs each affected JS portlet of its new state through the JS portlet's onStateUpdate() callback method
        5. Each affected JS portlet can (if necessary) obtain a resource URL and retrieve data from the portal to update the UI
      • If only a single portlet were on the page, that would seem inefficient, because you would need two Ajax requests rather than only one.
      • However, if many affected portlets were on the page, it would result in one additional Ajax request for the page.
      • Question would be how important it is to minimize Ajax requests
      • With this approach, we also need to think about scoping issues, since not all portal implementations follow the action / redirect model, returning instead markup directly in the response to the action request.
        • Need to make sure the data can be made available if portlet lifecycle execution is stopped after the event phase.
    • General discussion about proposal 2a:
      • Ajax requests by the the JS portlets should be marked as returning "data" rather than "markup"
        • Sometimes portlets might retrieve for example JSON data or data in another format rather than actual markup
      • This model places the responsibility of retrieving data / markup with the JS portlet rather than having a central instance that updates to DOM for all portlets
        • Yes, because central update of the DOM could potentially interfere with operation of portlet JavaScript operation
        • But then if a simple portlet with no JavaScript were affected by an event or PRP change, a full page refresh would be required
        • That would seem to be too bad, somehow
        • Idea: Consider introduction of a portlet configuration option or some other mechanism to allow a DOM update to be done by the portlet hub to handle such cases
          • Portlets that want to control their own Ajax destiny would configure something like: <allowAutomaticAjaxUpdate>false</allowAutomaticAjaxUpdate>
          • While portlets that want to allow the Portlet Hub to update their DOM could configure: <allowAutomaticAjaxUpdate>true</allowAutomaticAjaxUpdate>
          • (comment: could we use this idea to "statefully Ajaxify" JSR 286 portlets in general? maybe always set the config option to "true" for JSR 286 portlets? need to think about the semantics ...)
      • How would this work with events / client-side event support?
        • Current proposal doesn't allow for client-side events
        • But it would be nice to have a simple & fast event model for JS portlets on the client
        • Related topic: On our to-do list, we have an item for extending the portlet event model
          • Allow for ad hoc events (events that have not been declared explicitly in the portlet descriptor)
          • Allow for broadcast events (portlet sets an event; all listening portlets are notified)
        • Would it be possible to add client-side eventing as well and somehow tie it in with server-side eventing?
          • Would be good to spend some thought here; open to proposals
      • A simple pub-sub system might be preferable
        • Just concentrate on solving the IPC problem
        • Don't try to handle portlet state
        • But this would put burden of state handling to the JS portlet
        • Doesn't solve problem of state shared between portlet & portal
        • Do we want to solve problem of state handling or just concentrate on IPC problem?
      • Proposal 2a attempts to solve state handling problem
        • Portlet Hub handles page state on the client-side
        • Provides portlet state to the individual portlets through the JS portlet's onStateUpdate() callback method
        • onStateUpdate() is always called for each portlet whose state has changed, so the JS portlet can count on doing (or at least initiating) its UI updates within that method
        • Portlet Hub is part of portal implementation, so it could be tied in to JavaScript code in the portal theme, for example
          • Potentially allows portal theme to react to changing public render parameters, portlet mode, window state
          • Example: portlet changing its portlet mode to "help" or "edit" might cause portlet theme to change its UI in some manner (styles, navigation possibilities)
          • Example: portlet changing its window state to "full" might cause the Portlet Hub to update window states of other portlets to "minimized"
      • JSF Questions:
        • To make propsal 2a work with JSF, we would need a JSF-portlet bridge update in some form
        • "JavaScript JSF Portlet Bridge" could mediate between jsf.js & portlet hub on client
          • Could register the JSF JS portlet with the Portlet Hub
          • Could provide utilities to make it easy for a JSF portlet to provide JS code that is executed when the portlet's onStateUpdate() method is called
          • Could register with jsf.js callback handlers for notification after the JSF portlet does an Ajax request
          • (idea after the call: Could potentially intercept the jsf.ajax.request() method for JSF portlet action requests if that would be beneficial in order to use the Portlet Hub action() instead ??)
  
 

19 November 2013

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Michael Freedman
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   Andrew Petro
     David Taylor
     Julien Viet
     
  • We welcomed Andrew Petro as a new member to the EG
    • Andrew has been active in the portal space for years and recently serving as release manager for the uPortal project. He brings considerable experience with Java technology and open source projects to the team, having been active on the Apache Portals project. He is currently with the University of Wisconsin, where he is once again involved with Portal technology.
    • Welcome Andrew!
  • Discussed Ajax support for portlets
  • Main use case still seems to be adding support for a stateful Ajax request (= action request with partial page update)
    • Short outline of where we stand:
      • Proposal #1 "Partial Rendering on Server":
        1. JS code on client submits Ajax action request;
        2. Portal drives the portlet lifecycle to completion with events, parameter changes, and everything;
        3. Portal performs partial render for all affected portlets;
        4. Portal transfers updated markup to client;
        5. Central JS code on client updates DOM for all affected portlets.
        • This approach seems to have many problems; can interfere or break JS code for individual portlets. Looks like no-go.
      • Proposal #2 "Pub-Sub of Portlet State":
        1. JS code on client submits Ajax action request;
        2. Portal drives portlet lifecycle through Action & Event phases (but not Render!);
        3. Portal returns new state (portlet parameters, portlet mode & window state) to client for all affected portlets;
        4. JS code on client notifies each affected JS portlet of new state;
        5. Each affected JS portlet individually responsible for obtaining new markup as necessary.
        • Approach seems to not fit terribly well with JSF; Requires extra server round-trips for each portlet to obtain markup
      • Proposal "PartialActionURL":
        1. A new PartialActionURL is introduced into the portlet programming model; See: some JSF background info
        2. Forms submitted through this new type of URL;
        3. Portal drives portlet lifecycle through Action & Event phase;
        4. Portal renders (possibly through serveResource) target portlet only;
        5. Markup for target portlet is returned to client;
        6. JavaScript code that causes events to be fired on client to notify other affected portlets is added to markup by portlet programmer
        7. Each of the other affected portlets performs Ajax requests to retrieve markup
        • Fits in very well with JSF; However, relies on portlet programmer to "do the right thing"; seems to fit less well with non-JSF portlets
        • Alternative: Portal injects JS code to do the notification
        • JSF.js module uses eval to execute any JavaScript passed to it
        • Would it be possible to use JSF.js plug points (before / after XMLHttpRequest execution) instead of injecting JavaScript?
    • Discussion about JavaScript and optimization of # of requests
      • Today working in HTTP 1.1 world trying to minimize number of Ajax requests
      • Soon HTTP 2.0 will be available, number of requests will become less important
      • While optimizing for today, we should be forward-looking in our design.
      • Optimizing number of Ajax requess is important, but seems to be more of a 2nd-level problem
    • Pub-Sub in JavaScript is good model; been done before, well-understood
      • but pub-sub of portlet state not so good; doesn't fit well with JSF
    • Big question: do we want to keep concept of portlet state on client
      • Portlet state consists of portlet parameters, portlet mode, & window state
      • Some portals don't use portlet mode & window state too much; they would therefore be less important
      • Other portals make extensive use of portlet mode & window state, including custom modes & custom window states; these items would therefore be more important
    • Use case: push button & window state changes - what happens?
      • Could be handled by portal JS code on client to change decorations, etc
      • Could be handled by portlet JS code, because it might need to retrieve additional markup
      • Might need both types of change
    • Do we want to support complete JavaScript-based UI?
      • Would be good if we see portlets in a distributed component model
      • However, sweet-spot for portlets is server-side aggregation of components that don't necessarily know much about each other
      • Alternative: Server provides basic markup; JavaScript added to make it "come to life" on the client
      • Suggestion: Goal for portlet spec 3 should be to bring portlets to Ajax-level of JSF 2.0 spec
    • Conclusion: need detailed use cases to make progress here

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. ---- 17 December 2013 Andy Bosch x Edward Burns Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan x Michael Freedman x Neil Griffen Werner Keil x Kito Mann x Scott Nicklous x Andrew Petro David Taylor Julien Viet * Discussed [https://java.net/projects/portletspec3/downloads/directory/WorkingDocs/Ajax Ajax proposal #2b & Ajax Slides 2b] ** Continued from where we left off last week ** General comment: Try to get use cases written down *** would make it much easier to understand what is meant; what is to be accomplished ** Slide #8: Diagrams on pages 8-12 are confusing at first glance. *** Hard to tell what work is done by portal & what work done by portlet *** Suggestion: use 3-tier diagrams like those used for WSRP *** Suggestion: use an interaction diagram format that clearly shows the scope of a method ** Slide #9: Why does the proposal focus on changing the state before doing the actual Ajax call? *** Seems counterintuitive, Ajax call should result in state change, not the other way around *** But this slide illustrates flow when private render parameters are changed. **** This is the equivalent of using a different render URL in a traditional portlet - HTTP GET semantics. **** The model is that setPortletState() is used by the JS portlet to set information that is usually part of the URL **** The JS portlet woulld use setPortletState() to set parameters, etc, and then use getResourceUrl() to obtain the URL containing that state information **** The JS portlet would then use that resource URL to retrieve information from the server **** The setPortletState() method is used to set information on a URL for use with the HTTP GET semantic ** Slide #10: Proposal 2b attempts to administer portlet state on the page and keep the server up-to-date *** But at what cost? Synchronizing page / portlet state with the server will cost server round-trips and performance *** Two problems: 1) Network latency can lead to delays. 2) Many server round-trips may also lead to delays *** This is a concern because it may lead to an unresponsive UI due to the large amount of server communication *** May also mean that different portlets on the page receive information at different times - this would need to be handled properly, especially if the portlets coordinate with one another ** Slide #12: After the Action processing on the server, why not just go ahead and (partially) render the portlets? *** Data from the rendering could be provided to the portlets without additional server round-trips, which would help address the performance concerny outlined previously *** Similarly to the JSF partial action request *** But some portlets might not need new data, event if their state changed **** Yes, but the partial action rendering could handle that case by allowing a no-op for portlets that have no new data to contribute *** Moving to this type of model would be more intuitive for developers **** Developers expect to make a request and get data directly in the response *** Moving to this type of model would make it easier to support JSF, CDI, & potentially other frameworks **** Could potentially avoid scoping issues that result from the separation of the Action/Event phases from the Render phase *** There is concern that the model outlined in proposal 2b would be unintuitive and hard to explain to developers **** Would potentially turn them off to portlets **** We should have the goal of making the portlet / JS portlet programming model very easy to use in order to attract developers ** Consider use of WebSocket technology in this scenario *** Would potentially have advantages allowing the server to push rendered portlet data and/or page state to the client *** Would WebSocket use be visible to the JS portlet developer? **** Would likely be more of an implementation detail of the PortletHub - Portal communication **** However, may want to provide a possibility of allowing the JS portlet / portlet developer to influence whether web socket support is used *** Since the target Java EE version for the portlet spec v3 is Java EE 7, we should have the server infrastructure available *** Depends also on browser support for WebSockets **** Older browsers & some mobile browsers don't provide support for WebSockets **** However, by the time portlet spec 3 is finished, the situation should improve *** May need to allow for graceful degradation to allow use of WebSockets when the technology is available, but work without it when it is not available * This was the last meeting of this year, so I wish everybody happy holidays!! ** Looking forward to working with you next year beginning on 7 Jan 2014! ** Note: I will be out with no access to my mail 18. Dec 2013 - 6. Jan 2014 *** However, I will try to read the mailing list at least occasionally ---- 10 December 2013 Andy Bosch x Edward Burns x Ross Clewley
 
 
Close
loading
Please Confirm
Close