[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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-48] Support @Inject for portlet lifecycle objects such as PortletConfig, PortletRequest, and PortletResponse Created: 17/Feb/15  Updated: 17/Feb/15

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: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In a jsr371-experts thread titled Initial Work & Feedback, co-spec-lead Santiago Pericas-Geertsen mentioned that JAX-RS (and MVC indirectly since it depends on JAX-RS) supports injection of
HttpServletRequest/HttpServletResponse.

It is my best understanding that this requirement actually falls on the CDI implementation (i.e.: Weld, OpenWebBeans, CanDI), and that JAX-RS/MVC simply benefit from that.

Santiago went on to write:

it should be fairly simple to support injection of Portlet-specific types for portlet applications

I think that this responsibility would fall on the portlet container implementation. Therefore this issue serves as a feature for implementing injection of portlet lifecycle objects such as javax.portlet.PortletConfig, javax.portlet.PortletRequest, and javax.portlet.PortletResponse.






[PORTLETSPEC3-49] Add createRedirectURL() method to javax.portlet.ActionResponse interface and javax.portlet.filter.ActionResponseWrapper class Created: 19/Feb/15  Updated: 25/Feb/15

Status: Open
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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Portlet 2.0 API provides the ActionResponse.redirect(String) method in order to support redirection during the ACTION_PHASE of the portlet lifecycle. However, frameworks like JSF need to determine the redirect URL (typically a String representation of a render URL) before they can call the redirect method. The problem is that the createRenderURL() method is only available in the Portlet 2.0 javax.portlet.MimeResponse interface.

Since it is not appropriate for javax.portlet.ActionResponse to extend javax.portlet.MimeResponse, this issue serves as a proposal for adding the following method to the javax.portlet.ActionResponse interface and javax.portlet.filter.ActionResponseWrapper class:

public PortletURL createRedirectURL();





[PORTLETSPEC3-51] Change PortletURLGenerationListener Declaration to allow for backward compatibility Created: 26/Feb/15  Updated: 26/Feb/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: msnicklous Assignee: msnicklous
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The current interface declaration for the PortletURLGenerationListener requires arguments of type PortletURL for both the Action URL and render URL arguments. This is inconvenient for V3 portlet developers, as it would require a cast to get the ActionURL and RenderURL objects, respectively.

On the other hand, we need to retain source & binary backward compatibility with existing JSR 286 portlets that use such a listener.

I suggest we change the interface declaration as follows to address both problems:

public interface PortletURLGenerationListener 
      <T extends PortletURL & RenderURL, U extends PortletURL & ActionURL>{

	public void filterActionURL(U actionURL);
	public void filterRenderURL(T renderURL);
	public void filterResourceURL(ResourceURL resourceURL);
}

Through type erasure, this is binary compatible with the existing declaration, and V2 portlets run unchanged. V2 portlets can be recompiled against the V3 API library, so source compatibility is achieved as well.

The V3 portlet developer has access to the new ActionURL and RenderURL interfaces, and would implement the interface as follows:

public class URLFilter implements PortletURLGenerationListener<RenderURL, ActionURL> {

   @Override
   public void filterActionURL(ActionURL actionURL) {
      // do something
   }

   @Override
   public void filterRenderURL(RenderURL renderURL) {
      // do something
   }

   @Override
   public void filterResourceURL(ResourceURL resourceURL) {
      // do something
   }

}





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

+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-44] Using Client side(Jquery/ ..) internationalization in portal Created: 09/Jul/14  Updated: 09/Jul/14

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

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

All portal supported servers



 Description   

Since various portal vendors using the different internationalization / localization , better to use light weight client side language...






[PORTLETSPEC3-43] In the Portlet State proposal, shorten the method names in the PortletParameters and MutablePortletParameters classes Created: 03/Jun/14  Updated: 03/Jun/14

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Portlet State proposal defines the PortletParameters and MutablePortletParameters classes for reading and updating parameters. Many of the method names in these classes have the word "Parameter" in their signature:

getParameter(String)
getParameterNames()
getParameterValues(String)
setParameter(String, String)
setParameter(String, String...)

These names are very long and also redundant, since both classes deal exclusively with parameters. The method names should be shortened.



 Comments   
Comment by msnicklous [ 03/Jun/14 ]

The following naming would shorten the method names and reduce redundancy. This suggestion also makes the getter & setter naming more symmetrical and more in line with bean naming conventions.

getValue(String)
getNames()
getValues(String)
setValue(String, String)
setValues(String, String...)




[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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.





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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

Comment by julien_viet [ 10/May/13 ]

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 ]

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 ]

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-45] Questions about Public Render Parameters Created: 14/Jan/15  Updated: 14/Jan/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

While implementing the Portlet Hub on Pluto, some questions came up about Public Render Parameters.

1) Pluto matches PRPs between portlets based on the identifier. The PRP QName is ignored.

According to the JSR 286 specification, the QName should be used as a unique identifier for the PRP. Also, the spec contains the following text describing how the public render parameters are to be shared between portlets:

It is up to the portal implementation to decide which portlets may share the same public render parameters. The portal should use the information provided in the deployment descriptor, like the name, qname, alias names and description, in order to perform such a mapping between public render parameters of different portlets. It is also an implementation choice of the portal whether different portlet windows of the same portlet will receive the same public render parameters. An example where different portlet windows may not want to share the same render parameters is a generic viewer portlet that takes as public render parameter the news article ID to display. The user may have several of this viewer portlets on her pages that may be connected to different content systems.

While leaving a great deal of room for implementation flexibility, the 'identifier' field from the portlet descriptor is not mentioned in the criteria for mapping public render parameters.

Taken together, I believe that the public render parameter mapping should not be based on the identifier, but rather on the QName. This would mean that the Pluto implementation is in error and should be corrected.

See: PLUTO-642

Portlets for testing this behavior can be found in the Pluto TCK in the two modules TestModule3-portlet1 and TestModule3-portlet2. The portlets contain four Public Render Parameter tests. These tests have been pushed to the master as well as to the PortletHub branches of the repository.

If you feel that the mapping should be done based on the identifier, please make your arguments known, thanks!

2) The second problem has to do with aliases for Public Render Parameters. The spec does not describe the use of aliases in detail, but the portlet deployment descriptor schema allows aliases to be specified.

I believe that there are problems associated with the concept of aliases for public render parameters that render it of little use.

For example, what should happen when aliases for a PRP refer to two different, but valid, public render parameter QNames? Which one should be used?

It is also possible to construct configurations through use of QNames where the configuration for the individual portlets is ok, but the overall configuration produces a logical inconsistency.

For these reasons, I propose clarifying the specification by completely removing the idea of aliases for Public Render Parameters from the document and also from the deployment descriptor schema (for version 3).






[PORTLETSPEC3-50] Updates from the V3 Prototype Implementation Created: 25/Feb/15  Updated: 25/Feb/15

Status: Open
Project: portletspec3
Component/s: None
Affects Version/s: None
Fix Version/s: None

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


 Description   

During implementation of the V3 prototype some changes in the Portlet Specification
v3.0 API definitions and javadoc seemed necessary and/or prudent. This issue lists
those changes.

1) Change the method signatures of MimeResponse#createRenderURL and
MimeResponse#createActionURL to allow for backward compatibility. Without these
changes, V2.0 portlets would not run unchanged.

Old Signatures:

    public RenderURL createRenderURL();
    public ActionURL createActionURL();

New signatures:

   public <T extends PortletURL & RenderURL> T createRenderURL();
   public <T extends PortletURL & ActionURL> T createActionURL();

2) The MutablePortletParameters#set() method returns a MutablePortletParameters
object rather than a PorletParameters object.

    public MutablePortletParameters set(PortletParameters params);

3) The MutablePortletParameters#add() method returns a MutablePortletParameters
object rather than a PorletParameters object.

    public MutablePortletParameters add(PortletParameters params);

4) The PortletParameters interface does not extend Cloneable as originally
envisioned. It was too difficult to make it work properly, as the PortletParameters#clone()
method returns a MutablePortletParameters object.

5) Added a size() method to PortletParameters, defined as follows:

  /**
   * Returns the number of parameters in this object.
   *
   * @return  the number of parameters in this object
   * 
   * @since    3.0
   */
  public int size();

6) Added new methods to the PortletURLGenerationListener taking specific URL
types defined as follows:

(This needs revisiting - reviewing this, I think I introduced an incompatibility!)

	/**
	 * Callback being called by the portlet container
	 * before <code>toString</code> or <code>write</code>
	 * are executed on action URLs.
	 * 
	 * @param actionURL  action URL to be generated
	 */
	public void filterActionURL(ActionURL actionURL);

	/**
	 * Callback being called by the portlet container
	 * before <code>toString</code> or <code>write</code>
	 * are executed on render URLs.
	 * 
	 * @param renderURL  render URL to be generated
	 */
	public void filterRenderURL(RenderURL renderURL);

7) Updated the Portlet Hub Javascript action() function to return a Promise
that is resolved with no argument when the action completes. This allows a
portlet client to be implemented in such a manner that the portlet UI doesn't
allow further input until the action completes.

See the following links to view the updates:

Updated Javadocs

Updated Jsdocs






Generated at Fri May 22 14:34:13 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.