[
http://issues.apache.org/jira/browse/PLUTO-122?page=comments#action_12451792 ]
Craig Doremus commented on PLUTO-122:
-------------------------------------
This would be a great contribution if you could do it.
What you need to do is implement the PortletPreferencesService interface. Look
at the DefaultPortletPreferencesService class for an example, which holds
preferences in an in-memory Map (called storage). This class does not do
user-specific storage, but you can call request.getRemoteUser() inside
getStoredPreferences() to get the user name.
Once you have a new service implemented (I'll call it
DerbyPortletPreferencesService) configure
it in the Spring config file (pluto-portal-driver-services-config.xml) by
uncommenting the portletPreferencesService property in the DriverConfiguration
bean and adding a separate bean element for PortletPreferencesService like this:
<bean id="PortletPreferencesService"
class="org,apache.pluto.core.DerbyPortletPreferencesService"/>
Here's a simple Derby database schema I played around with a while ago:
CREATE TABLE preference (
preference_id INTEGER NOT NULL
generated always as identity (start with 1, increment by 1),
preference_name VARCHAR(75) NOT NULL,
read_only CHAR(1) DEFAULT 'N',
auth_user VARCHAR(75),
mod_date TIMESTAMP DEFAULT current_timestamp,
constraint preference_pk primary key (preference_id)
);
CREATE INDEX preference_auth_user_ndx on preference(auth_user);
CREATE TABLE preference_value (
preference_id INTEGER NOT NULL,
preference_value VARCHAR(250),
mod_date TIMESTAMP default CURRENT_TIMESTAMP,
constraint preference_value_pk primary key (preference_id,
preference_value),
constraint preference_value_fk foreign key (preference_id) references
preference(preference_id)
);
The auth_user is the authorized user name returned from
PortletRequest.getRemoteUser(). The size of the preference_name and
preference_value fields are arbitrary and not defined by the spec (as is the
auth_user size).
There is a one-to-many relationship between the preference and the
preference_value table because there can be many preference values for a given
preference (returned by PortletPreferences.getValues()).
It should be noted that the JSR-168 spec states that preference storage must be
atomic, so make sure that you do any preference table inserts within a proper
transaction.
Let me know if you have any other questions.
> Portlet Preferences need to be user specific
> --------------------------------------------
>
> Key: PLUTO-122
> URL: http://issues.apache.org/jira/browse/PLUTO-122
> Project: Pluto
> Issue Type: Bug
> Components: portal driver
> Affects Versions: 1.0.1-rc1, 1.0.1-rc2, 1.0.1-rc3, 1.1.0-alpha1
> Environment: All operating systems and hardware
> Reporter: Craig Doremus
> Fix For: 1.1.0
>
>
> According to the JSR-168 specification PLT.14.2:
> "Portlet Specification assumes preference attributes are user specific, it
> does not make any provision at API level or at semantic level for sharing
> preference attributes among users."
> Right now the PortletPreferences attributes are shared by all users and
> stored within the portletentityregistry.xml file. I'm not sure if there will
> be enough time to fix this for the final Pluto-1.0.1 release, but there
> should be documentation concerning our implementation of Portlet Preferences.
> As the spec says, "If a portal/portlet-container implementation provides an
> extension mechanism for sharing preference attributes, it should be well
> documented how the sharing of preference attributes works."
> Maybe we should implement this in Pluto 1.1 in conjuction with a User
> Information (PLT.17) implementation (Jira issue PLUTO-38), since both are
> keyed on a specific user.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
