name field

Just to summarise what I feel were the two different approaches me and you discussed at Drupal Con

1) Joachim: We store the full name name within one "field" and we build in some form of magic that splits the name up when needed (I think you were suggesting a "sort-by" "field" in the database)
2) Me: We store every single possible section of the name in seperate places (maybe seperate fields, maybe seperate fields in the database) and then build some form of magic that pulls the name together.

The reason why I say "Field" is that I don't think I know where things should be a field as in "field api" or in a new column in the database, or whatever. To be the issue is whether we are splitting the name up, or pulling it together or a mixture of both.

So near the end of that wc3 article they have an area called "To split or not to split"? The thing is their version of "not splitting" is just what we have in drupal today. Its not quite the same thing as Joachim's idea. They actually specifically say "Be careful, also, about assumptions built into algorithms that pull out the parts of a name automatically". However seeing as we're making this as a generic name module, its possibly that we could do this really well.

I think where our use case differs from that article. Is they are talking about how to build a form. Whereas we're trying to build a form that stores things in such a way that potentially ALL the nationalities that we support could be in one database in such a way that our CRM could work with them all nicely.. Thats going to be quite complicated.

I feel like rather then seeing this as a "name field" module. It might be more helpful to see this "Name module that solves all your different naming field needs" as I think its possible we might do this as one field, or a whole range of fields?

Will try and spend some time following the links in that article to see if there are clues as to how other CRMs have solved this.

I think there are 4 ways we could deal with storing this kind of data.

1) No special treatment of names. (Which I think is what you've just suggested?) where we ask for the name in a text field and allow site builders to create other fields if they like, this also gives users the option to use the fullname field or their specific one. We can then build ordered sorting that sorts by these extra fields if they are there. This is definitely the most generic and simplest but we'd need to build some "CRM primitives" concept if we want to go down allie's route. We'd need some way of the generic fields knowing that they are a "family name" if they are to intergrate with other CRM packages.

2) Store extra data in seperate columns. We could have a single name field with a huge number of columns for every single possible combination of name parts that exist. The field would then magically pull these columns together.This way would mean that every name field would have loads of empty columns, and then we have issues with some people have more then one middle name and so maybe we'd have to use multiple tables that are related?

3) We could create a sort of pseudo field that pulls information from lots of other fields. Each name part would be stored in a different field. This is sort of like 1) but now the field doesn't store data itself (except for maybe where it should find the name parts and how it should bring them together)

4) We store all the data in one field and one column and build stuff that pulls the information together as discussed in my first post.

-----------

Personally I think its clear that 1) is what we do for now but possibly move to 3)?

There's also https://drupal.org/project/addressfield, which does names and addresses to the xNAL standard: http://xml.coverpages.org/xnal.html. It's used by Commerce to capture user data, and comes with a really nice widget that lets you choose the country to start and provides appropriate fields for the rest.

I haven't seen address field doing names, but I'm sure we could use alot of their work.. The really clever thing about the the solution in #4 is the widget...which I think Is cleverer than Address Fields (although I may be wrong). I'm working on something similar for bible field at the moment.

Out of interest, why do we not want to use subpieces? (Assuming by sub-pieces you mean having multiple columns in the field table)

We'll use multiple columns in the field table, but only one single name field for the user to enter their name in.

Yup ok :) I agree with you then - that's what I thought you meant by sub pieces.

The customer profile system in Commerce has a single field name system built into the standard billing profile. I'm not sure if this is baked into addressfield or not, but it makes for a nice clean interface.

The solution referenced in #4 makes a lot of sense if the UI can be worked out.

I like this, however it would be interesting to see how this would work with party labels:
#1299914: make Party label customizable

Name does this!