This page is intended to capture discussion related to appropriate strategies to store preferences in a portal environment.
PortletPreferences
PROS
- Easy setup, no configuration, convenient
- Standardized, (JSR-168)
- Great for saving a small number of values
- Low footprint (no extra libraries, jars)
CONS
- Can be difficult to manage with a large number of preferences
- Only stores and retrieves String values
- Implementation may be different on different containers
- Hard to maintain relationships between values if they exist
Custom Preferences (Database, webservice, etc.)
PROS
- Can manage limitless preferences, large or small
- Can store and retrieve any object type
- Can easily maintain relationships (e.g. inheritance between groups, users, multiple instances)
CONS
- Generally requires custom persistance design & development
- Requires configuration and setup on the users and developers part
- Larger footprint (may require extra libraries, jars)
- Depending on the technology used, may not work on all databases (unsupported operations)
PortletConfig
PortletConfig is probably also worth a mention here – though actual patterns between when to use it versus PortletPreferences has been hazy. JSR-286 has somewhat clarified the distinction, noting that PortletConfig settings are generally those settings made by an administrator that are not intended to be end-user over-rideable, or maybe even end-user visible.
The recommendation seems to also suggest implementing the CONFIG mode if you want to provide an interface to these kind of settings.