3093 Posts in 875 Topics by 654 members
| Go to End | Next > | |
| Author | Topic: | 4114 Views |
-
Extend Member or Decorate
13 November 2010 at 5:52am
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?
-
Re: Extend Member or Decorate
13 November 2010 at 8:49am
If this is only about access to the backend why don´t you simply use different groups?
-
Re: Extend Member or Decorate
13 November 2010 at 12:30pm
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.
-
Re: Extend Member or Decorate
13 November 2010 at 2:04pm
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.
-
Re: Extend Member or Decorate
14 November 2010 at 11:44pm
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?
-
Re: Extend Member or Decorate
15 November 2010 at 1:48am Last edited: 15 November 2010 1:49am
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...
-
Re: Extend Member or Decorate
15 November 2010 at 6:31am
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?
-
Re: Extend Member or Decorate
15 November 2010 at 11:46pm Last edited: 15 November 2010 11:46pm
I've used...
_config.php
Object::add_extension('Member', 'CustomMember');
class...
class CustomMember extends DataObjectDecorator {
function extraStatics()
{
return array(
'db' => array(
'Stuff' => 'Boolean'
),
'has_one' => array(
'Stuff' => 'Stuff',
),
);
}
}
| 4114 Views | ||
| Go to Top | Next > |
