Allow arbitrary string and still have autocomplete
| Project: | Autocomplete Widgets for CCK Text and Number |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | won't fix |
This module is great, but lacks a functionality I should be using: allow arbitrary strings to be entered and still have autocomplete working. The attached patch (rolled against today's -dev) adds a new checkbox called "Accept unlisted strings" to the widget setup form (?q=admin/content/node-type/$node_tpye/fields/$field_name), which is unchecked by default. If it's unchecked, everything works as usual. If it's checked, arbitrary strings can be entered as there is no validation (and no checking of #default_values), but the autocompletion still works.
Use case: there are various authors of publications at a university department: colleagues (content type: "colleague") and outside authors (they don't have any content nor content type). Both colleagues and outside authors should be allowed as authors of a publication (content type: "publication"). We can't use a nodereference (as outside authors don't have a node, according to customer's requests). The authors listed in arbitrary order, both colleagues and outside authors mixed up (thus we use an unlimited multivalue textfield), but names of colleagues should be displayed as-is. To ease the correct input our customer asked for autocompletion on colleague names, but still wants to be able to enter outside authors - so we forged the attached patch, which solves this scenario.
A new stable version (preferably with this patch attached) would be gladly welcomed.
| Attachment | Size |
|---|---|
| autocomplete_widgets-suggest.patch | 3.73 KB |
#1
It looks like something useful. One thing I see in the patch that needs work. The autocomplete for allowed values widget is available for Text, but also for Number fields. However, this new option should only be available for Text fields because we cannot store the non-listed values as numbers.
[EDIT] Another thing that I'm not sure how it is solved is... when this new option is enabled, the autocomplete should provide candidates from existing field values as well as values from the allowed values list.
#2
I forgot to mention that this feature only kicks in when using the allowed values list, but have nothing to do with existing field values. And yes, you're right, to be honest I haven't tested it with Number fields (yet) - but it should not be quite difficult to filter out these as well.
#3
Here's another approach that you could try without altering this module.
Try with an autocomplete for existing values widget. This will bypass the validation of the allowed values list. Then, using jQuery, replace the autocomplete path of the form element with your own. The menu callback of your autocomplete element could provide values from an arbitrary list based on something the site administrators can maintain somewhere else, such as users, taxonomies, nodes, ...
If we have to modify the module, then I think we need an additional option to define if autocomplete candidates are restricted to allowed values list, or can come from both sources (allowed values list and existing values).
#4
I'm not planning to add the suggested feature because a) it will complicate things here, and b) there's an alternative approach to get the same result, as outlined in #3.
#5
anyway, it's a good idea for text
[edit]
I test it; the "additional option to define if autocomplete candidates are restricted to allowed values list, or can come from both sources" adds a nice feature and makes it grow the module functionality.
I'm thinking of coding for internal development.
#6
the patch for the 6.x-1.3 version (after the security update)