Skip to end of metadata
Go to start of metadata

Service

The service would have:

UserPreference getUserPreferenceValue(String key) - using a default namespace (like message service) - trying to decide if it should just hand back string or convert to a type or what here (I think we want to allow String, Boolean, Integer at the very least)

UserPreference getUserPreference(String key, String namespaceCode) - with namespace specified
String getUserPreferenceValue(String key) - using a default namespace (like message service) - trying to decide if it should just hand back string or convert to a type or what here (I think we want to allow String, Boolean, Integer at the very least)

String getUserPreferenceValue(String key, String namespaceCode) - with namespace specified

void setUserPreference (UserPreference preference)

List<UserPreference> getUserPreferences() - get all the user preferences in the default namespace <--- not sure if makes sense

List<UserPreference> getUserPreferences(String namespaceCode) - get all the user preferences for a particular namespace

List<UserPreference> getAllUserPreferences() - get all the user preferences for all namespaces

Depending on implementation we may use componentCode as a parameter (above is based on preferences per rice domain instead of global to all rice apps)

Business Object

The bo would look like this

UserPreference

@Entity

@Table(name="KRAD_PREF_T",uniqueConstraints= {  <---- Dont know if name is appropriate

        @UniqueConstraint(name="KRAD_PREF_TC0",columnNames="OBJ_ID")  <---- Again don't know if names are appropriate

})

public class UserPreference extends DataObjectBase(question) {

    @Id

    @Column(name="NMSPC_CD",length=20)

    private String namespaceCode;

    @Id

    @Column(name="PREF_KEY",length=100)

    private String key;

    @Id

    @Column(name="USER_ID",length=100)

    private String userId;  <--- Not sure if correct here, is it called principal id? really don't know here

    @Column(name="PREF_VALUE",length=4000)

    private String value;

 

 

Another table which defines:

    @Id

    @Column(name="NMSPC_CD",length=20)

    private String namespaceCode;

    @Id

    @Column(name="PREF_KEY",length=100)

    private String key;
private String defaultValue
private String defaultLabel

private String type (int, string, boolean);

@Column(name="PREF_DESC")

private String description;  <--- this could be used in instructional text

private String fieldId (optional)

 

I think type may be necessary here as well, especially if we get into using it for date or color preferences

I guess we would have a default entry for each UserPreference that would be used when a value is needed for a user and they have no preference specified?

Field configuration

A way to define the field configuration in the xml when the id is specified above.  That way we could combine this approach with the auto-generated approach.

For ids:

id="UP-Namepsace-Key"

propertyName="userPreference['namespace.key']"

For the View, if its items are empty, auto-generate.

If a View has an item(s) and it matches a namespace by id="UP-Namespace" override that Namespace's page that would be generated.

If the View has pages without the appropriate ids specify, full view override control is assumed and all fields must be specified.

The Form

The form will at the very least have this:

Map<String, String> userPreference - namespace, key

Framework Access

Then in the framework we would have a SpringEL accessible method to #getUserPreference(key) and its other variations.
Then you could do stuff like change styles colors, whether things appear or not, etc

p:validationMessages.useTooltips="#getUserPreference('use_tooltips', 'validation')"

Framework Manipulation

I think the best way to do this would be to have a multipage/multitab view which organizes the preferences in a CssGridLabelColumnLayout.

Each page would represent a namespace.

In the controller we would grab all the UserPreferences for this user and dynamically populate the View with fields to set these values and a page per a namespace.

Alternatively we could statically declare all the fields on the view on each page, that way we would have more direct control but more maintenance cost to keep it in sync with preferences that are being added.

  • No labels