|<< Back to previous view|
[PORTLETSPEC3-31] Provide a mechanism to automatically copy render parameters to the StateAwareResponse during action requests and event requests Created: 31/Jul/13 Updated: 16/Aug/13
|Component/s:||Ideas for JSR 362 Extensions|
|Remaining Estimate:||Not Specified|
|Time Spent:||Not Specified|
|Original Estimate:||Not Specified|
|Participants:||andre.hagemeier, msnicklous and Neil Griffin|
A common portlet programming use case is to copy the render parameters representing the portlet state from the ActionRequest or EventRequest to the ActionResponse or EventResponse (StateAwareResponse), respectively. To improve the portlet API usability, a mechanism should be implemented that would allow the render parameters to be automatically added to the StateAwareResponse to that programmers would only need to set parameters to reflect the changes that need to take place due to action or event request handling.
This represents a break compared with the JSR 286 programming model, so a runtime option to control this behavior should be added as well.
Use of this parameter would make migration of JSR 286 portlets to the JSR 362 programming model easier.
We would need to decide on the default setting for this parameter.
1) On the one hand, the portlet container could recognize the portlet version based on the deployment descriptor. The portlet container could (logically) set the parameter to TRUE when a JSR 362 portlet is loaded and to FALSE when a JSR 286 portlet is loaded. For the migration case where a major JSR 286 portlet application is migrated to JSR 362 in order to use new features, but it would be too much work to change the parameter handling, the programmer could explicitly set the runtime setting to FALSE in the deployment descriptor to facilitate migration.
2) On the other hand, an experienced portlet programmer might not realize that there is a major difference in this area, and be completely surprised and irritated by the new behavior. To prevent such surprises, it might be better to have the default setting to always be FALSE, and allow programmers who wish to take advantage of the new behavior to explicitly set the runtime option in the deployment descriptor to TRUE.
|Comment by andre.hagemeier [ 31/Jul/13 05:29 PM ]|
Generally I would always favor stable backwards compatibility over new features, but in this case I'd vote for 1. As Scott stated, the container could evaluate the portlet version and it the behavior could be overridden with this parameter. If a developer gets surprised by this new behavior while intentionally developing a jsr362 portlet, it would be about time to read the spec.
|Comment by Neil Griffin [ 06/Aug/13 03:03 PM ]|
+1 for option #1. Moving forward, I think we should consider enabling new Portlet 3.0 features by default when the portlet.xml descriptor indicates "3.0" or higher. Developers would have to disable container-runtime-options in order to get backwards compatibility.