...
| Section |
|---|
| Column |
|---|
| PROS - Easy setup, no configuration, convenient
- Standardized, (JSR-168)
- Great for saving a small number of values
- Low footprint (no extra libraries, jars)
|
| Column |
|---|
| 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.)
| Section |
|---|
| Column |
|---|
| 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)
|
| Column |
|---|
| CONS- 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.