As requested, I'm starting a thread on the dev list for the user specific preferences isssue that David mentions below. I am one of those users that has been vocal about this issue, so I'd like to show my support!
Ideally, I'd like preferences to work in this manner: 1. Preferences default to the values specified in portlet.xml. But, if they are not read-only, they can be overriden by: 2. Preferences specified in a PSML fragment. These in turn can be overriden by: 3. User specific preferences that the user can edit themselves. A user ought to be able to edit their preferences via the page-manager (I think that is the place). However, in addition, I would expect that when I invoke the API calls: PortletPreferences.setValue(prefName,prefValue); PortletPreferences.store(); I would expect that the value (prefValue) for the preference 'prefName' would be stored as a user preference and remain specific to that user. This would allow a portlet to provide its own preference editor interface (most likely in EDIT mode) that remains JSR-168 compliant and portable accross containers. One question: If the chain of precedence works as described above, suppose I have the following situation: 1. A value, S, for preference A for portlet X is specified in portlet.xml. 2. No value for preference A for portlet X is specified in the psml fragment. 3. It is the first time a user is using portlet X (thus there would be no user specific value). If I make the API call: PortletPreferences.getValue(A,R); Should it return R or the value specified in portlet.xml. My interpretation would be to return S, the default value specified in portlet.xml. R would only be returned if there were no value specified for A in any of portlet.xml, PSML fragment or user specific value. Comments/Suggestions/Differences of Opinion? -aaron On 7/17/06, David Sean Taylor <[EMAIL PROTECTED]> wrote:
I want to apologize if people have sent me messages on the user list and I didn't respond, or if I have neglected a particular JIRA issue. I have this bad habit of taking on too many projects at once and sort of drowned in June. If I didn't respond to a direct question to me, or a question in my particular area of expertise, please resend it. This week I plan to address some important database issues: 1. normalizing the principal table. A number of users have complained about the principal tables not being normalized with the principal name in its own column, as well as the principal type in its own column. There are always needs to join to the user tables, and without normalized columns, its difficult. Please start a thread on the dev list to discuss this in further detail 2. finally fixing the preference issues with entities per user/page instead of entities per page (in the database). Please start a thread on the dev list to discuss this in further detail, or visit the JIRA issue: http://issues.apache.org/jira/browse/JS2-449 3. I have also seen requests for additional columns on the principal tables. Normally I recommend joining for these columns, or putting them in the user attributes. However if someone wants to make a case for why we could have a few generic columns on the user table, start a new email discussion on the dev list --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
