Remove displayName ?

[bakura10]

Hi,

I can see the use of the username property (even if it's not used, it's often useful it tons of projects). However, I'd be for removing the displayName property. Most of the time, people use "firstName" and "lastName" (I already had a display name in some clients websites that ended being simply a free input where people would enter first name and last name, but it's just a hell to normalize then). I think most of the time this property will be disabled in favor of first name and last name, so I'd say maybe we could remove it (so less nullable inputs).

Thoughts @DASPRiD @Ocramius ?

[DASPRiD]

I actually see many use cases for it. One may just override the getDisplayName() method to aggregate it from first and last name.

[bakura10]

Yes. The method. But not persisting this in Db.

Envoyé de mon iPhone

Le 28 août 2013 à 20:23, Ben Scholzen notifications@github.com a écrit :

I actually see many use cases for it. One may just override the getDisplayName() method to aggregate it from first and last name.

—
Reply to this email directly or view it on GitHub.

[Ocramius]

It could be an amorph field with metadata...

[bakura10]

metadata in displayName ? To me display name is like a computed properties, so it makes no sense to store this.

[Ocramius]

No, metadata in general. And no, displayName != "$firstName $lastName"

[Ocramius]

After a bit of discussion with @bakura10 I'm +1 on removing this.

We can discuss adding user metadata later on, but the displayName is clutter, and probably a View Helper problem more than a data modeling problem.

[DASPRiD]

Could you paste the discussion, or, the relevant part of it?

[Ocramius]

The point is that displayName varies between different systems/locales or even applications (because every second customer wants a different way of displaying usernames).

It may be including a prefix, it may not, it may be always prepended by something, it may be a composition of other fields.

Basically, the problem is that it is a view layer problem, while it's very blurred in data definitions.

A $this->displayName($this->getIdentity()); view helper utility may be more fitting here, since it could either use the existing data of the user, or just fetch metadata from somewhere else (a displayName field on another table or on a JSON blob field for example)

[DASPRiD]

Okay, I agree with that. So solution:

• remove display_name from the entity
• supply a default displayName() view helper (can be overriden by the user), which either display the username if activated, or email address otherwise.

[bakura10]

I agree with that an the view helper :).

Envoyé de mon iPhone

Le 29 août 2013 à 13:38, Ben Scholzen notifications@github.com a écrit :

Okay, I agree with that. So solution:

remove display_name from the entity
supply a default displayName() view helper (can be overriden by the user), which either display the username if activated, or email address otherwise.
—
Reply to this email directly or view it on GitHub.