Download
Say I create a dropdown with values, e.g.
- Value 1
- Value 2
- Value 3
If I decide to rename the values at a later date, this will not affect existing records in the corresponding table, so the values can't be updated dynamically if one decides to change the option titles. dropdowncustomkey instead uses indexes for the keys. So if you choose 'Value 1', what's saved in the database is just '0'. Hence, you can label and relabel your values at any time without worrying how it affects existing data.
Example: with CUsers, I use dropdowncustomkey for the user levels so that admins can re-title the user levels without affecting the conditionals in the coding, since the conditionals use the number keys instead of the titles of the options. So if I want something to affect only administrators, I don't need to worry about the title of the option given (which could be anything) - only the index in the dropdown.
I understand that it's a pretty hokey and unhelpful name to use, but I was running out of ways to easily distinguish between the different dropdown types. If you can provide more sensible ones, I'd change them out in a heartbeat (with backwards compatibility, of course).
*edit* I'm not exactly sure about what you mean for things working before. The original dropdown field from the procedural version of The Matrix works as it did before, where it takes values from an existing table as the labels/titles and the record IDs as the values. dropdowncustom was created to let you create options on the fly with a textarea (like Custom Fields/Special Pages) without having to build a separate table to house them. dropdowncustomkey exists for the reasons explained above.
I should have explained the difference between these dropdown types more clearly in the documentation... :S
- Value 1
- Value 2
- Value 3
If I decide to rename the values at a later date, this will not affect existing records in the corresponding table, so the values can't be updated dynamically if one decides to change the option titles. dropdowncustomkey instead uses indexes for the keys. So if you choose 'Value 1', what's saved in the database is just '0'. Hence, you can label and relabel your values at any time without worrying how it affects existing data.
Example: with CUsers, I use dropdowncustomkey for the user levels so that admins can re-title the user levels without affecting the conditionals in the coding, since the conditionals use the number keys instead of the titles of the options. So if I want something to affect only administrators, I don't need to worry about the title of the option given (which could be anything) - only the index in the dropdown.
I understand that it's a pretty hokey and unhelpful name to use, but I was running out of ways to easily distinguish between the different dropdown types. If you can provide more sensible ones, I'd change them out in a heartbeat (with backwards compatibility, of course).
*edit* I'm not exactly sure about what you mean for things working before. The original dropdown field from the procedural version of The Matrix works as it did before, where it takes values from an existing table as the labels/titles and the record IDs as the values. dropdowncustom was created to let you create options on the fly with a textarea (like Custom Fields/Special Pages) without having to build a separate table to house them. dropdowncustomkey exists for the reasons explained above.
I should have explained the difference between these dropdown types more clearly in the documentation... :S
