Patch to add customizable autocomplete path
jrbeeman - October 16, 2007 - 20:37
| Project: | Textfield Autocomplete |
| Version: | 5.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
Jump to:
Description
I have attached a patch that modifies the textfield autocomplete module to allow a customizable autocomplete path. If the field is left blank, the module behaves as it currently does.
| Attachment | Size |
|---|---|
| textfield_autocomplete-customizable-autocomplete.patch | 3.7 KB |
#1
#2
Hi,
is there any way that the module could check the field's "Allowed values" instead of the values already submitted before? I'm not sure your patch is meant to do that but maybe you have an idea.
Thanks!
#3
A very useful alternative functionality! Will this be applied in D5 and D6?
#4
I am curious on why would you like to use a different path for the autocomplete feature. As far as I can tell, this is a path that the user will never see.
#5
It would be most valuable. I wrestle with a site that has close to hundred thousand items to autocomplete here - but they are structured, so if there was a way to pre-define a part (beginning) of the path, it would allow for quicker autocomplete of sub-group of the items. So, in general, this is an easy way (one setting in the content type settings for this field) to limit the number of fetched matches on large sites (and sites, in general, are growing large). Thanks for your efforts in porting this to D6, crossing fingers, you've got my support.
#6
AFAICT, the autocomplete path here is built in the form
'textfield_autocomplete/'. $field['field_name'], and this is similar to other autocomplete paths, such as those used by nodereference, etc.You just have one menu item defined with the first argument of the path, and the second argument is passed to the menu callback as the first function argument.
Said menu item should be defined as MENU_CALLBACK type, so it is not displayed in any user visible menu.
I still don't see what the benefit is if the site admin can change the first argument of the autocomplete path. If there was something relevant, wouldn't it be a common issue with any other module implementing autocomplete elements?
#7
Further... the patch posted on top would not work unless it is also patched the hook_menu() implementation of the module, and the whole menu caches are forced to rebuild after changing field settings when autocomplete path is changed.
The propossed solution would have to generate different menu items for each field, where we already have one that is able to deal with any field. We would be adding more menu items to the system where it is not really necessary.