Skip to main content

This site requires you to update your browser. Your browsing experience maybe affected by not having the most up to date version.

Data Model Questions

Extend Member or Decorate

Go to End

22 Posts   5668 Views


13 November 2010 at 5:52am Community Member, 21 Posts

I was wondering what the best way to approach this is - conceptually i want the member object to be able to have a relationship with business objects, but im not sure if extending Member or using a decorator is better.

i will have 3 user roles, top level admin who will have full SS admin access, client admin who will have limited SS admin access, and then Member, who will have no SS access and a limited in-site admin panel.

so what should i be doing? extending or decorating? and what are the pros/cons of both?


13 November 2010 at 8:49am Community Member, 279 Posts

If this is only about access to the backend why don´t you simply use different groups?


13 November 2010 at 12:30pm Community Member, 21 Posts

No, I said I want to add a relationship to a business object for each member, as well as other extra objects. I just mentioned the 3 levels of user control in case it had a bearing on whether to extend or decorate.


13 November 2010 at 2:04pm Community Member, 271 Posts

Extending Member is not good idea, since it will create a new class name for Member :

class MyMemberClass extends Member{

When Member is called, you won't get any MyMemberClass objects.

So decorating is the way to go, if you want extra db fields or methods for Member.

But I can imagine that you don't want to polute the Member table with fields that only a certain group of Members need.

I rather create a seperate DataObject with a has_one relation to Member, which contains the extra fields.

The backdraw is that Members can't edit those details in the Security tab, so you will need a seperate ModelAdmin where Members can edit their details in the CMS or create a Page with a form where they can edit the details in the separate DataObject.

It depends what the usecase is and how the data is handled which method you use.


14 November 2010 at 11:44pm Community Member, 21 Posts

In this case, there will be one main admin account, which we (the development team) will have access to. Then one (or possibly a few, but very few) silverstripe accounts with limited admin privileges, which we will hand over to the client so they can maintain their site. Finally, an unlimited number of business accounts that the client will add/delete using their SS admin accounts. The business members should be able to edit their own info and thats about it. we are thinking business members wont even have admin access, instead just use insite forms to update their info.

Given that kind of use case, how would you structure your classes?

Also, you say extending member is bad because "When Member is called, you won't get any MyMemberClass objects." How do you mean? Doesnt Object::useCustomClass("Member", "BusinessMember"); make SS use BusinessMember instead of Member?


15 November 2010 at 1:48am (Last edited: 15 November 2010 1:49am), Community Member, 271 Posts

I'm not sure if Object::use_custom_class() will work across the whole site.

But decorating is the way to go if you want add extra fields to the Member table...


15 November 2010 at 6:31am Community Member, 21 Posts

Ye I keep hearing it a lot, but no-one ever seems to say what exactly is wrong with extending member, or why... its kinda mysterious.

Anyway, using decorators or not, given the above structure I outlined, would you decorate member and use groups to achieve those roles, or would you use member for admins and client admins who have SS access, and extend DataObject for the businessmembers?


15 November 2010 at 11:46pm (Last edited: 15 November 2010 11:46pm), Forum Moderator, 1796 Posts

I've used...


Object::add_extension('Member', 'CustomMember');


class CustomMember extends DataObjectDecorator {

   function extraStatics()
      return array(
         'db' => array(
            'Stuff' => 'Boolean'
         'has_one' => array(
            'Stuff' => 'Stuff',

Go to Top