Posted by te-brian on June 4, 2010 at 12:26am
4 followers
| Project: | Form Builder |
| Version: | 6.x-0.7 |
| Component: | Form Builder Core |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
Unless I am totally misreading the code, the default associative key_type does not appear to be implemented. In _form_options_from_text() on line 334:
// Check if this row is a key|value pair.
elseif (($key_type == 'mixed' || $key_type == 'custom' || $key_type == 'numeric') && preg_match('/^([^|]+)\|(.*)$/', $row, $matches)) {
$key = $matches[1];
$value = $matches[2];
$keys[] = $key;
$items[] = array(
'key' => $key,
'value' => $value,
'group' => $group,
);
}
// Set this this row as a straight value.
else {
$items[] = array(
'key' => NULL,
'value' => $row,
'group' => $group,
);
}It would appear that if the key type is 'associative', then the $keys will be NULL here, which means they will be auto-incremented when the final array is created just below that snippet.
Also, in _form_type_options_value() on line 237:
$options = form_options_from_text($edit['options_field'], $element['#key_type'], empty($element['#optgroups']), $duplicates);The key_type is being passed from the $element, not the $edit array?
Again, I may be misreading things but in my implementation of form_builder I am having key issues and I traced the issues to these two code blocks.
Comments
#1
I think I'm having a similar issue.
When I try to edit the keys after checking Customize keys, any key that I enter is immediately changed to be the corresponding value. Also, if I choose Manual entry, and edit pipe-delimited key|value pairs, the key|value pair as a whole is treated as the value rather than splitting on that pipe to get the key and value.
FWIW, I'm also using this as part of Form Builder module.
#2
Also, I'm happy to provide a patch if my analysis of the issue is correct.
#3
I've uploaded a patch that I came up with that worked for me. I don't know that it's complete enough to work for everyone, but it certainly lets me handle associative keys.
@te-brian, It sounds like it's the same approach you took. Though, I'd like to see your patch and compare notes.
#4
If you could remove the wh_* module contents that would be helpful for reviewing. Thanks for your work on this.
#5
Yes, I should have uploaded the Options Element specific patch.
#6
Thanks, I'll give this a review when I get a chance.
#7
I've been looking at this today and I think the confusion has arisen because "associative" has taken on a different meaning since the original implementation.
It used to be that "associative" could provide custom keys. This is no longer the case. As noted in the Options Element PHPdoc for options_element_elements():
* - associative: Keys are automatically mapped from the user-entered values.* This is equivalent to making key|value pairs, but both the key and value
* are the same. Each key must be unique.
This patch would cause this behavior to no longer be the case. There is still a problem here, it's that Form Builder isn't using the proper key type. It should be using "mixed" (now the preferred mechanism) instead of "associative". Options Element has been more regularly maintained (since it's in use by Webform) than Form Builder (which is still mostly theoretical).
I'm moving this to Form Builder, since that's where the problem lies.
#8
This patch makes Form Builder use "mixed" key type instead of "associative" and adds support for new Options Element properties that have been added since Options Element was moved to its own project.
#9
Automatically closed -- issue fixed for 2 weeks with no activity.