Skip to main content
Last updated April 17, 2014 09:40, by Martin Scott Nicklous
=Expert Group Meeting Minutes - Archive: Minutes up to 1 April 2014 ---- 25 March 2014 Andy Bosch Edward Burns Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan x Neil Griffen Werner Keil Kito Mann x Scott Nicklous x Andrew Petro David Taylor Julien Viet * I was unable to attend the Javaland conference and planned F2F meetings. ** This was due to IBM internal reasons ** We'll have to find a way to make progress without the F2F * Discussed platform for RI (Pluto) ** Might be good to have the RI on a platform that provides JavaEE web technology (esp. JSF & CDI) if the portlet standard embraces these technoogoes more closely ** Looked at Tomee, since that platform provides JavaEE Web Profile implementation *** Tomee provides MyFaces JSF and OpenWebBeans CDI, which are non-RI Apache implementations of those technologies *** Got Pluto to run on Tomee, but problem with test suite *** Does Liferay work on Tomee? **** Liferay portal will run under Tomee **** However, JSF portlets under Liferay on Tomee run on Mojarra JSF packaged in portlet WAR file **** Mojarra Servlet Context Listener needs to be registered for each servlet context ** Another possibility might be Glassfish *** Glassfish uses Mojarra JSF and Weld CDI, the reference implementations of those technologies ** A further possibility would be WebSphere Liberty Profile *** Provides MyFaces JSF and OpenWebBeans CDI, which are non-RI Apache implementations of those technologies *** Very nice, fast implementation; people are excited about it * Discussed portlet objects for CDI ** See mailing list post [ CDI Ideas for Portlets] *** Making portlet objects available through CDI would be a good idea *** "Bean-like" portlets - define annotations to allow definition of portlets potentially w/o extending GenericPortlet and with a minimal portlet.xml file **** Might be able to use CDI infrastructure, or may be a CDI-independent implementation. Needs prototyping / investigation. **** Do we need to define this in the spec? Might be better to leave this as a platform-specific add on. Some might want to use Spring rather than CDI **** Spring already does annotations for portlets, why do we need this in the spec? **** But portlets target a JavaEE platform, should fit in well with JavaEE technology. Supporting CDI would go in this direction **** Whatever we define should not hinder the use of Spring or other technologies * Discussion about spec content (philosophy) ** xmp JSF: JSF harvests the best ideas from the industry and incorporates them into next version of the spec ** Standards are not about innovation, they are about specifying common functionality across implementations * Would it be useful to have more frequent meetings? ** So far this year, the blocking factor has not been EG meeting frequency ** For now, I would not define another fixed weekly meeting ... maybe set up additional meeting in special cases * Discussed [ Ajax Proposal 2d] ** This proposal allows data to be returned by the server in the Action response ** Goes in the right direction ** Potential difficulty: if Ajax portlet is on the page that does not participate in IPC, it might lose its state. May need additional mechanism to send portlet state from all portlets to server. *** (Comments after the fact): I'm not sure I understand the problem here ... The URLs used by the portlet hub action() method and generated by createResourceURL() contain the complete page state as represented by the aggregated render parameters, window state, and portlet mode for all portlets on the page. * Some questions / comments about JSF ** To what degree is JSF.js standardized? *** Both the JS API and the Request / Response to the server are standardized. *** Implementations may add additional implementation-specific parameters ** But is there interoperability testing? can one expect a jsf.js impl from one vendor to work with the server from another vendor? *** ... don't know. ** Is it possible to execute Ajax requests by another mechanism (for example, native XMLHttpRequest or JQuery) in parallel to jsf.js operation? *** Experience shows that jsf.js works well in parallel with other Ajax mechanisms. ---- 4 March 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 David Taylor Julien Viet * Neil provided a CDI portlet example on [ Github portletbox] ** Thanks, Neil! ** See "demos" directory & its "CDI-portlet-bridge-compat" & "cdi-portlet" subdirectories ** Uses Weld 1.0. Due to the version, certain compatibility code was necessary. This code is contained in a separate module "CDI-portlet-bridge-compat". ** Weld version story: Weld 1.0 & 1.1 implement CDI version 1.0, while Weld 2.0 implements CDI 1.1 ** Later CDI implementations such as Weld 2.0 are much more developer friendly - reduces / potentially eliminates need for compat layer ** Interesting: Another open-source CDI implementation is available - [ CanDI], which is a CDI implementation for Resin * Talked a bit about [ Tomee] ** Apache project, open source Java EE 6 certified web profile (Tomee v1.6.0) ** Ships MyFaces JSF impl & OpenWebBeans CDI implementations (both are Apache projects) *** Background: MyFaces contributed by company Irian. Very well-written code. Fine implementation with many performance improvements ** Seems to work well ** However, difficulties were experienced getting JSF portlet bridge working on MyFaces *** Maybe MyFaces has not been adequately tested with portlets ** When we move toward a reference implementation, might be good to have Pluto running on Tomee in order to take advantage of built-in JSF & CDI support * Discussed how @RequestScoped bean works when page addressed through render URL or after simple page refresh ** JSR 329 Bridge introduced idea of "bridge request scope" which allows managed beans to be created during the protlet action phase and used during subsequent render phases ** Once created during portlet action, bean lives in pseudo-session (PortletContext, I believe) until next action, it times out, or is thrown away due to too many beans being stored ** Why was bridge request scope introduced in JSF portlet bridge rather than in JSR 286 spec? *** There was a lot on the plate for JSR 286, scope question fell off the plate *** Bridge rquest scope addresses JSF managed beans; it is inherently tied in with JSF; therefore argument could be made that it belongs in the bridge spec ** CDI scope is actually more of a portlet problem rather than a bridge problem, since CDI beans can be used without using JSF *** The base JSR 362 spec should define any CDI scopes found to be necessary ** Use cases for Bridge Request Scope **# Have request scoped bean live from action phase to render phase **# Have bean live long enough for page re-rendering due to updates of other portlets ** But how does bridge request scope work if page refreshed or render URL clicked? *** The JSR 329 bridge contains an algorithm that looks up beans depending on URL & other info *** not exactly sure ... Neil will test *** results of Neils test - thanks for being so quick! ... :-) **** Performed the following test with the JSR 329 BridgeRequestScope: ****# Added to JSF portlets (Portlet A and Portlet B) to a single portal page ****# Filled out the form of Portlet A and clicked submit ****# Filled out the form of Portlet B and clicked submit ****# Observed that the form field values of Portlet A were preserved due to the BridgeRequestScope ****# Reloaded the page via RenderURL ****# Observed that the form field values of both Portlet A and Portlet B were reset (BridgeRequestScope lost) *** Summary: Bean still available when page reloaded due to page refresh or update of other portlet; Bean lost (or not created) when page accessed through render URL ** Discussion about JSF Portlet Bridge spec *** We should assume that updates will be made in some manner; Don't inhibit JSR 362 work by forcing things to work according to old bridge spec *** Various potential solutions to the problem of getting the bridge spec updated **** Could start a new bridge spec JSR - argument: "keep with tradition" ... JSR 329 spec, RI, TCK already exist as [ Apache MyFaces Portlet Bridge] project, we could build on that base **** Bridge spec could be assimilated by JSF spec - argument: JSF spec address servlets, so it should address portlets, too. **** Bridge spec could be assimilated by portlet spec - argument: Portlet spec addresses JSP base technology, should address JSF base technology, too. **** So there are various ways it could get done. For now, we should assume it will get done ... somehow. * Discussed new [ Ajax Proposal #2C] ** Very similar to 2b, with PortletHub, etc., but adds ability for portlet to obtain data directly after action is executed ** Changes compared to previously-discussed Proposal 2b: *** Slide #3 "Portlet Hub Interface - Methods" shows all changes **# Added onErrorHandler to PortletHub register() method. This is a Portlet Client call back method celled mby the PortletHub when an error occurs **# Added formElement to PortletHub action() method. This corresponds to the "source" parameter in the portlet.ajax.request method of the [ alternate Ajax proposal] (see section 6, page 9 of proposal) **# Added cacheParm parameter to PortletHub createResourceURL() method. Allows portlet JavaScript developer to set cacheability option on resource URL. **# Added responseData object to onStateChange callback method. **** Present only for portlet initiating the action / stateful Ajax request **** Contains data corresponding to that which would be obtained from serveResource with current render state & cacheability set to "PAGE" **** Optional part of spec - a portal implementation MAY implement this **** RequestData Data structure tbd - initial idea shown on page #5 of slide deck ** Comments: *** Concern with making the responseData object optional. Experience shows that such optional portions of the spec easily lead to incompatibilities between implementations **** Would it be possible to add flag to allow developer to choose whether data should be provided through this mechanism? **** Maybe set flag in portlet.xml or maybe allow JavaScript programmer to specify flag when executong action() **** Furthermore, if flag was introduced in appropriate manner, could potentially be used by any portlet affected by the stateful Ajax request, not just by the portlet initiating the action ***** Since PortletHub implementation is part of portal implementation & is considered to be a black box, one portal vendor might choose to pack data for all portlets together in one response for transport to the client, while another portal vendor might choose to make individual serveResource calls to obtain the data. *** Likely get pushback due to having JavaScript developer deal with / create resource URL **** Rationale behind createResourceURL(): JavaScript developer can use this call to get a resource URL, use any JavaScript library (JQuery, DoJo, ...) to do the actual Ajax request & process response. *** onErrorHandler is a nice addition * Talk about schedule ** Will we get done with JSR 362 Spec, RI, & TCK in 2014? ** There is still hope if we can get major decisions on Ajax support made during the F2F or soon after ** Other items such as Servlet 3.1 alignment should be more clear-cut ** How can we accelerate progress? More frequent calls? to be discussed. * I know it's bad timing, but I will be out of the office for the next two weeks, so the next two meetings will be cancelled. * See you at the F2F on 25 & 26 March! ---- 25 February 2014 Andy Bosch Edward Burns Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan Neil Griffen Werner Keil Kito Mann x Scott Nicklous Andrew Petro David Taylor Julien Viet * Discussed the F2F meeting during the JavaLand Conference ** The meeting times will be 13:00 - 15:00 Tuesday 25 March & 09:00 - 11:00 Wednesday 26 March * Discussed CDI Scope ** Would be good to have a look at the JSR 329 Bridge Spec - it lists the requirements very well ** If we have an action-to-action scope, what happens when someone clicks on a render URL? *** May cause a memory leak until the A2A bean is released ** Would be good to have at least a PortletRequestScope, as discussed on 11 Feb * Can CDI Beans be recreated based on render parameters & other info the portlet has at it's disposal? ** CDI scope defines how long beans will be available ** Use of scope is up to the developer ** If we define a new scope, we might make it an optional feature ** There can be potential problems with clustering / farming scenarios ** Can CDI conversational scope be used instead of creating a new scope for portlets? ** In any case, developers should be allowed to use conversation scope ** Defining a portlet-related scope might be a convenience for developers. *** Save developers the trouble of figuring out how to make beans exist in portlet environment with conversation scope *** Would be good to at least have something like a @PortletRequestScoped annotation to save beans from action to render phases in a post-redirect-get environment *** Many parts of Java EE are introducing special scopes & adding CDI support *** Looks like CDI is here to stay ... we should probably support it ** These would be good questions for Pete Muir / Ken Finnigan ** CDI performance questions *** A lot of code / a lot of reflection done in CDI container# *** In this matter similar to Spring, which uses reflection extensively as well *** There is some performance impact *** The initial implementation was slow; later implementation much better *** Experience with larger projects shows acceptable performance * Great new feature in JSF 2.2 - Flow Scope ** Beans exist for life of flow between JSF panels ** Similar to conversation scope, but it works automatically ** Flow is associated with browser tab, can have different flows going on different tabs ** How is flow scope handled if user abandons a flow? *** User clicks "start over" link - flow scoped beans can be cleaned up *** User navigates to different page - not sure. Maybe timeout? * Discussed Ajax proposal ** Good to approach CDI question along with Ajax question as they are related, esp through JSF ** Might be good to question EG members & other users on how important it is to get data directly as result of action ** Major differences between the proposals currently on the table: *** Response to action provides markup directly as opposed to response to action provides new state information and portlet needs to retrieve data on its own *** Action processing on server uses render method as opposed to using serveResource **** Might be acceptable to use serveResource, even though it would require a bridge / bridge spec update. ---- 11 February 2014 x Andy Bosch x Edward Burns Ross Clewley Boleslaw Dawidowicz Kenneth Finnigan x Neil Griffen x Werner Keil Kito Mann x Scott Nicklous Andrew Petro David Taylor Julien Viet * Discussed CDI Support for portlets ** If we define a CDI scope for portlets, how would it work in a cluster / farmin scenario? *** Scope concepts implemented in JSR 329 JSF Portlet Bridge have no awareness of cluster *** CDI Session scope is abstraction on top of HTTP session. Is replicated if session is replicated ** CDI 1.0 works with Pluto portlet container *** Have to add CDI Jars as they are not provided by underlying Tomcat *** Some work is necessary - basically need to wrap HTTP servlet Request & Response with compatibility layer to make it work *** Portlet developer needs to do some configuration work * Idea about implementing portlet request scope ** Define a new scope ... something like @PortletRequestScoped that would save beans created during the action phase so that they would be available in the render phase ** Goal would be to have JSF / CDI apps that use request scoped beans to run as portlets unchanged ** Would be possible to listen for event on CDI startup when beans are loaded and change annotations on the fly ** Change @RequestScoped beans to @PortletRequestScoped on the fly ** If new @PortletRequestScoped is defined, it needs to be documented *** Maybe in the JSF Portlet Bridge spec *** However, CDI can be used without JSF, so it most likely would belong in the Portlet Spec ** But this could be complex, as the CDI spec defines other times when @RequestScoped beans must be available (EJB invocation, web Services, etc), and this would have to be mirrored in a potential @PortletRequestScoped support ** Would also be possible to just redefine the behavior of the current @RequestScoped annotation *** But this could lead to difficulties in the implementation as well as misunderstandings among portlet developers *** Better to define a @PortletRequestScoped annotation * Use of JSF without storing data in session ** Is possible, developer must be very careful ** State can be stored on client (but not for JSF portelts), but even so, key is stored in session * Thoughts on JSF ** As consultant / developer, size of session is often #1 concern ** Not only the beans, but also the component tree plays a role ** Easy to create big, complex app with big component tree and corresponding large session size ** However, if app is designed well with session in mind, not too bad ** There is much ongoing work to reduce JSF session requirements *** Partial state saving is default since JSF 2.0. Only necessary data is saved, rest is recreated from xhtml file *** JSF 2.2 allows programmers to declare "stateless" JSF pages **** However, developers need to take some care in order to make it work *** Important parameters for performance tuning: **** # views in session. Often set to too large a value, resulting in overly large session size **** # logical views. Often set to too large a value, resulting in overly large session size * Ajax support in JSF ** Very nice fit for portlets ** How to allow information to be pushed to the client? *** PrimeFaces provides PrimePush technology based on Atmosphere framework *** Allows updates to be pushed to the client *** Based on WebSockets; could also be implemented using polling ** Do JSF portlets use eventing? *** Yes, client-side eventing using pub-sub system *** However, little / no server-side portlet eventing ---- 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: **# As a portal user, I want to view (GET) different data within a portlet without causing a full page refresh. **# 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 ...) **# As a portal user, I want to change (POST) data within a portlet without causing a full page refresh. **# 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 **# As a portal user, I want to get help or change settings in a portlet without causing a full page refresh. **# As a portal user, I want to change the window state without causing a full page refresh. **# 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. **# 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. **# 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. **# 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). **# 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
Please Confirm