Community wishlist for the next release of the JSR168 specification

==#Messaging between portlets == We'd really need a solution for sending messages between portlets. If for instance a portal page contains a portlet showing folders in the left pane, and a content portlet showing the items in the selected folder, the latter needs updating in case the user has selected another item in the former portlet.

What's wrong with using the session (except that there's currently an issue with cross context sessions in tomcat)?

This won't work if your goal is to message between portlets that reside in different contexts. Cross context sessions don't seem to be applied to the manner that portlets are used.

This will also not work if you need to do some action processing on the target portlet.

Portlet[[#Filters]]

Similar to the concept of Servlet Filters. Maybe with a configuration option on which phase(s) to apply it to.

==#Exclusive Window State == Add a new window state called "exclusive" to the list of mandatory window states (could also be a portlet mode). When a portlet requests this state, the portal would typically give the portlet direct access to the request and response without going through the normal portlet aggregation activity. This would serve as an easy way for a browser to download a file served directly from a portlet. We've implemented it in uPortal so that we could get file downloading to work properly. Contact Ken Weiner <kweiner@unicon.net> if clarification is needed.

Comment: Just a thought really, but what if it was the container's responsibility to decode the multipart request and store the file contents to a temporary storage. And then extend the PortletRequest with a getFile(String paramName) method that returned a java.io.File object?

Comment: I think two different things are being talked about. The above comment refers to uploading a file to a portlet. That is already possible by using the getPortletInputStream() method on the ActionRequest object and decoding the multipart request. There are lots of libraries out there that do this for you. The "exclusive" window state is for downloading a file 'from' a portlet or more generally, allowing a portlet complete control over all content written to the browser for that response. - Eric Dalquist <edalquist@unicon.net>

Scope PortletPreferences to Portlet Instances

Users may subscribe to the same Portlet more than once and want to configure them independantly via PortletPrefences. For instance I may subscribe to the IMAP client Portlet twice and want each Portlet configured for different IMAP servers. The current spec talks about how PortletPreferences are scoped to a particular user but leaves it unclear where or not they are scoped to a Portlet or Portlet Instance. - Bill Thompson <wgthom@rutgers.edu>

==#UserKey == Add a method to the PortletRequest that returns a key representing the current user of the portal. Portlets need this key to store user-specific information when the portlet preferences mechanism is not suitable. A workaround is to create a custom user attribute representing the user, but a definitive method would be preferable.

Comment: you could either use getRemoteUser(), or (as we did), add a new entry to the user info map which represents the user. In our case, where the users are stored in LDAP, it would be the DN of the user. - Rickard Öberg <rickard@dreambean.com>

==#InstanceLifecycle == Add init and destroy methods to the Portlet that get called whenever a portlet entity is constructed or destroyed.

Comment: And clone() too, to allow "copy&paste" - Rickard Öberg <rickard@dreambean.com>

==#Edit Defaults Portlet Mode == Add a new PortletMode called "edit_defaults" to the list of mandatory portlet modes. The mode would only be valid when a portlet is being published in the portal. It would allow the portlet to display a custom UI for entering publish time parameters. This item would be dependent on the preceding and following items about preferences. - Eric Dalquist <edalquist@unicon.net>

==#Publish Preferences == Currently preferences can be assigned at the portlet.xml level and within a user instance of the portlet. portlet.xml preferences are avalable to every instance of the portlet and user instance preferences are only avalable to that user instance of a portlet. I'd like to add a publish time level of preferences. These preferences would only be editable when a portlet is being published or the published description is being changed. Publish time preferences would have the option of being set read-only as well. Publish time preferences would be avalable to all rendered instances of that published instance. This would create three levels of preferences, portlet.xml which are avalable to any instance of the portlet, publish time which are avalable to an instance of that published portlet and user instance which are scoped per user per instance. - Eric Dalquist <edalquist@unicon.net>

==#ObjectPreferences == PortletPreferences are today only String->String mappings. We quite often (almost always) keep more complex state in the preferences, so would like to add String->Object mappings. - Rickard Öberg <rickard@dreambean.com>

Comment: I'd also like to see this. I just want to clarify that you are thinking of Objects that implement Serializable. Since PortletPreferences must be backed by a persistant store only Seralizable objects would be able to be written out. Other API types that include helper methods for java primitives and byte[] would also be usefull. - Eric Dalquist <edalquist@unicon.net>

==#Servant Mode == In many cases a general use portlet, such as a group management portlet, could have many opportunities for re-use by other portlets. A method to make a call to another portlet, via JNDI or similar, would be very usefully. This call would render the referenced portlet is a specific mode such as PortletMode.SERVANT. The called portlet would have complete control of the output for the calling portlet until it returns a specific value or sets a specific mode. The caller could specify a "mode to go back to" and the called portlet could set that mode when done. This could be an implementation that shared some code with the portlet messaging functionality for looking up another published portlet via JNDI. - Eric Dalquist <edalquist@unicon.net>

All User[[#Attributes]]

A new tag that can be specified in portlet.xml that would denote the portlet as wanting all avalable attributes from the portal. This would allow a portlet to get a list of all the attributes for a user and could be usefully in certain cases. - Eric Dalquist <edalquist@unicon.net>

PlutoProjectPages/WishList (last edited 2009-09-20 23:32:54 by localhost)