Skip to main content
This revision made June 03, 2014 08:43, 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.


27 May 2014

     Andy Bosch
 x   Edward Burns
     Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
     Andrew Petro
 x   David Taylor
     Julien Viet
  • Update on Apache Pluto RI - moved to git repository, ready to go
    • I have a few update to check in that will allow Pluto to be deployed on Tomee, will check in
    • However, not immediately, since there is a public holiday in Germany this week
    • One larger piece of work will be to rewrite the portlet TCK under the Apache license
      • The JSR 286 & JSR 168 TCKs were provided under Sun licensing terms and for that reason, they cannot be made available on Apache
      • For JSR 362, we want to have the TCK licensed under the Apache 2.0 license
      • So we need to re-implement the JSR 286 TCK in order to prove compatibility
    • But are we allowed to do so?
      • The original proposal for JSR 362 states "The Reference Implementation and TCK will be licensed under the Apache 2.0 license: http://www.apache.org/licenses/LICENSE-2.0.html "
      • The JSR process specifies that the spec lead must provide a TCK, but does not specify licensing terms
      • If we in the EG agree that we want one that is licensed under Apache 2.0, we should be able to do it
    • There is precedence for having the TCK available under a different license:
      • The JSR 329 JSF Portlet Bridge MyFaces reference implementation provides a TCK that is licensed under Apache 2.0
      • The CDI spec has its own TCK that is managed by the spec lead
    • Is there a way we could bootstrap TCK development?
      • Mike F. suggested that we might be able to reuse portions / structure of the JSR 329 TCK, since it is already licensed under Apache
      • The JSR 329 TCK is very nice, covers much, easy to use
      • Driven by Selenium & includes many (200+) individual test cases
      • If we reuse the JSR 329 TCK, maybe try to do it in such a way that test cases for the JSF portlet bridge can be added
    • Must discern between unit tests that verify an implementation from a TCK that tests spec compliance
      • For example, Mojarra has an internal automated test system for verification that is in some ways superior to the JSF TCK, but actually consists of internal unit / integration tests
      • There are numerous instances where internal implementation-specific tests are needed in addition to the TCK
  • Discussed serveResource
    • Some changes may be in order; revisit next meeting
  • Discussed Portlet State proposal
    • latest version available on github
    • incorporates feedback from within IBM
    • one point: names are a little long: ActionRequest#getActionParameters().getParameterValue() try to shorten
    • Will solicit additional comments next week
  • Mentioned that the latest JSR 362 API working document on github includes a Portlet Hub mock up
    • Contains many JavaScript test cases implemented with Jasmine; may be able to evolve these TCs or a subset of them to become part of the JSR 362 TCK
    • Please have a look; will discuss next week

13 May 2014

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
     Andrew Petro
 x   David Taylor
     Julien Viet
  • Decided to move the meeting slot up by 1 hour - new time: 4:30pm CET / 10:30am EST
  • Talked about Portlet State proposal
    • When can we start integrating into Pluto? Soon, working on it
    • Status on Pluto move to git repo - possible to move to git, just a formality, David will place the necessary infrastructure request
  • Discussed Ajax Slides #3d
    • On slide #15, the action() method does not show reference to form - needs to be updated
    • On slide #16, the PortletInit structure needs to be updated
    • (note: in the mean time, the portlet hub mockup was created, so the slides need to be updated again)
  • Discussed dependencies
    • Slide #17 in Ajax Slides #3d needs work
    • Goals:
      • provide way for portlets to declare system dependencies (JQuery, DoJo, CSS files ...)
      • Allow portlets to share dependencies
      • Prevent duplication of resources in head section
    • Have a look at JSF implementation for resource dependencies
    • JSF has no location or version attribute for dependencies
    • There are two aspects to be considered:
      • How the resources are laid out in the file system
      • How the app references the dependencies
    • JSF has already solved this point
      • Can be handled because JSF has a component tree
      • Application has to declare resource in markup
      • info for head section maintained as facet; When processing head section, JSF can make sure each resource only included once
    • JIRA issue PORTLETSPEC3-40 makes a proposal that would prevent duplication of resources in head section
      • Please comment on the issue
    • With non-streaming portals, it's a little difficult to use doHeaders
      • Performance impact since JSF lifecycle mus be executed twice - once for headers, once for body
  • Neil's state diagram presented last week was nice - which tool?
    • Used umlet ... works ok, but it is some work to make it look nice
  • Discussed WSRP opaque state & how to handle for portlet hub
    • Problem: private parameters set by the portlet running on the producer are stored in an opaque blob transmitted to the consumer, but the portlet hub needs to make the private parameters available to the portlet client on the browser
    • Proposed solution: The producer provides encode / decode methods (JavaScript module) for interpreting the opaque parameter object
    • Portlet Hub would need to be provided with these methods for each portelt client in order to decode the private parameters for the portlet client & encode them again if the P.C. makes changes
    • But how to transport the encode / decode methods to the Portlet Hub?
      • The producer could inject them into markup produced by the portlet
        • Might be OK if the methods are small
        • But it might be too dependent on how the portlet client handles its markup - what if the P.C. deletes the methods?
      • Would it be possible to transmit a URI to the methods or the methods themselves during the initial WSRP handshaking between consumer and producer?
        • sounds interesting; would be worth looking at the registration call
        • Might be possible to transmit a URI in the service description
      • The consumer would have to recognize the availability of the encode / decode methods and make them available to the portlet hub

06 May 2014

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
     Andrew Petro
     David Taylor
     Julien Viet
  • We considered moving the EG meeting forward by 1 hour. That would place the meeting at 4:30pm CET and 10:30am EST.
    • No members on the call objected. I will ask again in the 5/13 meeting and if there are no objections, I'll cancel the current meeting and invite everyone to the new meeting, which will take place 1 hour earlier.
  • Comment about eventing - Is the proposed Portlet Hub eventing mechanism tied in with the server-side portlet eventing model?
    • Currently, the Portlet Hub eventing is strictly client-side only. It is not tied in with server-side eventing
      • But at some point in the future, the Portlet hub eventing mechanism might be tied in with server-side eventing
      • Leave open for now
    • This can be confusing, as folks who know the portlet programming model well may naturally assume that the client eventing is tied in with the server-side eventing
    • Might consider changing the Portlet Hub method names in order to reduce the possibility of confusion
  • Portlet Hub method naming - Do we want to be consistent with server-side naming ("createResourceURL") or with JavaScript convention ("createResourceUrl")?
    • My take: since we are defining a JavaScript API, we should adhere to JavaScript convention
  • Discussed Ajax Slides #3d through slide #13
    • Comment: When a portlet uses an Ajax action, a partion action, or sets its portlet state, only portlets affected by the state change are notified. Other portlets are not notified.
      • This might be a problem if the back-end state (model) of a portlet changes. With a full-page refresh, the new back-end state would be taken into account even if the portlet state remains the same. But with the partial update idea on the client, the portlet would not be updated.
      • Portlets that expect frequent model changes (for example, a stock ticker portlet) may need to implement a polling mechanism
      • This might be an area where Web Socket support would be helpful. Web Socket is on the "ToDo" list - we need to discuss in the future
    • General comments on proposal #3d: looks great, nothing objectionable found so far.

29 April 2014

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
     Andrew Petro
 x   David Taylor
     Julien Viet
     
  • Neil walked us through state diagram showing JSF portlet partial action sequence inclding WSRP
    • In general, what needs to be done to have a JSF portlet work with WSRP?
    • JSR 329 JSF Portlet Bridge implemented BridgeRequestScope for maintaining state between Action / Render phases.
    • JSF portlet running as WSRP consumer would need BridgeRequestScope to maintain state of request scoped beans
      • JSR 329 implements this for Faces managed beans
      • Trickier to implement for CDI request scoped beans
      • But BridgeRequestScope assumes that the portlet on the consumer maintains a session, and in WSRP the producer maintains the session
        • How would the JSF state be maintained in this situation?
    • There is another WSRP impact as Ross noted on the mailing list.
      • Private parameters are transported from WSRP Producer to Consumer as a single, opaque object
      • This means that WSRP remote portlets would not work with the Portlet Hub concept, which calls for the private parameters of all portlets to be available
      • This issues affects the Portlet Hub concept in general
      • Need to talk about this during the next WSRP call on 8 May.
  • Went through Ajax Slides #3a
    • Tags existing Action URL as Partial Action; uses existing Action / Event / Resource phase processing; No WSRP impact
    • Requires server to implement new processing sequence but has minimal impact to portlet API as seen by developers
    • General comments:
      • Use single-ended arrows in diagrams to show message flow
      • Always put the Portlet Hub on the right-hand side
      • Add sequence numbers to text on diagrams to improve readability / allow matching sequence descriptions with diagram arrows & text
      • Like the idea of RenderData which is present in the proposal. Please leave it in.
    • Observation: the portlet Ajax support would add two new processing sequences to be implemented by the portlet container / portal server
      • Ajax Action: used by native portlets. Performs only Action & Event phase processing on server; returns resulting page state to Portlet Hub, which updates affected portlets.
      • Partial Action: used by JSF portlets. Performs Action, Event, & Resource phases on server; returns page state & render data to initiating portlet on the client. Initiating portlet must update Portlet Hub with new page state.
      • Server-side processing of the Action & Event phases is the same for both types of action
    • Overall design is very comprehensive. Looks like most use cases have been addressed
      • On the surface, it looks like all major problems have been effectively addressed
      • Now need proof-of-concept prototyping
    • Suggestion: think about adding support for Javascript eventing
      • add addEventListener(...) concept
      • add means through which the Portlet Client could fire its own events
      • But what would be the value add as compared to the eventing mechanism provided by the browser?
        • Browser eventing is tied to DOM events
        • Would be nice to have to have general-purpose event mechanism to allow Portlet Clients to pass events back and forth

22 April 2014

     Andy Bosch
     Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
     Andrew Petro
 x   David Taylor
     Julien Viet
  • Talked about Apache Pluto project - portlet container reference implementation
    • Be a good time to get started. Looks like we are far enough along to begin doing things
    • Could begin prototyping Ajax support & other API changes
    • How do we want to check things in? Do we want to create a branch? Could we move to GIT as repository
      • David will look into this
  • Went through Ajax Slides #3, which contains partial action request
    • There is a problem with the Partial Action idea if the initiating portlet fires events
      • The new page state won't be available until after event processing has completed, so it wouldn't be available during the actual partial action request processing itself
      • Could solve this by introducing a Partial Render phase that would run after events have been processed
      • Partial Render could potentially run for all affected portlets
      • It would be good if we could have more than one portlet participate in rendering.
      • See additional mailing list discussion on Partial Action / Partial Render here and here (among others).
    • The Partial Action idea would have a big impact on WSRP
      • Would have to model the new portlet requests / responses in WSRP to allow transport to remote portlets
    • There is another WSRP impact as Ross noted on the mailing list.
      • Private parameters are transported from WSRP Producer to Consumer as a single, opaque object
      • This means that WSRP remote portlets would not work with the Portlet Hub concept, which calls for the private parameters of all portlets to be available
      • Need to talk about this during the next WSRP call on 8 May.
    • Method name createActionUrl should be more aptly named createPartialActionUrl
    • Some points about how JSF handles Urls
      • JSF generates URLs for partial actions on the server, wouldn't need to obtain URL from Portlet Hub
      • For each partial action update, JSF updates hidden form field with new partial action URL
      • JSF resource URLs are stored in hidden form fields as well
  • Are there any plans to present portlet stuff at Apachecon in Europe in November?
    • Not presently ...

15 April 2014

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   Andrew Petro
     David Taylor
     Julien Viet
     
  • Neil presented ideas about an event-oriented approach for Ajax support
    • Page 2 shows a general 'addOnEvent' allowing Portlet Clients to add several event handlers, but doesn't allow an event type to be specified. How will the portlet client recognize what type of event was fired?
      • Each event handler will recieve all events. Each event handler must eveluate the event type to determine if the event is to be processed.
      • But doesn't this place a burden on Portlet Client developers? Wouldn't it be better to have either call-backs or define specific event types?
        • This conforms to prior art, since JSF does it this way.
      • Also using the word "event" is sort of a misnomer, because each Portlet Client subscriber will receive different, portlet-specific data. For example, don't want to provide private parameters meant for Portlet A to Portlet B as well, because there might be parameter naming clashes and other issues.
      • JSF provides a general event facility in order to be able to flexibly add capability. But JSF assumes it controls the whole page.
    • Page 3 shows an example where Portlet A initiates a request
      • The Portlet Hub sends an "actionParameters" event to collect data from all portlets. Each portlet can contribute data.
        • The data collected by the actionParameters event is transmitted to the server in the form of parameters in the URL query string
        • In Ajax Proposal 2, the individual portlets would set their parameters through use of the setPortletState function
      • The Portlet Hub passes the action URL to Portlet A through the "dispatchActionRequest" event
      • Portlet A prepares the request, possibly adding additional parameters to the URL.
        • Not sure that it is possible for a portlet to simply append aditional parameters to a URL in all cases. Some portals require special parameter encoding.
      • Portlet A uses the Portlet Hub "actionResponse" function as an on completion callback and dispatches the XHR
      • The Portal performs the action, generates the new page state
        • The Portal may optionally retrieve data from the serveResource method of each affected portlet and package that data into the response
        • The packaging of the page state and portlet data is in an implementation-specific format
        • Since the individual portlet controls the content type and character encoding in the serveResource request (a serveResource request may return text, images ... basically anything a servlet can return), the portal may have difficulty packaging all data together
      • The Portal transmits the new page state and optionally any data provided by the serveResource method of each affected portlet to the client
      • The Portlet Hub receives the action response exactly as it was sent by the server.
      • The Portlet Hub decodes the response and fires the 'actionRequestComplete' event for each affected portlet (Page 4)
        • The actionRequestComplete event passes portlet-specific state and render data (if available) to each affected Portlet Client
        • The actionRequestComplete event corresponds to the onStateChange call-back from Ajax Proposal 2
        • If the affected portlet is a JSF portlet, the JSF Portlet Bridge would use the functionality of jsf.js to decode the render data and update the DOM
        • In other words, it's possible to pass JSF-response-formatted data into the jsf.ajax.response function for interpretation.
        • Question that occurred to me after the meeting: But does jsf.js count on the request having been prepared by jsf.ajax.request?
    • Page 5 shows handling for JSF portlets
      • The JSF Portlet bridge would intercept the jsf.axjax.request and jsf.ajax.response methods in order to provide the functionality described on previous pages
    • The event-oriented proposal does not address the capability provided by the Ajax Proposal 2e setPortletState function
      • What if a Portlet Client needs to update a PRP or change portlet mode / window state?
  • I presented some new ideas about a partial action request
    • These ideas pick up and expand upon ideas that Neil proposed some time ago
    • These ideas are to be though of as additions to Ajax Proposal 2e
    • Primarily meant for use by JSF Portlet Bridge code
    • A partial action could be thought of as a resource request with action semantics
      • The partial action request would have the same capability for generating markup / content as the resource request
        • Markup would be returned only for the initiating portlet
      • But would in addition allow public & private parameters to be changed and events to be fired
        • Basically allows action-phase processing
      • A new server-side API would be provided that would allow the portlet to obtain the new page state for inclusion into the response data
      • The portlet would be responsible to transmitting the new page state to the client
      • The corresponding Portlet Client would be responsible for updating the Portlet Hub with new state data
      • The Portlet Hub would fire onStateChange events to each affected portlet client
  • Need to digest all of the info presented today. It feels like we are getting close to a workable solution for all types of portlets.
  • Looking forward to the meeting next week!

08 April 2014

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Neil Griffen
     Werner Keil
     Kito Mann
 x   Scott Nicklous
     Andrew Petro
 x   David Taylor
     Julien Viet
     
  • Talked about need for starting a JSR for a new version of the JSF Portlet Bridge
    • Liferay has volunteered to move the Bridge spec forward
    • Neil has emailed people in Oracle to sound out the proposal, but has not yet received an answer
    • Ross will try to obtain more information within Oracle
  • I've been looking at the JSR 329 MyFaces Apache Bridge as an educational exercise
    • Recommend not doing that, since it represents JSF 1.2 support with minimal additions ... very back-level compared to today's JSF technology
    • Recommend moving to a more mature bridge implementation such as the Liferay bridge that supports JSF 2.2
    • But there are licensing issues to deal with (for me within IBM, that is)
      • Liferay bridge is LGPL licensed; Mojarra JSF RI is "GPL with classpath extension" licensed
  • Neil presented some recommendations for the Ajax Proposal. See his mailing list post.
    • Purpose: align method naming with prior art as well as address some issues concerning JSF support through the Portlet Hub (see meeting minutes from last week, below).
    • See comments to the recommendations in this mailing list post.
      • The comments in the post above will not, for the most part, be reproduced in these minutes
    • Naming proposals:
      • Namespace all Portlet Hub functions. Suggestion: use namespace 'portlet', i.e. "portlet.register(...)", etc.
      • Use camel-case naming consistently, i.e. 'PortletId' instead of 'PortletID'
    • Look at Promises-oriented APIs
      • Programmer-friendly approach, easy to use
      • Excellent for JavaScript programming in a very reactive environment
        • However, it's questionable whether portlet programming really represents a reactive enviroment to such an extent as to warrant a Promises implementation
      • Have looked into promises to some degree - spec is difficult to implement, question as to whether cost of implementation would justify the usability gain
      • David will look into this in more detail
    • The JSF specification requires at a minimum the ViewState parameter to be encoded as a hidden form field in each JSF form.
      • This means that each JSF portlet on the page needs to contribute at a minimum its ViewState parameters when an action is executed
      • If the JSF portlets cannot contribute their ViewState, the portlet state would be lost
      • The "actionParameters" event proposed in the recommendations would allow each portlet on the page to contribute necessary data to the action request
      • The JSF Ajax module jsf.js does considerable work to prepare the request and analyze the response
        • JSF defines the response format as a well-defined XML document conforming to an XSD
        • jsf.js needs to (expects to) handle the JSF request-response sequence
    • According to the recommendations, the Portlet Hub would issue a "actionParameters" event to collect additional information from each portlet before an action, and would issue a "dispatchActionRequest" to the portlet initiating the action (if a listener is registered) in order to allow that portlet to handle the request / response, thus fulfilling JSF portlet requirements
      • But wouldn't that mean that the format of the information transmitted between the Portlet Hub and the Portal would need to be specified?
        • Don't believe it would need to be specified ... Neil will present some ideas in the next meeting
      • The JSF response extension element could be used for data destined for the Portlet Hub
        • Don't believe it would be necessary to use the extension element ... Neil will present some ideas in the next meeting
      • Wouldn't this approach preclude the use of WebSocket communication between the Portal and the Portlet Hub, at least for JSF portlets?
        • Yes it would, since jsf.js currently supports only XHR communication

01 April 2014

     Andy Bosch
 x   Edward Burns
 x   Ross Clewley 
     Boleslaw Dawidowicz 
     Kenneth Finnigan 
 x   Neil Griffen
 x   Werner Keil
     Kito Mann
 x   Scott Nicklous
 x   Andrew Petro
     David Taylor
     Julien Viet
  • Discussed Ajax Proposal 2e, which has monor changes compared to the previous document.
    • Main change compared to "Ajax Proposal 2d": Added error handlers to all methods that are meant to be called by Portlet Clients
    • General comments:
      • Looks like the right subject to be looking at; more and more demand from customers for Ajaxified applications
      • Basic design is good; still need to find a solution for JSF support
    • Question about onStateChange method - can the Portlet Hub call that method independently of an action() or setPortletState() call?
      • Yes. For example, the Portlet Hub will call onStateChange() after the Portlet Client registers itself in order to provide the Portlet Client with its initial PortletState and possible initial renderData
        • But that can be seen as a call in response to the register() call by the portlet ...
        • Still, there is nothing to prevent the Portlet Hub to spontaneously call onStateChange() for one or more Portlet Clients if there is a need to do so
        • If the Portlet Hub is implemented through use of Web Sockets, there would be nothing preventing the portal (for whatever reason) from pushing an update to public or private render parameter and/or render data to one or more Portlet Clients
      • Actual background of the question: think about Web Socket support
        • Say the portal server pushes some data through a Web Socket to the Portlet Hub for a particular Portlet Client. Could the Portlet Hub then call onStateChange() for the affected Portlet Client in order to pass the pushed data?
        • Yes, I don't see why not. Great use case ... hadn't thought of that!
        • We need to keep Web Socket support in mind when designing Ajax support for portlets
      • ICEpush technology does something similar to Web Sockets; Implementation is through long polling rather than by Web Sockets.
        • Experience with ICEpush shows that when a JSF portlet is updated in that manner, the JSF portlet may need to request data through serveResource rather than directly using data provided through ICEpush
        • This fits in well with the Portlet Hub concept, because the Portlet Hub could call the affected Portlet Client, providing it with new paraleters. The Portlet Client could then obtain a resource URL and retireve the necessary data.
    • So it looks like we might be able to use the Portlet Hub idea to provide Web Socket support in addition to the proposed stateful Ajax suport for portlets. Some thoughts (which occurred to me after the meeting ...):
      • Since the Portlet Hub implementation and communication between the Portlet Hub & the portal itself is implementation-specific, a vendor could choose to implement it through Web Sochet technology
      • If we want to provide Web Socket support through the Portlet Hub idea, we might need to define additional APIs on both the client and on the server.
        • Client: We can use the onStateChange callback method to provide the Portlet Client with data sent by the host. However, the Portlet Hub action() method as it is defined today is very portlet parameter / form submission oriented. We might need another method to allow arbitrary data to be sent.
        • Server: We would need to define an API that would allow a portlet to obtain the server end of the Web Socket in order to allow it to send & recieve data to the Portlet Client. Need to give some though to this.
        • However, if we define our own APIs to encapsulate the Web Socket interface, we would have the problem of updating those interfaces to accommodate new / changed Web Socket functionality.
        • It might be better for the portlet spec to provide a mechanism through which portlets and their corresponding Portlet Clients can obtain a Web Socket connection rather than defining the actual communication APIs in order to mimize coupling to the Web Socket spec.
        • I think that before we can make real progress concerning Web Socket support, we (or at least I) need more knowledge about the Web Socket API, and maybe do some prototyping.
    • Discussion about the need for all portlets to transfer parameters back to the server (topic from last week) is ready to be discussed. Neil can present this.
      • We wanted to talk about this at the end of the meeting, but the other discussion took too long - sorry!!
      • I would say that this item should be the first topic of discussion next week.
    • Would we be open to certain naming changes for the Portlet Hub API?
      • Certainly. If there are better names, let's use them.
  • We discussed the possibility of allowing a 3rd party (for example, a portlet bridge) to plug an alternate communication mechanism into the Portlet Hub
    • The basic idea would be to define a service provide interface for this purpose. The JSF portlet bridge and/or a framework library would use this interface to install its communication mechanism.
      • A closure could be passed the PortletHub to perform the communication
      • This would allow the Portlet Hub to delegate the actual communication with the server to the communication mechanism provided through a closure
    • Background: To provide JSF support, it would be good to find a way to allow existing JSF.js modules to be used, and allow such modules to perform the actual communication.
      • Some JSF library vendors (RichFaces?) intercept the jsf.ajax.* methods with their own in order to provide additional functionality
      • Some JSF library vendors replace the entire jsf.js module with their own in order to provide additional functionality
      • jsf.js does not provide an API for processing partial response data obtained from other sources (for example, through the renderData object of the onStateChange() method or through use of a resource URL).
      • The big question is who "owns" communication with the server; who gets 1st crack at the response?
    • Conceptually, The Portlet Hub abstracts stateful communication with the server away from the Portlet Client developer.
      • The Portlet Client uses the Portlet Hub API for stateful communication
      • With the idea of an SPI, the idea is to allow a proxy to be inserted between the Portlet Hub and the Portal
    • The Portlet Hub wants control of action execution for a number of reasons:
      • The action is a blocking interaction since it changes the state of the portal page. The portal can't accept a new action request until the previous one completes. The Portlet Hub can enforce that blocking.
      • For security reasons to allow a portal implementation to use one-time action URLs
      • It needs to interpret the response from the server to determine the new page state, so that it can distribute changed portlet state / render data to the affected Portlet Clients
      • A Portlet Hub installation might potentially need multiple communication sequences to obtain all required data for a given action
      • The Portlet Hub needs to be able to respond to an action() call by doing a full-page refresh at its descretion - for example, in order to support incompatible portlets on the page
    • Can we make the SPI idea work somehow?
      • JSF specifies the data structures transferred between client and server, so it would be possible for a JSF portlet bridge to completely implement its own jsf.js support
      • But this would not solve the problem of supporting 3rd party JSF libraries like RichFaces or ICEfaces
      • Considerations to take into account regarding the idea of an SPI
        • How would this fit in with a potential Web Socket implementation of the Portlet Hub? We wouldn't want to define anything that would be XHR oriented.
        • This would speak against the idea of having implementation-specific communication between the Portlet Hub and the portal. We would have to define the data structures used for communication.
        • Would the SPI be installed on a per-installation or per-portlet basis?
          • You might have two portlets on the page, one based on JSF, and another based on a different FW that also wants to install its own communication plug-in. Which one would win?
          • It would be bad if the communication module used depended on initialization order of the Portlet Clients
          • So we might need a per-portlet plugin definition ... makes things much more complex.
      • Would it be possible to provide JSF support without adding a communication SPI? (these are a few of my ideas after the meeting)
        • It would be possible to transfer the JSF partial response data from the portal through the Portlet Hub to the Portlet Client either using the renderData object of the onStateChange() callback function, or by obtaining a resource URL and getting the data through serveResource
        • It seems to me like it should also be possible for a JSF Portlet Bridge solution to implement its own JavaScript module providing the required jsf.ajax.* methods.
          • That Bridge JavaScript module could use the Portlet Hub API to carry out the action and obtain the partial response data
          • It could then update the JSF portlet(s) appropriately (although it's clear to me that it would be a lot of work and that there might be compatibility issues)
  • How to proceed ...
    • Work out a good solution for JSF support
    • Got Pluto running on Tomee ... may provide basis for prototyping work
  • High-Level summary of where we stand on Ajax support
    • Good proposal, we are on the right path.
    • Still need to work out good solution for JSF support
  • Good meeting ... thanks for your participation!
Difference compared to previous revision
<span>=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. ---- <span style="text-decoration:underline;color:green">27 May 2014 Andy Bosch x Edward Burns Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan x Neil Griffen Werner Keil Kito Mann x Scott Nicklous Andrew Petro x David Taylor Julien Viet * Update on Apache Pluto RI - moved to git repository, ready to go ** I have a few update to check in that will allow Pluto to be deployed on Tomee, will check in ** However, not immediately, since there is a public holiday in Germany this week ** One larger piece of work will be to rewrite the portlet TCK under the Apache license *** The JSR 286 & JSR 168 TCKs were provided under Sun licensing terms and for that reason, they cannot be made available on Apache *** For JSR 362, we want to have the TCK licensed under the Apache 2.0 license *** So we need to re-implement the JSR 286 TCK in order to prove compatibility ** But are we allowed to do so? *** The original proposal for JSR 362 states "The Reference Implementation and TCK will be licensed under the Apache 2.0 license: http://www.apache.org/licenses/LICENSE-2.0.html " *** The JSR process specifies that the spec lead must provide a TCK, but does not specify licensing terms *** If we in the EG agree that we want one that is licensed under Apache 2.0, we should be able to do it ** There is precedence for having the TCK available under a different license: *** The JSR 329 JSF Portlet Bridge MyFaces reference implementation provides a TCK that is licensed under Apache 2.0 *** The CDI spec has its own TCK that is managed by the spec lead ** Is there a way we could bootstrap TCK development? *** Mike F. suggested that we might be able to reuse portions / structure of the JSR 329 TCK, since it is already licensed under Apache *** The JSR 329 TCK is very nice, covers much, easy to use *** Driven by Selenium & includes many (200+) individual test cases *** If we reuse the JSR 329 TCK, maybe try to do it in such a way that test cases for the JSF portlet bridge can be added ** Must discern between unit tests that verify an implementation from a TCK that tests spec compliance *** For example, Mojarra has an internal automated test system for verification that is in some ways superior to the JSF TCK, but actually consists of internal unit / integration tests *** There are numerous instances where internal implementation-specific tests are needed in addition to the TCK * Discussed serveResource ** Some changes may be in order; revisit next meeting * Discussed Portlet State proposal ** latest version available on github ** incorporates feedback from within IBM ** one point: names are a little long: ActionRequest#getActionParameters().getParameterValue() try to shorten ** Will solicit additional comments next week * Mentioned that the latest [http://msnicklous.github.io/portletspec3/apidocs/index.html JSR 362 API working document] on github includes a Portlet Hub mock up ** Contains many JavaScript test cases implemented with Jasmine; may be able to evolve these TCs or a subset of them to become part of the JSR 362 TCK ** Please have a look; will discuss next week ---- </span>13 May 2014 Andy Bosch x Edward Burns x Ross Clewley <span>
 
 
Close
loading
Please Confirm
Close