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.

We've moved the forum!

Please use forum.silverstripe.org for any new questions (announcement).
The forum archive will stick around, but will be read only.

You can also use our Slack channel or StackOverflow to ask for help.
Check out our community overview for more options to contribute.

Data Model Questions /

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

Extend Member or Decorate


Go to End


22 Posts   10127 Views

Avatar
matthewjumps

Community Member, 21 Posts

16 November 2010 at 12:31pm

Edited: 16/11/2010 12:32pm

Thanks swaiba, but I do already understand how to USE Decorators, Im more interested in why I SHOULD use them, why extending Member is discouraged, and what the correct setup for my given use case would be.

So, why is extending Member then using Object::use_custom_class() supposed to not work across the site? Where exactly does it fail? Can someone give me some specific information? It seems a bit silly to me if SS doesnt work properly with a custom Member class, but if thats the case I need to know exactly how it fails.

And more importantly, given the use case I outlined
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.
what is the correct approach? Use Member for the main admin and the client admin, extend Member for business members? Or extend DataObject for business members? Decorate Member so even admin/client admin have the fields intended for business members?

Avatar
swaiba

Forum Moderator, 1899 Posts

16 November 2010 at 10:01pm

Hi,

Partly I was posting that to make sure no one responded - what the hell are you doing it like that for... THIS is how to do it!
I was not implying you did not not know how to use it!

My opinion would be that use custom class would be more dangerous I think because you are saying "If you get asked to make this object, make this other one instead" whereas with decorating you are saying "whenever you make this class, just add this on to it please".

The difference is that one completely overrides the security system with your custom programming, whereas the other uses the exact security in place and add a little functionality to it. But as I say it is a guess - I haven't gone through the code with a fine tooth comb.

Barry

Avatar
matthewjumps

Community Member, 21 Posts

23 November 2010 at 5:45pm

Edited: 23/11/2010 5:46pm

I still am unsure as to wether I should use the decorated Member class for business users, or create an entirely NEW class that simply extends DataObject - again, given these levels of access

  • Root SS Admin (full access to SS admin area)
  • Client SS Admin (restricted access to SS admin)
  • Business Member (No SS access, possibly an in-site "Edit Profile" page)

would people use Member (and decorate it) for all 3 user types? Or would it be better to use Member only for the types that have SS admin access (Root and Client admin) and extend DataObject for the Business Members? It would be much appreciated if anyone who knows SS well could give me some solid direction.

Avatar
Willr

Forum Moderator, 5523 Posts

23 November 2010 at 8:51pm

I still am unsure as to wether I should use the decorated Member class for business users, or create an entirely NEW class that simply extends DataObject

If they need to login, either in the front end (i.e that edit profile) or to access the CMS then you should decorate (or subclass member). You're asking for much more work to make your own dataobjects for it.

Now whether to subclass or to decorate is the other question and the answer here is based on how much functionality you need to tie to each of the types. Remember multiple decorators can be applied to an object and its nearly fully transparent so if you have a BusinessMember and a ClientMember all functionality or database fields you add to either of those decorators will be available to all member objects i.e all members are client members and business members. Sometimes this is a feature, sometimes its a problem, most times you can live with a few database fields being null.

Avatar
matthewjumps

Community Member, 21 Posts

23 November 2010 at 9:07pm

Edited: 23/11/2010 9:07pm

Thanks Willr, that was a very helpful response. Thats definately cleared up a lot of my confusion.

Are you saying that even if I extend Member into BusinessMember and ClientMember, then decorators I add to these 2 extended classes will also be applied to the base Member class?

Avatar
Willr

Forum Moderator, 5523 Posts

23 November 2010 at 9:24pm

Are you saying that even if I extend Member into BusinessMember and ClientMember, then decorators I add to these 2 extended classes will also be applied to the base Member class?

No, if you decorate an extended class (say BusinessMember) then you won't have it affect the ClientMembers. When you apply a decorator you give it as class to decorate, eg member. From then on its relatively hidden. That decorator is now a 'Member' object. All decorators have an 'owner' class. If you applied to a subclass of member then the 'owner' would be the subclass and the decorator wouldn't know about members.

But then the question is why are you subclassing and decorating at the same time. That may just be creating a whole bunch of debugging fun for yourself!

Avatar
matthewjumps

Community Member, 21 Posts

23 November 2010 at 9:47pm

Edited: 23/11/2010 9:49pm

Thanks for clarifying. I wasnt actually intending to decorate AND extend, tho I was curious as to wether I had misunderstood you or if in fact extended classes did update base classes if you decorate. Im glad thats not the case cause that woulda been bizzare :)

It seems like everyone is recommending decorating, but to me extending seems like the 'right' thing to do, so what problems would I face if I was to make ClientMember and BusinessMember an extension of Member? Would the top level admin Members be able to see/edit the Business/Client Members easily in the CMS? I recall swaiba said "The difference is that [extending] completely overrides the security system with your custom programming" but is that entirely true? Is it a complete override or do extended Member classes work in without too much hassle into the existing security system?

Avatar
MarcusDalgren

Community Member, 288 Posts

25 November 2010 at 12:50am

Subclassed members do show up in the Security admin and I do think there's enough hooks in there to add your own functionality. I've done pretty extensive modifications of the Security admin and extending Member through Decorators but like some other people I don't like all those extra fields in the db, especially if the functionality is only for a small part of the members.

You could use those hooks to show different edit forms depending on the class that's being edited and you could add buttons to the bottom that allow you to add different types of Member. Haven't tried that specific solution myself but it should be doable.