Aaron Evans wrote:
David Sean Taylor <david <at> bluesunrise.com> writes:

Well, thats one solution, but why not go directly from UserInfoManager to LDAP? Why not write a UserInfoLDAPManagerImpl and store the user info attributes in LDAP, leaving the Prefs impl as is?



The biggest reason is because of the method signature of getUserAttributes in
the org.apache.jetspeed.security.User interface. It returns a Preferences object.

Preferences getUserAttributes();

We *can* change the API....
It seems like the UserInfoManger API is a bit empty anyway.
IMO, I'd prefer something more like the Portlet API's preferences: get a map, and edit the map, and then have a store() method. Seems wasteful to have atomic updates everytime you put a property. The more I see the Java Prefs api, the less I like it.

So I'd have to create a Preferences instance from the LDAP values at some
point anyway (either in a UserInfoManager implementation or in a User implementation or some combination).

The second reason (although much more minor) is that when the security application updates user attributes, it simply adds/updates a value in this preferences object and leaves it to the Preferences implementation to persist it:

user.getUserAttributes().put(userAttrName, value);

The security portlet can be easily changed

(see org.apache.jetspeed.portlets.security.users#updateUserAttribute).

Again, this second reason is not such a big deal because I will no doubt
need to make some mods to the security app anyway.  I would like the
edit attributes portion of the user details portlet to display a pre-defined
list of attributes rather than letting the user add any arbitrary value.

I figure if I just keep the "attributes" preferences object and "preferences"
preferences object separate in a User implementation and have the former
persist data to LDAP, that that would be the least intrusive customization.

I'd like to see a User Info impl that persists to LDAP
Willing to work with you on this, change the API to suit your needs, its up to you....

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to