Hi,
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?

Ta,
Z.

Anyone?

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.

Hmm...

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?

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