[Zope3-dev] Re: Status of homefolders?

[Max M]

Florent Guillaume wrote:
> In article <cp4ffe$p5t$1 at sea.gmane.org> you write:

>>If member folders had a getMemberFolder() method it would be easy to 
>>check hasattr(self, 'getMemberFolder')
> 
> Urgh. This is not Zope 2 :)

I suppose you mean that it is not Zope 3?


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

Yes and no. In Plone you store:

First lastname
E-mail
Editingmethod
Visibility
id editing
portrait

These attributes seems pretty arbitrary to me. Ant that is exactly the 
half baked solution you will get if there is not framework to deal with 
the issue.

I have used Zope so long that I cannot even remember the first version 
(but I remember the Python version was 1.5.2) and storing member 
attributes has allways only had half-baked solutions. But i have yet to 
make a solution where I didn't need to store different properties for 
members.

CPS might have a better solution to the problem, but please don't assume 
that everybody who knows Zope also knows CPS. There is far more 
frameworks out there than it is possible to get to know.


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

It's not many more lines in Plone, but copying data should not be the 
solution. It's like the first rule of normalisation that is broken.

For access controll you need memberID, password and email. But after 
that things starts to get fishy.


>>3) different workflows for different member properties.

>>MemberBaseProperties:
>>MemberPublicProperties:
>>MemberPersonalProperties:
>># and one can only dream on
>>MemberMultiMediaProperties
>>     image, videogreeting, audiogreeting
> 
> Where do you store all that information ?

My first impulse would be to have some kind of memberproperty interface, 
where the classe implementing it could be related to a member in some 
way. Then all the member*Properties objects would be memberproperties.

A natural place would be somewhere in member folders, as they would then 
be (re)moved with the members. That would also be easy to understand for 
site managers.

Instead of the "chaos" that is Plone/CMF, where you need to remove the 
credentials from acl_users, the membership from portal_membership, the 
data from portal_memberdata and the content from the member folder.

I mention it in this thread because I believe it is a very general 
problem that is somewhat related to member folders.

-- 

hilsen/regards Max M, Denmark

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