Skip to main content
This revision made March 04, 2014 14:55, 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.

04 February 2014

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
 x   Kenneth Finnigan 
 x   Neil Griffen
     Werner Keil
 x   Kito Mann
 x   Scott Nicklous
     Andrew Petro
 x   David Taylor
 x   Julien Viet
  • The access rights to the download area should now allow any EG member to add documents.
    • However, I would like to reserve the right to delete / update documents so that I don't lose track of what is out there. If you need a document deleted, let me know.
  • News about Face-to-Face:
    • A room is available, need to decide on exact times.
    • Scott will look at schedule, look for 2 2-hr slots that would allow EG members and invited guests to attend
    • Don't count on projector being available; Scott will try to bring one
  • Discussed CDI scope for portlets
    • This needs to be considered during our Ajax deliberations, since it strongly affects the JSF support
    • See Neil's post to the subject of CDI
    • Basic idea: Define @PortletLifecycleScoped - Custom CDI scope that spans from the ACTION_PHASE/EVENT_PHASE into the RENDER_PHASE of the portlet lifecycle.
      • That would allow CDI beans to live across the Action, Event, and Render phases
    • But portlets need to be re-rendered (simple page reload by browser), and it might also be useful for Resource phase to have access to the beans
      • So maybe it would be good to define something like @PortletRenderStateScoped scope that exists as long as a specific portelt render state is in force
      • That would mean the beans live from one action / event to the next
      • Mike implemented this for JSF managed beans with the @PortletRedisplayScoped for the JSR 329 portlet bridge
    • The Portlet API would define the annotations for the custom scope; the portal implementations would provide the code to make it work
    • To make the example in Neil's post work, @Inject has to work in a portlet class
      • Here, the portlet might have to delegate to the CDI implementation to make it work ... not sure
      • Need to get more information on how the CDI bean management methods work with beans that are not instntiated bs the CDI impl
      • CDI 1.1 introduced new bean management methods that make this job easier
      • Need more information here; would be good to talk to Pete Muir about this
    • A good goal would be to allow JSF web apps to run as portlets unchanged
      • Mike did this with the JSR 329 JSF portlet bridge
    • A big question is about how to handle CDI @RequestScoped beans
      • Problem, since the portlet action request is separate from the render request.
      • Normally the beans would only be available in the actual request (action or render) in which they are injected
      • Portlets need the beans to live from the beginning of the action / event until the end of the render request
      • If the portlet container could redefine the meaning of @RequestScoped for portlets under the covers, it would be easier to migrate normal web apps to portlets
      • Neil contacted Pete to ask if it would be technically possible for the portlet container to redefine the meaning of @RequestScoped
      • However, redefining @RequestScoped might cause other suprises or difficulties for developers
    • One good point about the JSR 362 Ajax Proposal (alternate) is that @RequestScoped could work for the target portlet, since the action / render phases both execute within a single servlet request
      • However, that is not the case for portlets who have changed their render state due to events rather than due to the initial action
    • If we introduce a new scope for portlets rather than redefining @RequestScoped, it would mean more work to migrate JSF web apps to portlets, since the annotations would have to be changed
    • There might be a CDI extension that would allow us to redefine or change the annotations at deployment time
      • (Note: a quick rescan of the CDI 1.1 spec shows that the CDI container fires a ProcessBeanAttributes event before the bean is processed. During the event processing, the listener can apparently actually set the bean attributes, including the scope. This is tantalizing ...)
  • Discussion about the additional user / developer stories provided via mailing list post
    • Since the new stories sort of mix user stories with developer stories, it begs the question - is it valuable to strictly differentiate between end-user stories and developer stories?
      • Yes, it certainly is, and I actually tried to formulate real user stories, but got frustrated in trying to formulate them "user-like". At the point in time I wrote them, it was more important to get the gist jotted down, so they ended up being a motley mix of end user / developer stories. sorry.
    • Reproducing the list here to add comments:
      1. As a portal user, I want to view (GET) different data within a portlet without causing a full page refresh.
      2. As a portal user, I want to view (GET) different data within a group of coordinating portlets without causing a full page refresh.
        • 1 & 2: Possible with JSR 286 (render URL) or can be simulated through resource serving by using resource parameters on the resource URL to mask the actual render parameters (which may or may not be a good idea ...)
      3. As a portal user, I want to change (POST) data within a portlet without causing a full page refresh.
      4. As a portal user, I want to change (POST) data within a portlet and have that portlet and all coordinating portlets on the page update without causing a full page refresh.
        • 3 & 4: This is, I believe, the main use case for JSR 362 Ajax support
      5. As a portal user, I want to get help or change settings in a portlet without causing a full page refresh.
      6. As a portal user, I want to change the window state without causing a full page refresh.
      7. As a portal user, I want to use the back / forward buttons to move back and forth through updates on the portal page without causing a full page refresh.
        • (To the extent technically possible) Our Ajax solution should not hinder use of the back button more than the underlying browser / JavaScript / HTML technology does.
      8. As a portal user, I want to bookmark specific views of my portal page, even if those views were reached through Ajax requests.
        • (To the extent technically possible) Our Ajax solution should not hinder bookmarking more than the underlying browser / JavaScript / HTML technology does.
      9. As a portal user, I want to be able to jump back to previously viewed data quickly.
        • This implies use of caching (==> HTTP GET & render URLs or cacheable resource URLs) to the extent possible. Can be done with JSR 286 portlets today.
      10. As a portal user, I want to be protected from hackers. Nobody should be able to send me a link to a portal page that would cause harm (debit my bank account, for example).
      11. As a portal user, I want to be protected from mistakes (double submission of an action debiting my bank account, for example).
        • 10 & 11: I'm not saying we need to implement this, but we cannot create an Ajax solution that would prevent a portal from implementing these points. These points imply special handling for action URLs ("one time" action URLs), meaning that the action URL in a form needs to be refreshed after it is used. Can be done with JSR 286 portlets today.
    • If we were to decide to go with Ajax proposal 2b, we would have work to do, since prototyping shows potential difficulties in interoperation with JSF Ajax support
      • It would also almost certainly imply work on the bridge spec, if we want a standardized bridge (which I personally would prefer)

28 January 2014

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Neil Griffen
 x   Werner Keil
 x   Kito Mann
 x   Scott Nicklous
     Andrew Petro
     David Taylor
 x   Julien Viet
  • Neil presented an alternate proposal for the Ajax support
    • Neil, thank you very much!! this will really help further the Ajax discussion!
  • Page 1: illustrates basic scenario
    • Contains JSF portlet, Native portlet, & portlet using Jquery
  • Page 2: Describes user stories
    • Clear separation of user-oriented stories from development-oriented stories
  • Page 4: Figure 3.1 shows the portlet lifecycle for JSR 286 portlets
    • Suggestion: Update figure caption to more clearly indicate that the diagram has to do with the non-Ajax case
  • Page 4-5: Presents the portlet Partial Lifecycle
    • This is meant for Ajax support
    • Started when a Partial Action URL is activated
    • Runs through portlet Action & Event phases to set the new render state
    • Executes Partial Render for the target portlet
    • Returns markup for target portlet
    • Other portlets notified through broadcast event; each affected portlet retrieves markup from serveResource
  • Discussion:
    • What is isPartial() ... what needed, what does it mean, why not use parameter instead?
      • Means that the render phase is being executed as the result of a partial action
      • Marks the partial render case within the render() method so the developer can decide what type of markup to produce
      • Convenience for the developer
      • Make TCK tests easier to write, since isPartial() behavior can be specified & tested
      • Make the spec easier to write
    • Why does the proposal call for partial rendering to be carried out in the render() method for the target portlet but in serveResource() for the other affected portlets?
      • Wouldn't it be better to have a single method for partial rendering?
        • A portlet changing its render state through an event should be treated the same as a portlet changing its render state through an action
      • Will think about this; look for solution
    • How are public render parameters supported?
      • They can be sent during the Action / Event phases on the server
      • Need more throught for client support
    • Another advantage of this approach: fewer server round-trips, since markup for target portlet returned by action response
  • Section 6: Presents the JavaScript API
    • Similar to the JSF.js javaScript API
    • Contains methods for registration, carrying out the Ajax request
    • Portlet client can add an error handler, event handler
    • Portlet client can send events to all subscribed portlets using the broadcast event API
  • Section 7: Defines the portlet events
    • The PortletState event is sent out when the state of the portlet has changed
    • In order to have the PortletState event fired, the action target portlet must include JavaScript code in its resopnse to call the broadcast event method on the client
  • Section 8: Describes the partial response
    • Diagram 8.1 shows a real JSF partial response in XML format
    • We could decide on a different format such as JSON, if desired
    • The response format would need to be specified
  • Face-to-Face at the JavaLand conference (Ed): Loonls like no problem to get a room
    • Members of the EG can gain entrance w/o attending the actual conference
    • targeting 1 EG meeting on each day

21 January 2014

     Andy Bosch
     Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
     Michael Freedman
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
     Andrew Petro
     David Taylor
 x   Julien Viet
  • Discussed Ajax proposal
    • Neil is working on an alternate proposal, will present as soon as possible
    • Will go at it from a user story perspective - great approach!
    • If we can decide on user stories, we can more easily compare the solutions to see how they match the stories
    • Referring to previous discussion on Proposal 2b:
      • Is the exposure of the public / private render parameters a security exposure?
        • Don't believe so, since they can appear as query parameters on URLs today
        • In proposal 2b, the private parameters for each portlet are provided only to that portlet through the onStateChange callback method
      • Why do we need the createResourceURL function?
        • returns a "real" URL that can be used with any framework or with native JS to retieve data through resource serving
        • (add'l info addded after the meeting):
        • After the render parameters have been update, a new resource URL has to be generated containing the new render parameters in addition to any resource parameters provided in the createRenderURL call
        • If the cacheability is set to "PAGE" (which is the default) on the resource URL, the resource URL neeeds to contain the render state of the entire page
        • The Portlet Hub, which manages the page state, has the info to create resource URLs with cacheability = PAGE, but the individual portlets do not
        • Different portal implementations can generate URLs using differing mechanisms
        • For example WebSphere Portal uses compression & encoding techniques that a portlet develper cannot be expected to reproduce
  • Folks are still working on getting travel budget for attending the F2F
  • Would be great to close on Ajax support concept at JavaLand Conference in March
  • Target: Produce document for Early Draft Review by 30 April

14 January 2014

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
     Michael Freedman
 x   Neil Griffen
     Werner Keil
 x   Kito Mann
 x   Scott Nicklous
     Andrew Petro
 x   David Taylor
 x   Julien Viet
  • Mike Freedman retired from Oracle and thus from the JSR 362 EG.
    • Thank you very much for your great support and contributions! You will be missed ...
    • Ross Clewley, already a member of the EG, will be taking Mike's place
  • JavaLand Conference will take place March 25-26 in Brühl, Germany (near Cologne)
    • The venue will be Phantasialand
    • We want to have a face-to-face meeting during that conference
    • It would be possible to prsent our JSR at a adopt-a-JSR meeting
    • Ed will try to get people from our group into the conference
    • Ed will help organize a conference room, etc.
    • Discussion about length of F2F meetings ... 1 mtg each day 1-2 hours
      • Might be good to have 1 afternoon mtg (1st day) and 1 morning mtg (2nd day)
    • Pete Muir, CDI 1.1 spec lead, will be in attendance at the conference
    • Would be a good opportunity to talk to him about CDI support in portlets
    • Ed will talk on Tues 25 March at 4:00pm
    • Pete will talk on Wed 26 March at 3:00 pm
    • Would be good to schedule our meetings around those times
    • Adopt-a-JSR activity is planned at the conference
      • However, so far, no presence on the conference web site
      • Discussion about how to attract folks to participate
      • Most valuable / reliable help from JUG: Create sample apps for early beta RI
        • Have them create app with previous version & port to new version, showing off the new features

07 January 2014

     Andy Bosch
     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
  • 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
  • How would this model work with frameworks such as JSF?
    • One concern is that the approach lined out would make it difficult to implement a JSF portlet bridge or CDI bean support
      • Request-scoped beans have to be available across all JSF lifecycle phases, which means for portlets during both the portlet action request processing and during the rendering
      • JSF bridge support doesn't use the serve resource method, it depends on the portlet render method
      • With the proposal 2b, the beans would somehow have to be made available during portlet action processing and during the portlet serve resource processing - difficult to do.
      • Would be better from a JSF point of view if the Ajax action were followed by a partial page rendering
  • Another drawback of this approach is that JavaScript developers would expect to get markup back from the action rather than state that would then be used to obtain markup.
  • Summary of concerns relating to proposal 2b:
    • Difficult to write JSF portlet bridge using this approach
    • Difficult to provide support for CDI
    • Less intuitive programming model on the JavaScript side
  • Summary of advantages of approach 2b: (note: not all of these were mentioned during the meeting ... they occurred to me later, sorry)
    • Simplicity of portal & portlet hub implementation
      • No new portlet lifecycle methods needed on the server
      • Portlet hub code can be kept to minimal size
      • If we were to allow partial rendering, complicated logic would be needed on the server to partially render those portlets that are affected by the Ajax action
        • The portal would have to package the data from each portlet somehow and send it to the portlet hub
        • The portlet hub would need complicated logic to unpack the data and provide it to each portlet client
    • Better cacheability
      • Response to an HTTP POST method (the Ajax Action request) is generally not cacheable, since the POST method is non-idempotent
      • But the HTTP GET request to the portlet serve resource method can be cacheable, and the cacheability is under control of the portlet
    • Better data response flexibility
      • Data returned by a partial rendering would be limited to the MIME type of the portal response
      • But the MIME type of the serve resource response can be set by the portlet
  • Proposal 2b is coherent & correct, but concerns noted above should be taken into account
Difference compared to previous revision
** Better data response flexibility *** Data returned by a partial rendering would be limited to the MIME type of the portal response *** But the MIME type of the serve resource response can be set by the portlet * Proposal 2b is coherent & correct, but concerns noted above should be taken into account---- 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: ***# Portlet calls the JS action() method ***# Portlet Hub transmits stateful Ajax request to portal ***# Portal drives the action & event portions of the portlet lifecycle and returns the resulting new page state to the client. ***# 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 ***# 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": ***# JS code on client submits Ajax action request; ***# Portal drives the portlet lifecycle to completion with events, parameter changes, and everything; ***# Portal performs partial render for all affected portlets; ***# Portal transfers updated markup to client; ***# 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": ***# JS code on client submits Ajax action request; ***# Portal drives portlet lifecycle through Action & Event phases (but not Render!); ***# Portal returns new state (portlet parameters, portlet mode & window state) to client for all affected portlets; ***# JS code on client notifies each affected JS portlet of new state; ***# 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": ***# A new PartialActionURL is introduced into the portlet programming model; See: [ some JSF background info] ***# Forms submitted through this new type of URL; ***# Portal drives portlet lifecycle through Action & Event phase; ***# Portal renders (possibly through serveResource) target portlet only; ***# Markup for target portlet is returned to client; ***# JavaScript code that causes events to be fired on client to notify other affected portlets is added to markup by portlet programmer ***# 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 *** "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
Please Confirm