<< Back to previous view

[PORTLETSPEC3-36] Ajax: Remove ability for portlets to provide resources Created: 13/Dec/13  Updated: 14/Jan/14

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

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

Tags:
Participants: kito75, msnicklous and Neil Griffin

 Description   

Reference: Ajax Proposal 2b

The current proposal allows both the portal and individual portlets to contribute resources for sharing with other portlets.

There is concern that this may lead to improper behavior if different portlets use the same name for different resources. For example, portlet A might provide a certain library at a certain version level. Portlet B might provide that same library at the same version level, but in reality, portlet B's library might be slightly modified as compared to that from portlet A (a fix or debug code might be added by one portlet but not the other, etc).

This could potentially lead to a situation where the behavior of the portlets on the page depends on the order in which the portlets appear on the page, or on the algorithm used by the portal for selecting resources when more than one resource of the same name is available. Bugs resulting from such a situation could be very hard to find.

It might be safer to allow portlets to only specify the resources they depend on. The actual resources themselves would always be provided by the portal - individual portlets would not be able to contribute resources for consumption by other portlets.

The manner in which resources are configured in the portal would remain unspecified and implementation-specific.



 Comments   
Comment by Neil Griffin [ 13/Dec/13 11:20 PM ]

Portlets developed against the existing Portlet 2.0 standard can contribute resources to the rendered page via the following syntax:

@Override
public void doView(RenderRequest request, RenderResponse response) {
    renderResponse.setProperty(MimeResponse.MARKUP_HEAD_ELEMENT, element);
}

See: http://portals.apache.org/pluto/portlet-2.0-apidocs/javax/portlet/MimeResponse.html#MARKUP_HEAD_ELEMENT

Resources that are contributed in this manner end up in the <head>...</head> section of the rendered portal page by default, and are by nature "shared" with other portlets.

Because of this, it seems like it would be OK to permit portlets to serve up their own resources using a feature similar to the JSF ResourceHandler. It wouldn't introduce any type of potentially troublesome behavior that doesn't already exist in Portlet 2.0.

Comment by kito75 [ 14/Jan/14 05:33 PM ]

I agree with Neil – some sort of registration mechanism makes sense. This does mean, however, that resources referenced manually without registration should be disallowed.





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





[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).





Generated at Thu Apr 24 17:51:35 UTC 2014 using JIRA 4.0.2#472.