[Zope3-dev] Re: Status of homefolders?

[Max M]

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.

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

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? 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.

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.

All that is needed for this approach to work is some way to relate the 
"member property object" with the member, and vice versa.

Or perhaps I am wrong and these use cases are to special?

-- 

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science