Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
Draft/WIP
Introduction
This page contains the current WIP thoughts for the preferences service.
Overview
Personalisation will be handled by the individual component, that is, the component is responsible for looking for its own config and overlaying any preference data that may be present for the current user. Furthermore, the component is also responsible for writing any preference data for the current user.
A preference data webscript will be available that components can use to set and retrieve preference information.
Use Case
The design shown in the rest of this document is shown by demonstrating the following use case:
The document library as you would expect has a list of actions for documents, in the current wireframes these are split into two sections: a frequently used list and a drop down list. At the bottom of the drop down list will be a Customise action that allows the user to select their own frequent actions or hide existing actions.
Design
Given the use case above, we may well have a list of available actions that are configured globally, that is, in web-framework-config.xml:
<config>
<actions>
<action id=â€edit-offline†method=â€alfresco.coci.editOffline†/>
<action id=â€edit-online†method=â€alfresco.coci.editOnline†/>
<action id=â€checkin†method=â€alfresco.coci.checkin†/>
<action id=â€delete†method=â€alfresco.dialog.delete†/>
</actions>
</config>
The component itself then may then have configuration for what actions appear where, for example:
<frequent-actions>
<action idref=â€edit-offline†/>
<action idref=â€edit-online†/>
</frequent-actions>
<more-actions>
<acton idref=’’checkin†/>
<action idref=â€delete†/>
</more-actions>
It could also have further config data stored as parameters with the component instance which could also be used to drive the rendering.
If a user clicks the Customise button, the user can select which actions go where, this would then be persisted via the preferences data webscript against the current user. In this scenario, the preference data could be a list of action ids the user wants as frequent actions and a list of actions they want as more actions.
The next time the component is rendered it will retrieve the user’s action preferences before consulting its own local parameters or config.
Having these different levels of config allows “reset to default†behaviour, the component config acts as the ‘starting point, the default’, this can then be overridden by the site author and/or the user.
The unique id for the component which currently consists of the componentname, region and scope will be used as the key for the user preference data.
Model
The current web client has a PreferencesService which stores user preference data as a cm
bject stored in the following location:
/system/people/<person>/configurations/preferences
For simple, small preference data we could continue to use the same object (we may then be able to share preferences between the old and new clients if required).
However, some preference data may grow to be quite large and represented as JSON and/or XML (it will be up to the component writer). We can not rely on the d:text property type as it has a limited length (depending on the DB). Furthermore, we can not use the Serializable attribute from the AttributeService as, although unlikely, there is still a limit to the amount of data it can hold (depending on the BLOB storage of the DB).
It therefore makes sense to store larger preference data as the content property of a type, either a plain cm:content type or a subtype if we want/need to query for them.
