Lots of freelancers hate having to call up people on the phone and asking if they’ve got any work for them. If only there was a...
User-specific versus shared portlet preferences – part 1Peter Mesotten
This article is the first in a series of 2 posts on how personalization can be achieved in a portal project. Moreover, the concept of sharing personalized settings between users is explained and how this behavior can be changed in Liferay.
One of the most important features of a portal is personalization, or the ability for users to change the behavior, content or visualization of portlets. In most projects we’ve done, customers are very skeptical about personalization. For those customers, enabling personalization equals enabling users to mess things up and call for support afterwards. We believe however that personalization, if implemented the right way, creates a dynamic experience that will increase the usage and ultimately extend the lifetime of the portal.
The Portlet 2.0 specification (JSR-286) enables personalization through the definition of portlet preferences. According to the spec, preferences are simple key-value pairs that are stored for each portlet and for each user. This means that two users who look at the same portlets will see two different versions of it, according to the preferences they have set on those portlets.
Since Liferay implements JSR-286 you would expect Liferay to store preferences on a per-user basis too. This is however not the case. By default, Liferay stores them inside the scope of the site that portlet lives in. This means that all site visitors will get to see the same configuration for a certain portlet instance. Luckily, the scope in which preferences are stored can be changed. For this, we need to update the liferay-portlet.xml.
There are 3 properties that are related to the storage of portlet preferences:
The first configuration parameter is the easiest one to understand. If preferences-company-wide is set to true, the preferences for portlets are stored portal-wide. Every instance of the portlet on every page within every site will have the same preferences. Changing the preferences in one place will change the portlet in all other places. If this parameter is true, the other configuration parameters are ignored.
The other 2 parameters, preferences-unique-per-layout and preferences-owned-by-group, can both be true or false as well. In this case, the combination of these settings will define the scope in which the preferences for portlets are stored.
If we do the math, we end up with 5 options for storing portlet preferences. The implications of those options can best be explained by giving an example.
Example: QuickLinks portlet
Consider a custom portlet that can be configured to show one or more links to internal or external pages, resources or applications. The set of links that should be visible is configured using portlet preferences. In this case, the preferences scope configuration will decide which quick links will be visible for which users.
- Portal-wide quick links
In this case, all portal users will see the same set of quick links throughout the portal. So even if there are multiple QuickLinks portlets on different pages, they will all show the same quick links. Usually, you won’t allow every user to update company-wide preferences, because users will start to override the preferences of each other. It is more common to assign this task to a global administrator.
- Site-wide quick links
(preferences-company-wide=false, preferences-unique-per-layout=false, preferences-owned-by-group=true)
This case behaves very much like the previous one. Except for the fact that the quick links will be the same in portlets on pages within one site only. Each site can thus manage its own preferences. Again, it is not recommended to allow this to every site member. The ideal person to manage these kinds of preferences is the site administrator.
- Per-portlet quick links, shared across users
(preferences-company-wide=false, preferences-unique-per-layout=true, preferences-owned-by-group=true)
This case is the same as the previous one. Except that every portlet instance has its own configuration. So we can have different QuickLinks portlets in different pages of our site and each of them can show different links. For a given portlet instance, all users will however see the same links. Again it’s mostly the site administrator who will manage these links or maybe a small group of users that will manage different parts of a site. Remember that this is the default setting, so it will be used if no configuration is set.
- Per-user, per-portlet quick links
(preferences-company-wide=false, preferences-unique-per-layout=true, preferences-owned-by-group=false)
In this case, every user will be able to store a dedicated portlet configuration for each portlet instance separately. So each user can decide for himself which links are visible in the portlet. If there are multiple QuickLinks portlets, the configured links can be different in each portlet. The user must of course be given the appropriate permissions to allow him to update the preferences (enable the PREFERENCES action on the portlet resource).
- Per-user quick links, shared across portlets
(preferences-company-wide=false, preferences-unique-per-layout=false, preferences-owned-by-group=false)
In case there are multiple QuickLinks portlet instances on different pages, this setting will share user preferences between all those instances. So if a user changes the quick links in one portlet, they will be updated in all other QuickLinks portlets as well.
It is clear that Liferay’s addition to the Portlet 2.0 specification with regard to portlet preferences enables a great amount of. Defining the scope in which preferences should be stored is an important decision that needs to be taken during functional analysis, not during development.
One limitation of this is that it seems impossible to store preferences in multiple scopes at the same time. Indeed, the liferay-portlet.xml configuration is applied to all preferences. Sometimes however, it could be useful to store default preferences on a global level (e.g. portal-wide or site-wide), while allowing end-users to override this global configuration with custom preferences. In case of the QuickLinks portlet, an administrator could provide a default set of quick links that are used if a user has not set his own quick links.
The next part of this series will explain in detail how this can be achieved in a clean, reusable way…