Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
You can use nodereference or userreference, that already have views integration. The former stores a nid in the field, the later stores a uid. But both have an autocomplete widget that already has views integration.
These autocomplete widgets can only be used with Text or Number fields. The widget doesn't change the data stored in the database. It just provides an input method. So if we had an autocomplete widget for Text and/or Number fields, what would we have to store in the database?
Well, I can see a couple of cases where this could be useful for input:
1. suggestions from a filtered list of already inserted values (dependant from user rights, relationships etc.)
2. suggestions from a filtered list based on arguments passed in a custom autocomplete path
(ie. provide a setting with a custom-path/% to a view)
For example, AFAIK the core taxonomy autocomplete suggestion widget for tags is unfiltered then all previously inserted tags are suggested. With such an improvement Autocomplete Widget could be very interesting for Content Taxonomy too.
Ok, it sounds like it could be usefull a separate widget for Text fields that would take candidates from selected view with support for arguments.
These views would have to generate text, which is what would get in the text field and stored in the database. The source of the data would be up to the site admin. I could grab code from nodereference to implement views selection, but I'm not sure how to add support for arguments.
Also, I wanted to mention I'm pretty busy, so I can tell when I'll be able to work on this.
Just thought about something that could be done. You could use the "Autocomplete for allowed values list" widget and use custom PHP code to build the allowed values list. That could be a function that extracts the candidates from a view or whatever else...
It would be a bit more complex as if there was a widget already made for this purpose, though.
Well, I'll mark this issue as 'postponed' as I'm pretty sure I won't have time in the near future for work out this new widget. #5 describes a possible workaround if someone needs this before any thing is built in the module. And of course, anyone with a patch is welcome.
In fact, I think this issue is "won't fix". You can implement whatever you need, including dynamically generated views, existing views, etc. using PHP to build the allowed values list.
Does have somebody working example of some workaround of this - how to add autocompletefield into views?
I really like this module, I use it in my cck content types, but when I want to build views exposed search based on values in autocomplete fields,
I can't, ok, I can, but with selectbox only, not autocomplete field, and it not possible to use for selecting from 600+ values (cities)
Comments
Comment #1
markus_petrux commentedYou can use nodereference or userreference, that already have views integration. The former stores a nid in the field, the later stores a uid. But both have an autocomplete widget that already has views integration.
These autocomplete widgets can only be used with Text or Number fields. The widget doesn't change the data stored in the database. It just provides an input method. So if we had an autocomplete widget for Text and/or Number fields, what would we have to store in the database?
I'm not really sure what you mean?
Comment #2
gunzip commentedWell, I can see a couple of cases where this could be useful for input:
1. suggestions from a filtered list of already inserted values (dependant from user rights, relationships etc.)
2. suggestions from a filtered list based on arguments passed in a custom autocomplete path
(ie. provide a setting with a custom-path/% to a view)
For example, AFAIK the core taxonomy autocomplete suggestion widget for tags is unfiltered then all previously inserted tags are suggested. With such an improvement Autocomplete Widget could be very interesting for Content Taxonomy too.
Comment #3
markus_petrux commentedhmm... I see. Please, correct me if I'm wrong...
Ok, it sounds like it could be usefull a separate widget for Text fields that would take candidates from selected view with support for arguments.
These views would have to generate text, which is what would get in the text field and stored in the database. The source of the data would be up to the site admin. I could grab code from nodereference to implement views selection, but I'm not sure how to add support for arguments.
Also, I wanted to mention I'm pretty busy, so I can tell when I'll be able to work on this.
Comment #4
gunzip commentedit is all right. thank you for your work anyway! just implement it if you and others think is useful, my 2c..
Comment #5
markus_petrux commentedJust thought about something that could be done. You could use the "Autocomplete for allowed values list" widget and use custom PHP code to build the allowed values list. That could be a function that extracts the candidates from a view or whatever else...
It would be a bit more complex as if there was a widget already made for this purpose, though.
Comment #6
markus_petrux commentedWell, I'll mark this issue as 'postponed' as I'm pretty sure I won't have time in the near future for work out this new widget. #5 describes a possible workaround if someone needs this before any thing is built in the module. And of course, anyone with a patch is welcome.
Comment #7
markus_petrux commentedIn fact, I think this issue is "won't fix". You can implement whatever you need, including dynamically generated views, existing views, etc. using PHP to build the allowed values list.
Comment #8
igorik commentedDoes have somebody working example of some workaround of this - how to add autocompletefield into views?
I really like this module, I use it in my cck content types, but when I want to build views exposed search based on values in autocomplete fields,
I can't, ok, I can, but with selectbox only, not autocomplete field, and it not possible to use for selecting from 600+ values (cities)
thanks
Igor
Comment #9
Grayside commented@ignorik From my reading, that's not on-topic. Though it is why I read the issue ;)