Supporting hcard phone number types

Whilst I don't mind having hCard support, I actually have need for much more varied custom "types", hence the current custom option.

For example, I have need for the following options, not all of which fit into the hCard list above:

Direct Line
Main Switch
Other number
Fax
Mobile
Home

Now, Fax, Mobile, and home can probably match up with fax, cell and home from the hCard standard. Other number can probably be voice, direct line can *maybe* be work, but then I'd have no where to put main switch.

Whilst I don't mind supporting the hCard standard, I have a very strong need for being able to specify custom labels *outside* of translation. We actually have some other code that makes vcards from data in our database, and both Direct line and Main switch map to the "work" type.

I don't mind hCard being the default, but I need to be able to specify other lists of items. Also, if we're going to support hCard fully, then it would be a complete *must* to allow multiple selections. i.e. my Mobile phone is also my preferred phone.

Personally I don't see the allowed values list needing alteration to be a problem. It can be changed as often as people like. The only time they cannot change something, is when they remove a key, for which there is already data. They can still change the label for this key, and they can also write a query to "fix" up any fields with this key in the database. So I don't see any issues with the allowed values list. But I do have a problem with only allowing a fixed list of number type options. I need to be able to customise this beyond the labels.

How would you feel about having the default behavior a list of hcard compliant types, then sticking a drupal_alter() after that list? That is, hcard will be the default behavior, and if you want to alter it, you have to write some code. Is that a reasonable solution?

Yeah. An alter hook will work. That would allow me to provide a custom module that could keep phone working like it is now fundamentally. Let me code something up and post for review. Most of the framework is there, so shouldn't take long.

Question: Are we happy to allow people to deselect a type that is potentially in use, and simply not display a type output for them, or is an actual warning required?

I would much prefer that it's like the field settings...once there's data in the field, you can't change it.

As we're Probably going to want to support custom labels, we can just allow them to enter an empty label, which can mean "don't output", or, a formatter setting of some sort I think.

Custom labels: Site wide config? Or per field?

When we talk about the type, we have the key that is stored in the DB, and the label. I think the keys are fixed, and tied to the field data. The labels themselves can be customised in the instance data I think. At least that was my impression.

Sure, those reasons exist. But the common behavior among fields is that allowed values can't be changed if there's data in the field. If they want to change the allowed values, it can be done through custom queries to move the data around (create the new field, insert all the old values into the new field (substituting where needed), then delete the old field). I think going with the hcard spec is the correct path forward here, and if anyone wants to do anything advanced, an alter hook is not difficult to write (and custom labels can be provided by some submodule in the future if it's a common feature request).

Also, if the values are represented as an associative array with the keys being the hcard names and the values being the user-facing text, changing the label is not difficult with the alter hook (and it doesn't require changing the field configuration).

And, of course, this can all be talked about in the documentation.

If we're going to make all of that require an alter hook, then we should agree on the default labels. :)

This is the current list that I have.

$values = array(
    'work' => t('Work'),
    'home' => t('Home'),
    'cell' => t('Mobile'),
    'pref' => t('Preferred'),
    'car' => t('Car'),
    'voice' => t('Voice'),
    'fax' => t('Fax'),
    'msg' => t('Answering machine'),
    'bbs' => t('BBS (Bulletin board)'),
    'isdn' => t('ISDN'),
    'modem' => t('Modem'),
    'pager' => t('Pager'),
    'video' => t('Video conferencing'),
    'pcs' => t('Personal comm. services'),
    // Note that other is not actually a hcard type,
    // but it's being used as the text equivalent of NULL.
    '' => t('Other'),
  );

On that note, I've committed a initial run at this in a separate branch. You can see the diff at http://drupalcode.org/sandbox/cdale/1925578.git/commitdiff/refs/heads/hc...

Comments thoughts and feedback please. :)

I'm having second thoughts about setting the key of "Other" as the empty string. Initially I thought it would be a good default in the event nothing was entered, but now I'm thinking that other should be another key in its own right, with another "empty" option. The number type doesn't really have a concept of required/not required, so perhaps adding in a faux empty option to allow this field to be set to nothing if people choose might be an idea.

Thoughts?

Ok, other as explicit it is. I'm done for today, so if you haven't done it by then, I'll take a look at patching that tomorrow, and possibly merging the hcard branch back into master if we're happy with it. Again, unless you beat me to it. :)

Only just got back to this now.

I've just merged in the hcard branch, with an actual 'other' option. So that's now in master. I'm not sure if that makes this needs review or fixed? I guess it will be fixed when it's merged into 7.x-2.x.