the primary motivation behind this jira is to centralize the management and display of metric views. instead of having to manipulate strings to get and set the view list for a given context as well as the count and ordering of the individual charts, there should be an abstract layer to make the conversion to JSF smoother. not only will this hide the details of how the view preferences are persisted, but it will centralize and consolidate the logic for doing the manipulation between the object form and the persistence form of the data. however, while i'm at it, i'm going to centralize all preferences in the system into a single facade.
rev2198 - centralized reading/writing of all user preferences in the system; if a particular web context only needed one preference, it had a direct getter/setter; however, for more complex preferences (dashboard portlets, metric views), object facades exist with convenience methods as needed by the context;
rev2215 - more refactoring for user indicator chart view preferences;
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1215