Allow multiple Member subclasses in SecurityAdmin?

[Ingo Schommer]

See http://www.silverstripe.org/data-model-questions/show/257221?showPost=257364 for some context.

Currently we don't support subclassing Member in our interfaces.

You can subclass SecurityAdmin and set it to use your

custom Member class, but there's no way for an administrator

to tell the system which "type" (=subclass) of Member he wants to

create.

We usually solve this by using DataObjectDecorator and "roles"

instead of subclasses. This means that all Member objects will have

all properties. This is recommended if you're building modules

like forum, to avoid inheritance issues. For your own datamodel

it might be cleaner to use different subclasses though, instead

of having a bunch of NULL fields in the database, and lots

of nonsensical/orphaned properties/methods on the object

instances. 

Do we want to support this by (optionally) allowing

to choose the Member subclass in SecurityAdmin

when creating or editing records through a "type" dropdown? 

What other APIs and interfaces would need to adapt to this type selection?

All groups would still list all Member subclasses to avoid overcomplicating

the interface.

-------

Ingo Schommer | Senior Developer

SilverStripe

http://silverstripe.com

Phone: +64 4 978 7330 ext 42

Skype: chillu23

[Sam Minnee]

We used to take this approach and it caused us real hassles. That's
why we moved to the DataObjectDecorator system.

The problem is that you inevitably run into situations where someone
needs to be stored in the system with two classes, because two members
with the same email get merged into. We tried to work around this by
some tweaky alteration of classes in existing records, but it caused
some horrible bugs. I really don't want to encourage people to do
this.

But the issue of a bloated Member table should still be solved. I
would recommend alternative approaches:

1) Have 1-to-1 relationships between member and other model classes.
Good use-case for your belongs_to field! For example, the extra
columns needed on a forum member might be stored in ForumProfile.

For this to be efficient, we would want to make it easy to create a
Form that could edit both "FirstName", "Surname", "Email", and
"ForumProfile.Bio". Support the dot syntax in form field names and
$form->saveInto($record) calls would give us this ability.

2) Question whether the data you're working with really needs to be
stored in the member table. I have a feeling that we bloat the member
table because we use it for too many different purposes. For example,
I'm beginning to wonder whether newsletters should be stored in a
different table, and whether we should leave Member purely for log-in
functions.

On Mar 30, 3:56 pm, Ingo Schommer <i...@silverstripe.com> wrote:
> Seehttp://www.silverstripe.org/data-model-questions/show/257221?showPost...

>   for some context.
>
> Currently we don't support subclassing Member in our interfaces.
> You can subclass SecurityAdmin and set it to use your
> custom Member class, but there's no way for an administrator
> to tell the system which "type" (=subclass) of Member he wants to
> create.
>
> We usually solve this by using DataObjectDecorator and "roles"
> instead of subclasses. This means that all Member objects will have
> all properties. This is recommended if you're building modules
> like forum, to avoid inheritance issues. For your own datamodel
> it might be cleaner to use different subclasses though, instead
> of having a bunch of NULL fields in the database, and lots
> of nonsensical/orphaned properties/methods on the object
> instances.
>
> Do we want to support this by (optionally) allowing
> to choose the Member subclass in SecurityAdmin
> when creating or editing records through a "type" dropdown?
> What other APIs and interfaces would need to adapt to this type  
> selection?
> All groups would still list all Member subclasses to avoid  
> overcomplicating
> the interface.
>
> -------
> Ingo Schommer | Senior Developer

> SilverStripehttp://silverstripe.com

[Sigurd Magnusson]

From a usability perspective it is convienient to find newsletter
recipients in both the security and newsletter area. It makes the
information more findable (and thus editable, exportable, etc.)

[dizzystuff]

I'm currently in the process of building a system with this issue, multiple member types with distinct profile info each and users can be multiple types of Member simultaneously.

The 'bloated member table' issue irks me and moving the extra columns to a separate profile class per Member type sounds great.

This thread is nearing a year old - is there any chance that the above dot notation that Sam suggested has made it's way into the core somehow?

If it hasn't, would I face any major inefficiencies by setting my system up in the way rather than simply extending the base table?

Cheers