User specific Preferences (JS2-449)

[Aaron Evans <aa...@gmail.com>]

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 <da...@bluesunrise.com> 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: jetspeed-user-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-user-help@portals.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org

Re: User specific Preferences (JS2-449)

[David Sean Taylor <da...@bluesunrise.com>]

Aaron Evans wrote:
> 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.

+1, the user specific prefs should always override everything

> 
> 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.
> 
i agree

> Comments/Suggestions/Differences of Opinion?
> 
> -aaron
> 
In order to get user-specific prefs instead of page-specific prefs, we 
need to change the database schema and the queries to retrieve prefs
Hopefully it will go smoothly...

---------------------------------------------------------------------
To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
For additional commands, e-mail: jetspeed-dev-help@portals.apache.org