Jump to:

3429 Posts in 1057 Topics by 734 members

Data Model Questions

SilverStripe Forums » Data Model Questions » Multiple Member types

Moderators: martimiz, Sean, biapar, Willr, Ingo, swaiba, simon_w

Page: 1
Go to End
Author Topic: 1466 Views
  • petebd
    Avatar
    Community Member
    15 Posts

    Multiple Member types Link to this post

    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.

  • Ingo
    Avatar
    Forum Moderator
    801 Posts

    Re: Multiple Member types Link to this post

    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.

  • petebd
    Avatar
    Community Member
    15 Posts

    Re: Multiple Member types Link to this post

    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?
    Thanks,
    Pete

  • Ingo
    Avatar
    Forum Moderator
    801 Posts

    Re: Multiple Member types Link to this post

    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.

  • Ingo
    Avatar
    Forum Moderator
    801 Posts

    Re: Multiple Member types Link to this post

    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.

  • petebd
    Avatar
    Community Member
    15 Posts

    Re: Multiple Member types Link to this post

    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.

    1466 Views
Page: 1
Go to Top

Want to know more about the company that brought you SilverStripe? Then check out SilverStripe.com

Comments on this website? Please give feedback.