[Zope3-dev] Re: Status of homefolders?

[Florent Guillaume]

In article <cp4ffe$p5t$1 at sea.gmane.org> you write:
> Stephan Richter wrote:
> > On Tuesday 07 December 2004 07:25, Florian Lindner wrote:
> > 
> >>I've read that Stephan is working on homefolders for users.
> >>What is the status of this project? Is there any code to look at in SVN
> >>already? When do you expect it to be usable for development?
> > 
> > It's in the trunk since last weekend. I consider it done for now and do not 
> > plan to do more work on it. Of course, I will maintain it. Feel free to 
> > suggest and implement or reimplement features; the home folder makes some 
> > assumptions that might not be well suitable for a general use case.
> 
> 
> There is a few things I have been thinking about for member folders, or 
> rather member properties. The way it is done in cmf/plone has a number 
> of problems for me when doing intranet applications.
> 
> 1) It's difficult to get the member folder through aquisition. Often you 
> want to show data from a member folder. Not from the authenticated 
> members, but from the member which member folder you are visiting.
> You then have to guess if you actually are under a member folder.

Then your member folders should different than normal folders, by
implementing a specific marker interface for instance.

> If member folders had a getMemberFolder() method it would be easy to 
> check hasattr(self, 'getMemberFolder')

Urgh. This is not Zope 2 :)

> 2) In Plone there is a memberproperties tool. In it, you can save 
> properties for each member. But you can only store member properties on 
> people that are actually members.
> 
> Often you want to store the exact same data for non-members.
> 
> Eg. with a contact database with adresses emails etc. which email 
> address do you use? The one in member properties, or the one in the 
> contact database. How do you avoid redundancy?

That's not a member problem at all. That's a problem of storing
information somewhere. CPS does it for instance by having a notion of
directories, you can have a directory with the standard members, and a
directory of contacts.

> A typical use case is 
> also that you have a contact that you want to make into a member. Then 
> you need to enter all the contact info once more. With the same 
> redundancy problems.

That's not a problem in the member framework. Just have a script that
creates a member from that info. (It's maybe 2 lines in CPS for
instance.)

> 3) different workflows for different member properties.
> 
> In an intranet you often want to have more personal info than you want 
> to publish to the public. Like your private phone and address. But as it 
> is right now you can only choose to show or hide all the properties.
> 
> It seems clear to me that member properties needs to be made from a 
> collection of some sort of content types with properties. Typically they 
> could be like:
> 
> MemberBaseProperties:
>      Name, email
> 
> MemberPublicProperties:
>      companyemail, companyphone etc.
> 
> MemberPersonalProperties:
>      privateemail, privatephone etc.
> 
> # and one can only dream on
> MemberMultiMediaProperties
>      image, videogreeting, audiogreeting
> 
> The workflow state could then be set for each individual content type. 
> It would be simple to add new member properties.

Where do you store all that information ?

Florent

-- 
Florent Guillaume, Nuxeo (Paris, France)   CTO, Director of R&D
+33 1 40 33 71 59   http://nuxeo.com   fg at nuxeo.com