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're retiring the forums!

The SilverStripe forums have passed their heyday. They'll stick around, but will be read only. We'd encourage you to get involved in the community via the following channels instead:

Archive /

Our old forums are still available as a read-only archive.

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

Muiltiple Member types and relations

Go to End

5 Posts   1651 Views


Community Member, 20 Posts

23 September 2008 at 12:47am

I have a data model requiring 3 different types of Members (with log ins and different extra fields) that have 1-many relationships with 3 different tables:

Student --* requirement
Provider --* offer
Organisation --* client

I am trying to work out the following:

1. Should I extend Member with a DataObjectDecorator with appropriate added fields and then disable/modify output according to an added 'type' field in the Member table? If so, how would I represent the 3 different table relationships? Would having 3 objects in the has_many array create problems when only one of them will be populated per Member?

2. Should I extend Member with 3 different DataObjectDecorators?

3. Am I better off maintaining 1-1 relationships between Member and 3 new tables that hold the extra fields and are then represented by 3 new objects - Student, Provider, Organisation

4. Is there a better way?



Community Member, 20 Posts

26 September 2008 at 12:54am



Community Member, 712 Posts

26 September 2008 at 11:52am

I'd go option 1 - seems the simplest and I don't see any problems only filling in one relationship. Option 2 is (effectively) going to be the same thing anyway.

Option 3 is feasible - and potentially cleaner, but perhaps harder to maintain from the CMS.


Community Member, 20 Posts

26 September 2008 at 10:23pm


Thanks Hamish. That was my first thought, the problem is that there will be a lot of redundant fields for each of the members.

E.g. (Summarising)
Organisation(ID, OrgType, Name, Contact, Address, City, Postcode, Phone, Fax, Email)
Student(ID, FirstName, LastName, Institution, GradYear, Modality, Practising, Email)
Provider(ID, FirstName, LastName, Address, City, Postcode, Phone, Fax, Email)

Adding new members through the CMS will be dodge if certain fields have to be ignored by the operator.

Would it be possible to set up 3 new TABs on the Member screen? One for each user type with a TableListField containing only the relevant columns (and pre-populated rows) for that user type?


Community Member, 23 Posts

30 September 2008 at 10:29pm

I'm looking for something simular, so let's try this again, can anyone help with the above idea of making the members choose?