Jens Vagelpohl  <[EMAIL PROTECTED]> wrote:
> On Apr 15, 2005, at 19:29, Florent Guillaume wrote:
> > yuppie  <[EMAIL PROTECTED]> wrote:
> >> Florent Guillaume wrote:
> >>> I'll be changing MemberData.setSecurityProfile to use
> >>> user._doChangeUser() instead of hitting the attributes directly, if
> >>> nobody sees a problem with that.
> >>
> >> Why not userFolderEditUser()?
> >
> > I checked this in (for 1.5 and HEAD).
> >
> > As usual unit tests took the longest time, MemberData is hardly tested
> > at all :(
> Thanks Florent!
> Actually, MemberData is kind of a weird subject.
> Its interactions with the underlying user folder are a little odd and 
> lack clear policy. Some things are written out to the user folder, 
> others stay in the wrapper. Most things are looked up in the wrapper 
> and sometimes create inconsistencies with the actual user database if 
> it gets updated without the CMF knowing.

Indeed, it's a total mess. You had to introduce you own CMFLDAP. In
early CPS we monkey-patched the standard MemberDataTool to provide
correct behaviour in the face of various non-standard user folders...

Now CPS has completely gotten rid of the original MemberDataTool, and
delegates all storage to the user folder (which has to know about that
of course). CPS's MemberDataTool just indirects everything to the user
object. The only source of user information for us is the user folder
(which itself abstracts its storage to a Directory, but that's another
story). And things are much saner.

> Maybe I could try and think of an extension that allows you to specify 
> what gets written where (and looked up where), some simple ZMI UI on 
> the MemberDataTool. Anyone have any thoughts on that?

I can't say I care about it, sorry :) MemberDataTool is dead to me, only
bits of the API remain :)


Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   [EMAIL PROTECTED]
Zope-CMF maillist  -

See for bug reports and feature requests

Reply via email to