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.
