I need to have multiple member types with distinct information associated with them. Have been reading about decorating the member. However as each decorator affects all the base table it seems a little inelegant.
So thought this approach might work and am looking for feedback.
1) Decorate Member with MyMember which has_one MemberExtend
2) Create MemberExtend which extends DataObject
3) Subclass MemberExtend which each type I need.
Then each member has 1 set of associated info at the MemberExtend Object. The MemberExtend object in infinitely subclassable (clearly not a word).
The only downsides I see are:
1) Backend isn't aware of extra data
2) MemberExtend could potentially have multiple Members (this relationship could be turned around, but the same thing occurs)
Thoughts? Maybe I'm over thinking this.
Actually upon reflection, if you turn the relationship around. MyMember has many MemberExtends. Then you can have a member with multiple usertypes.
Which is kinda sweet and fixes Sminnee's issue here: http://groups.google.com/group/silverstripe-dev/browse_thread/thread/4519e2b9b5e967db/79b0aa3075d67d18?lnk=gst
A better name for MemberExtend is probably Role.
The problem with decorating Member is that all members get the added stuff. In many cases the need for a special Member is that a site needs a way for people to log into the website and not the CMS. If I need to store information for members that are website only then I subclass Member so that administration users don't get a bunch of info that is not relevant to them. I also usually create a custom loginForm so that when the special member logs in they get sent to the page they should see. I use ModelAdmin to administrate my special members. In fact I have never found a reason to decorate the built in Member class as the current one does most everything needed for CMS administration.