<< Back to previous view

[PORTLETSPEC3-24] GenericPortlet.doHeaders(RenderRequest, RenderResponse) should throw javax.portlet.PortletException Created: 14/May/13  Updated: 10/Oct/13

Status: Reopened
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Neil Griffin Assignee: msnicklous
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: msnicklous and Neil Griffin

 Description   

In order for a JSF 2 portlet to work in a streaming portal, the JSF lifecycle must be run from the GenericPortlet.doHeaders(RenderRequest, RenderResponse) method in order to determine the JSF 2 <script> and <link> resources that are to be included in the <head>...</head> section of the rendered portal page.

Unfortunately the signature for GenericPortlet.doHeaders(RenderRequest, RenderResponse) does not throw an exception, so if there is a problem running the JSF lifecycle, there is no way report any exceptions other than by printing the stacktrace or throwing a RuntimeException.



 Comments   
Comment by msnicklous [ 24/Aug/13 07:49 PM ]

Resolved this by adding IOException and PortletException to the method signature. The method doHeaders() now has the same documented exceptions as the related doDispatch(), doView(), doHelp(), and doEdit() methods that can be called during render() processing.

Also corrected a number of typos and missing/falsely named closing HTML tags that were adversely affecting the javadoc page formatting for the GenericPortlet class.

Comment by msnicklous [ 10/Oct/13 02:29 PM ]

I think we should talk about this one again. I got feedback that adding "throws IOException, PortletException" to the GenericPortlet.doHeaders(RenderRequest, RenderResponse) method would be an incompatible change that would break existing portlets (binary incompatibility). We probably shouldn't do that.

As an alternative, we might want to introduce a new method with a different signature like maybe:

GenericPortlet.doHeaders(HeaderRequest, HeaderResponse) throws IOException, PortletException

to accomplish the goal of allowing exceptions to be thrown.





[PORTLETSPEC3-40] Add new javax.portlet.ResourceComparator annotation in order to identify duplicate resources Created: 13/Dec/13  Updated: 14/Jan/14

Status: Open
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Neil Griffin Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kito75 and Neil Griffin

 Description   

I would like to propose the following annotation, which
would allow portlet developers (and JSF portlet bridge implementors)
to provide a way to inform the portlet container of duplicate
resources. This is a common problem with JSF portlets, since each
JSF portlet on the portal page needs the "jsf.js" resource:

package javax.portlet;
/**
* Annotation for marking a class that compares resource URLs. Such classes are
* discovered by the portlet container at startup and are required to
* implement the {@link java.util.Comparator} interface in order to compare
* resources represented as type {@link java.lang.String}. If the
* {@link java.util.Comparator#compare(Object, Object)} method returns 0, then
* the portlet container will consider the resources to be identical and will include
* only the first resource in the &lt;head/&gt; section of the rendered portal page.
*
* @since 3.0
*/
@Target(ElementType.TYPE)
@Retention(RetentionPolicy.RUNTIME)
public @interface ResourceComparator {
}

Here is an example that a JSF portlet bridge could use in order to prevent duplicate JSF resources:

public interface FacesResource {

	public enum TYPE {
		HREF, LINK, SCRIPT
	}
	
	public TYPE getType();
	
	public String getName();
	
	public String getLibrary();
}
@ResourceComparator
public class FacesResourceComparator implements Comparator<String> {

	public int compare(String resourceURL1, String resourceURL2) {

		if (isFacesResource(resourceURL1) && isFacesResource(resourceURL2)) {
				
				FacesResource facesResource1 = new FacesResourceImpl(resourceURL1);
				FacesResource facesResource2 = new FacesResourceImpl(resourceURL2);

				if (facesResource1.equals(facesResource2)) {
					return 0;
				}
				else {
					return -1;
				}
		}
		else {
			return -1;
		}
	}

	protected boolean isFacesResource(String url) {
		return ((url != null) && url.contains("javax.faces.resource"));
	}
}


 Comments   
Comment by kito75 [ 14/Jan/14 05:28 PM ]

Sounds good to me. Would we need a default implementation?





[PORTLETSPEC3-11] Create single interface to handle public and private render parameters Created: 03/May/13  Updated: 30/Jul/13

Status: Open
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: julien_viet, msnicklous and Neil Griffin

 Description   

The StateAwareResponse and BaseURL interfaces both allow setting and getting public and private render parameters.
However they use different method names to do the same job. I suggest introducing a new interface that
represents the aspect of handling parameters and to have both the StateAwareResponse and the
BaseURL interfaces extend this new interface. This would make it much simpler to write state handling code,
and would make it easier to keep the semantics consistent.



 Comments   
Comment by msnicklous [ 06/May/13 06:36 AM ]

Updated the problem priority to "minor" from "major" ... corrected an oversight on my part.

Comment by julien_viet [ 10/May/13 08:26 AM ]

I don't see how that is technically possible since:

1/ StateAwareResponse class has methods named "render parameter" such as setRenderParameters(String key, String value)

2/ BaseURL class has methods named "parameter" such as setParameter(String name, String value)

Comment by msnicklous [ 13/May/13 12:15 PM ]

We would have to include both setRenderParameters and setParameters in the new interface, and deprecate one of them. The point is that the parameters don't really differ conceptually (at leaset as I understand it so far), so we shouldn't have two different method names for setting / getting the same thing.

Comment by Neil Griffin [ 14/May/13 03:07 AM ]

I like the idea of a separate interface very much, but perhaps it could be left as an implementation detail.

It might be that I am simply accustomed to the existing API, but it seems like:

response.setRenderParameter("foo", "1234");

seems to self-document a little better than:

response.setParameter("foo", "1234");

meaning that the parameter is intended for the render request (in some sense).





[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

Status: Open
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: andre.hagemeier, msnicklous and Neil Griffin

 Description   

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.

javax.portlet.copyRenderParametersToResponse
TRUE - The render parameters are automatically copied to the response
FALSE - The render parameters are not copied to the response, implementing the JSR 286 behavior.

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.



 Comments   
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.





[PORTLETSPEC3-16] Provide a mechanism to extend annnotation processing in GenericPortlet Created: 03/May/13  Updated: 30/Aug/13

Status: In Progress
Project: portletspec3
Component/s: Ideas for JSR 362 Extensions
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: msnicklous and Neil Griffin

 Description   

When extending GenericPortlet, there is currently no way to extend or reuse the
annotation processing provided by GenericPortlet. It would be good if the
GenericPortlet annotation processing could be made extensible in some manner.

One use case would be to allow support for custom portlet modes.



 Comments   
Comment by Neil Griffin [ 14/May/13 04:10 AM ]

I think that the simplest way to achieve this goal would be to have the private maps in GenericPortlet could be exposed with getter methods, and the getter methods could be consulted rather than accessing the private variables directly. For example:

Method actionMethod = getProcessActionMethodsMap().get(action);

instead of:

Method actionMethod = processActionHandlingMethodsMap.get(action);

Also, it would be good to change the scope of the GenericPortlet.cacheAnnotatedMethods() method from private to protected so that it can be overridden.

Comment by msnicklous [ 30/Aug/13 09:26 AM ]

The map methods are not synchronized, and if we make them available, portlet programmers might be tempted to change them, which might not be so good.

Instead, I propose adding the following methods to GenericPortlet:

dispatchAnnotatedActionMethod()
dispatchAnnotatedEventMethod()
dispatchAnnotatedRenderMethod()

These methods allow some flexibility, since the annotation name used does not need to be an action parameter, an event name, or a portlet mode. An arbitrary string can be used.

For example, a developer could annotate a method and access it as follows:

@RenderMode(name="George")
myRenderMethod(...) {
   ...
}

doDispatch(...) {
   ...
   boolean itWorked = dispatchAnnotatedRenderMethod("George", ...);
   if (!itWorked) {
      // show a message
   }
}

If this proposal is found to be good, I will update GenericPortlet to use these methods internally, test the changes, and update the spec appropriately in order to resolve this issue.





Generated at Fri Apr 18 13:36:15 UTC 2014 using JIRA 4.0.2#472.