Currently we ship with (in the order they appear in 'Manage Field' pages / 'add new field' UI:
- Boolean
- Decimal
- File
- Float
- Image
- Integer
- List
- List (numeric)
- List (text)
- Long text
- Long text and summary
- Taxonomy term
- Text

Ouch.

- We should consider whether Text and Long Text can be merged.
- I'm actually not sure of the difference between 'List' and 'List (numeric)' / 'List (text)'
- I'm not sure we really need Float. That's a remnant from CCK D5, when we didn't have the more flexible 'decimal' type. For a reason I don't exactly remember, we couldn't migrate those to CCK D6's 'decimal' field type, and kept the legacy 'float' type. I'm not sure it needs to ship in core D7.

Comments

yched’s picture

This is also made worse by the fact that we currently only show 'field type descriptions' ('This field stores a number in the database as an integer', 'This field stores long text in the database along with optional summary text'...) is currently not available at the 'add new field' step, but only once you've created the field.
See #614294: Remove UI description that says what is stored in the field .

bjaspan’s picture

- I'm actually not sure of the difference between 'List' and 'List (numeric)' / 'List (text)'

Me neither. And if neither of us understands it...

Float and decimal are stored and treated very differently. If I understand correctly we'd have to create a decimal(45,7) to store all values from a float, and even then mathematical operations on floats are performed with an IEEE float library while on decimal are performed using fixed-point arithmetic, so the decimal and float fields would still not be the same.

That said, I doubt there are many uses cases for float fields in Drupal. Perhaps it should be moved to contrib?

yched’s picture

Move float to contrib: +1. Too much on my plate right now, though. Any volunteer for a patch ?

About Lists: the only difference between 'List' and 'List (numeric)' is that
- 'List' assumes actual stored values (int) are unimportant. Admin user can simply define the 'value aliases' (e.g. "Choice 1, Choice 2, Choice 3" and we automatically generate the corresponding integer values that will be stored (0, 1, 2)
- 'List (numeric)' assumes actual stored values (int) are meaningful. Admin user should enter actual values (e.g. 0, 10, 20) and their aliases (e.g "Less than 10", "Between 10 and 20", "More than 20")
Both are valid use cases, but both types could and should be merged. The difference is only a matter of the UI for entering the allowed values.
Current UI with one single textarea where you enter stuff like

0|Less than 10
10|Between 10 and 20
20|More than 20

is confusing and unfriendly.

A simple enhancement would be to separate values and aliases into two textareas next to each other:
1st textarea : enter values to be stored, one per line (leave empty to automatically generate 0..n values).
2nd textarea : enter human names for the values, one per line
I'll do that once #639466: hook_options_list() + XSS filtering is in.

Of course the ideal UI would be a table, one row per value, one textfield for the value, one textfield for the alias, buttons to remove and add more. I think form_builder has that. But *I* won't go there in any near future ;-). It can be seen as a "mere UI improvement" over the UI described above.

2nd step: List (text) / List (numeric):
This just affect the type of the 'value' column in the schema. I don't see why this couldn't be a field setting (just like varchar length is a setting for text fields). Once you chose one type, you can't change it back, and we already have that mechanism in place.

That would collapse the three "List / List (numeric) / List (text)" field types into a single "List" type.

philsward’s picture

I'm going to totally agree with this topic and also mention that there is no easy to find documentation (at least it's not where you might think it should be) that explains what the heck all of the field types even do or when you might need or want to use one over the other. Common sense helps explain some of them, but even then, some of them can still be confusing to know what might be needed for a certain situation.

Wanting to create a book review site and an ISBN field for numbers, the logical thing would be "integer". After creating the field for it, I find out that Integer only allows a maximum of 10 numbers. I need 13 for an ISBN number... Looking at Float & Decimal, I don't need those types of separators which makes me think I shouldn't use them. D6 CCK had a field that let you force the maximum number of integers that could be used within a field. D7 does too, but calls it a "value". When I think of a value, I think of the maximum number that could be entered. For example, If I put a value of 5, I think of it as 1 - 5, not "any number between 0 - 99999". Horrible description for it not to mention it states "For an unlimited number, leave blank" but yet still only allows a total of 10 integers.

I'm now stuck with the internal question: "Should I just use a freakin Text Field since it doesn't give a rats ass what I put in or how?" and hope I don't end up with any alphabetical fat fingering...

Sorry, just frustrated...