I am just missing something about names?

Spark uses "name" instead of first name and last name. At first I figured this was fine and that it would be as simple as Laravel's auth boilerplate is to yank name and make it store first/last. Turns out name is used throughout the spark app, which I am apprehensive about changing, because updating spark will surely become cumbersome. Now I know that with spark I can add fields to the registration form in my app.js and spark service provider, but I think it would be a little bit more than stupid to ask someone for their first name, last name, and then their full name. I thought about making name a hidden field and updating its value to the first and last name fields, but that seems a bit like a hackjob. What I am wondering, is if I am just missing something here. As is often the case in Laravel, if something seems difficult you are probably doing it wrong, so I feel like there has to be a better way to resolve something as simple is changing the format a name is stored without locking myself out of spark updates.

I just don't see how a framework designed around doing business online thinks its a good idea to lock people's customers into a single name field (if that's the case). A much more flexible option would have been to have first/middle/last fields and then a name method on the user model to return a concatenated full name rather than locking people into a singular way of storing customer data. Oh well, it is what it is I guess. Looking forward to hearing what can be done about the name.

ohffs

9 years ago

Level 50

I think the idea is that the concept of 'a name' is actually a bit more difficult than programmers often assume. Some cultures only have a single name, some have a 'private' name that, say, the government would use, and a different name which is used everywhere else. And a whole host of other differences.

So imagine someone from a culture where a single name is ok tries to sign up to your application but you insist that they have 'forgotten' to fill in their second name. That might make them a bit annoyed. I used to work with someone who actually quit his job because the organisation insisted on using his 'private' family name everywhere rather than what he looked on as his 'actual' name which was a very, very big deal to him - and I can understand.

Have a read of https://www.kalzumeus.com/2010/06/17/falsehoods-programmers-believe-about-names/ for some more examples. I think the current 'best option' is to ask for a 'formal' name if it's needed and a 'what would you like to be called?' option - but it's a bit of a minefield.

JustinM

9 years ago

Level 4

I see your point and the argument for a single full name field. But I don't think it is the framework's place to make assumptions as to how the developers should implement names in their application. My case for instance, is a service that generates legal documents that have to be sent in to a U.S. government entity. The customer's name has to be broken up into its individual parts and these parts need to be exact or the documents get rejected. I cannot rely on the manipulation of a single name field because as you could imagine users will enter their full name any number of ways, whether its George Martin, George R.R. Martin, Mr. George R. R. Martin or Mr George R. R. Martin IV, and so on.

My gripe is that spark sets the singular name field as a required field for registration and other parts of the app and makes it less than simple to customize how names should be handled in the application. I think a better option would have been a less opinionated implementation making use of a fullName method on the user model, for people that are OK with a single name field, go ahead and provide an artisan command for the boilerplate for that, for everyone else, let them customize the name fields and fullName method so that at the end of the day fullName outputs a string that represents a users full name, or however you want your application to identify them.

There are great scenarios and arguments for and against the single name field. I just don't think the framework or the devs should necessarily pick sides in that. At the end of the day is the clients/stakeholders that should be the deciding force of how the application is built to best suit their needs.

EDIT: I enjoyed the article about names you linked, lots of overlooked stuff in that.

1 like

jlrdw

9 years ago

Level 75

Agree with @ohffs on different names. Sometimes my wife calls me asshole, other times Jimmy. And sometimes F---- asshole.

1 like

Please or to participate in this conversation.