3341 Posts in 982 Topics by 703 members
|Go to End|
28 March 2009 at 5:48am
I have a site where I need to have a number of different member types. As an example, you might have sellers and buyers and these guys would need to have different information associated with them.
What is the recommended way of achieving this? Can we extend the Member class or should we create different Profile classes and associate an instance of one of these with each member? What is easiest?
Thanks in advance.
29 March 2009 at 3:23pm
We normally don't subclass Member for our own projects unless you're 100% sure that you've only got this one usecase (=subclass) for them, and have control over where the member subclass needs to be queried and instanciated. Its usually more flexible to use DataObjectDecorator for this, our version of "multiple inheritance" in PHP5. Its got its own shortcomings, but can be quite powerful. Have a look at ForumMember in the forum module for example usage.
29 March 2009 at 10:14pm
Thanks for the reply, Ingo.
I found the wiki pages about subclassing Member and also the DataObjectDecorator.
The trouble with the second post is that it appears to affect every instance of the class that is decorated.
Here is my problem in more detail. In a modelling agency site, I have two member types: Model and Client.
Models need to have things like gender, height, eye colour and so on. Clients need to have business information, multiple contacts and so on. They all need to be able to login and modify their information online.
My guess is to create two classes ModelMember and ClientMember that both extend Member and then create specific pages to manage the registration and profile management etc. I assume that things like ForumRole will still work as they will decorate the base class Member, which will flood down to the subclasses?
Is there a better way of achieving this?
30 March 2009 at 3:50pm
We found the "all properties available on all Members" to be a necessary evil, its easier to deal with than multiple Member subclasses. You basically need to build your own admin/security interface which lets you choose the "type" of Member you want to create, list, edit.
30 March 2009 at 3:57pm
BTW, I've started a discussion on the dev list about this: http://groups.google.com/group/silverstripe-dev/browse_thread/thread/4519e2b9b5e967db
Would be a nice feature, but I'm not sure how feasible it is.
30 March 2009 at 9:54pm
I have applied to be a member of the dev mailing list and I will continue with the discussion there.
There is an interesting point made by Sam on that discussion: if you subclass Member but then have two members who are actually the same person but need multiple MemberTypes (for example, a Model who is also a Client!!). What do you do? He suggests that instead one uses 1-1 relationship between Member and other member related fields (such as profile information).
In many ways I like the subclass method since it seems more straightforward to understand if you came to a project and found the subclassed Member types. The related classes method is obviously more flexible, since you could associate multiple roles with a member and act accordingly but this mechanism would need to be baked into the core and well documented for it to be used correctly and to help understanding.
Certainly from a module developers point of view the second approach is better as you don't tie website integrators into a specific set of Member types. From an integrators point of view it may be easier to use the first approach as long as you are absolutely sure that no members will exist in more than one type.
|Go to Top|