I was struggling trying to get the autocomplete feature to work with a list of keys and values where key is a unique_id and value is the textual name. I found a couple of solutions ([#354625] and #322383: Autocomplete nid/vid extraction. i.e. CCK Nodereference) but they were either too complicated or too intrusive. I felt that if I could just hook onto the act of selecting a value, I would be able to solve my problem.
So, I wrote this patch that uses jQuery to trigger a custom event "autocomplete_select" whenever an item is selected. With this event in place I can now do something like this:
Drupal.behaviors.autocompleteSupervisor = function(context) {
$("input#edit-autocompleteField", context).bind('autocomplete_select', function(event) {
var values = $(this).val().split('|'); // my key was a pipe-delimited string (name|id)
$(this).val(values[0]);// set the value of the field to just the name part
if (values[1]) { // if an id was found...
$("input#edit-recommendedSupervisors-0", context).val(values[1]); // set the val of some other field to the id
}
});
};
Comment | File | Size | Author |
---|---|---|---|
#54 | ac_select_event-365241-54.patch | 1.23 KB | skruf |
#47 | autocompleteSelect.js_.patch | 1.05 KB | paulmarbach |
#45 | autocomplete.js_.d7_autocompleteSelect_event.patch | 1.06 KB | paulmarbach |
#31 | ac-select-event-365241-31.patch | 566 bytes | xjm |
#18 | ac_select_event-d7.patch | 683 bytes | bcn |
Comments
Comment #1
chuckdeal97 CreditAttribution: chuckdeal97 commentedI was trying to reference this page: http://drupal.org/node/354625 which is a one-off solution to #322383: Autocomplete nid/vid extraction. i.e. CCK Nodereference. In both cases, my solution should work and be simpler and less intrusive.
Comment #2
andreiashu CreditAttribution: andreiashu commentedNot sure if this is already in 7 but it would be useful.
Comment #3
malks CreditAttribution: malks commentedHi,
I'm trying to get this working, and think I've loaded in the javascript (used hook_nodeapi()) but can't quite get the desired result :/ Javascript not my strongest point, have tried debugging in firebug etc. and while it looks like the trigger in the patch is getting fired I don't know how to work out if my code in the behaviours is being run...
Any help much appreciated.
Anthony.
EDIT: just with hook_nodeapi() what value of $op should I be loading in the code? I thought "prepare" might be best but I can't seem to get a prepare event so have tried using "view" and "alter" but still not much luck.
Comment #4
chuckdeal97 CreditAttribution: chuckdeal97 commentedI don't have access to my code repo at the moment, so I don't have an answer about how to use hook_nodeapi. But as for your other problem of not knowing if your js behavior is firing...have you tried old school debugging and put in some alerts? It's not scientific, but sometimes it helps. I usually place an alert at points just before and just after some choice is made (an if stmt, function call, etc) so that I can attempt to follow the workflow via the alerts that pop up.
If you do a view source on the generated page, do you see a reference to the new javascript?
Comment #5
malks CreditAttribution: malks commentedHey,
Thanks for the response. I did put some alerts in (old school lol) one before the anonymous javascript function and one inside the function. The first did appear but the second didn't. Where should I see the javascript code if it's attaching correctly?
I'm not sure if I've got the right name of the element to attach to as I notice in view source that there is an input with the id (just a quick one, it shouldn't be the name should it?) "edit-project-test" and a hidden one which does the autocomplete with an id "edit-project-test-autocomplete" and I'm using the first (but have tried the second) with no luck.
I definitely feel that I'm not loading the javascript in the right place so will try hook_form_alter() I think or maybe some theme statements.
Anthony.
Comment #6
malks CreditAttribution: malks commentedUsing the hook_form_alter() did the trick. One last question... I followed your example and it works but in the select list I'm still getting the "full" value, i.e. it shows "Project|13" even though it is correctly storing Project in the autocomplete field and 13 in my id field. Anyway around this?
Thanks,
Anthony.
Comment #7
chuckdeal97 CreditAttribution: chuckdeal97 commentedSorry about the delay. Here is the js function I use
My values are displaystring|value pairs, so I split the string on the '|' and put the displaystring back into the autoselect field and I have a hiddenfield paired with the autocomplete that receives the value. Upon submit, both the displaystring and value will be available to you.
Comment #8
malks CreditAttribution: malks commentedHey again,
That's what I've done (read: blindly copied) already and it works, that is I get the display string in the autoselect form and the value in the hidden field correctly... BUT in the dropdown that has the values computed for the autocomplete it still has the unparsed value, that is with the '|' in it. Is there anyway to get rid of that? Not a biggie, no one has actually complained about it, just chasing it up for completeness :)
Thanks again,
Anthony.
Comment #9
esteewhy CreditAttribution: esteewhy commented@chuckdeal97
Charles, your solutions works like a charm! What can we do to push this into the core ?
The only minor improvement i'd ask is this:
With this in place, i think you won't need pipe-trickery above:
Comment #10
esteewhy CreditAttribution: esteewhy commented@andreiashu
Andrei, can you please suggest, if the discussed feature has a chance to make it's way into 6.x ?
Comment #11
sotiris CreditAttribution: sotiris commentedsubmit
Comment #12
Alan D. CreditAttribution: Alan D. commented+2 For D7 and backport to D6
Trying to combining autocomplete & AHAH is trivial using the new listener, but near impossible with standard listeners. (the keystrokes were being really painful)
The following is a D6 example using the original patch above:
The autocomplete 'autocomplete_select' event triggers what would have been a 'change' event. So when the autocomplete is really finished, the AHAH request is triggered.
Comment #13
bcn CreditAttribution: bcn commentedAs per #9
Comment #14
bcn CreditAttribution: bcn commentedMinus the whitespace in the patch above....
Comment #15
bcn CreditAttribution: bcn commentedI've been testing this patch out for a couple weeks on D7 and it seems to work fine.. Has anyone else tested? Anyone else ready to RTBC this?
Also, attached to this post is a drupal 6 version of the patch (zipped so it doesn't get tested), which also seems to work fine for me..
Comment #16
bcn CreditAttribution: bcn commentedPatch from #14 (and #16) is missing:
Will reroll soon...
Comment #17
bcn CreditAttribution: bcn commentedHere's an updated patch for Drupal 7...
Leaving this at 'needs work' because it seems with this patch applied, the "autocomplete_select" event is getting triggered twice, when the mouse is used to select an option from the list of autocomplete result choices. If the selection is made with the enter key, the event only fires once..
Comment #18
bcn CreditAttribution: bcn commentedMaybe this will work... I moved the triggering function around a bit, and it seems to fix the issue of double firing for mousedown (click) events.
the .zip attachment is for Drupal 6...
Comment #19
mdeltito CreditAttribution: mdeltito commented@noahb
I just added this functionality myself in the same manner, and I rolled my own patch that matches yours exactly. Thus, I can confirm that this patch is tested working for Drupal 6.
Comment #20
bcn CreditAttribution: bcn commentedtagging...
Comment #21
clashar CreditAttribution: clashar commentedI tried patches for Drupal 6 from #15 and #18, but still no effect. Maybe I am confused as I imported only 2 lines of code.
Or maybe I am confused with functionality, should I see both Autocomplete and Select options simultaneously together?
Comment #22
bcn CreditAttribution: bcn commentedAt this point features would likely have to be delayed to 8.x
Comment #23
chris.jichen CreditAttribution: chris.jichen commentedautocomplete.js_.patch queued for re-testing.
Comment #24
Alan D. CreditAttribution: Alan D. commentedThis is not an API change, just a minor addition, so D7 should be alright. While the core Autocomplete sucks, hopefully some of these patches get in....
Comment #25
Ajenjo CreditAttribution: Ajenjo commentedautocomplete.js_.patch queued for re-testing.
Comment #26
webchickSounds like a nice feature, but we don't do features at this point, and it sounds like there's a workaround, albeit sub-optimal.
Since this is fairly non-invasive though, it might be something we could conceivably backport from D8 in a point release of D7.
Comment #27
jerdavisI came across this tonight when trying to add auto submit to DamZ's d7 port of editablefields. I'm wondering if we could just add $(this.input).trigger('change'); and use a standard event? What do we gain by declaring a custom event?
At any rate, I'd love to see this included in 8 and back ported to 7. It seems more or less required if you want to try and make any autocomplete fields do a ahah form submission when selecting an existing value.
Comment #28
catchAdding needs backport tag, looks like that might need some discussion but also doesn't look out of the question.
Comment #29
xjm#18: ac_select_event-d7.patch queued for re-testing.
Comment #31
xjmRerolled for current D8; assuming this is still RTBC based on #24 and webchick's review in #26.
Comment #32
sun1) Underscores are rarely used in JavaScript, so I think the event name should be 'autocompleteSelect'.
2) Why don't we pass the entire
this
object to event listeners?20 days to next Drupal core point release.
Comment #33
webadpro CreditAttribution: webadpro commentedsub
Comment #34
webadpro CreditAttribution: webadpro commentedoups
Comment #35
xjmI think it's still NW for #32.
Comment #36
webadpro CreditAttribution: webadpro commentedSo what do I need to change in D7 to get this to work?
Do I only need to use the path at #31 to get this to work?
Comment #37
webadpro CreditAttribution: webadpro commented@checkdeal97 - #7 ... Whats does your form element look like?
Comment #38
jerdavis@webadpro you can either patch core, or you can also "fix" it for your own module(s) by overriding the core JS, see here for an example:
http://drupalcode.org/sandbox/damz/1130436.git/blob/refs/heads/7.x:/edit...
Comment #39
webadpro CreditAttribution: webadpro commentedThanks, but my question was what does his form element looks like? Do I need to have 2 elements to get this working?
Comment #40
jaxxed CreditAttribution: jaxxed commentedI would also like to support this change.
The first line change is a no-brainer. Why the key-based update is directly updating the input element, when there is already an abstraction is confusing.
The addition of the select hook is also great, but perhaps we should just trigger the 'change' event?
Comment #41
Everett Zufelt CreditAttribution: Everett Zufelt commentedSee #675446: Use jQuery UI Autocomplete
Comment #42
RobLoachEverett is correct... If we adopt jQuery UI, we will get the select event, along with much more.
Comment #43
Alan D. CreditAttribution: Alan D. commentedI guess that #675446: Use jQuery UI Autocomplete will not be back-ported? As such, should this issue be assigned back to D7?
Comment #44
mkalkbrennerJust want to mention that #18 works fine for D6. Thanks for that patch.
Comment #45
paulmarbach CreditAttribution: paulmarbach commentedThis patch fixes the mouse event error in #17 and some of these other fixes.
Comment #47
paulmarbach CreditAttribution: paulmarbach commentedreattaching reformatted patch
Comment #48
xjmThanks @paulmarbach. Let's keep the version on 8.x; I don't see that this has been committed to D8 yet. We should also create a patch for Drupal 8 first. Once the fix is committed to D8, it is probably backportable to D7 (and will probably be exactly the same patch except that the files are in different directories). Thanks!
Comment #49
Alan D. CreditAttribution: Alan D. commentedIt looks like the other thread has stalled.
It would be great to push this forward so we can (maybe) get this in so that we do not have to override the core JScript for a few years :?
Comment #50
OptimusPrime23 CreditAttribution: OptimusPrime23 commented#14: autocomplete.triggerEvent.patch queued for re-testing.
Comment #52
nod_7 only, on 8.x this will be provided by jQuery UI.
Comment #53
skruf CreditAttribution: skruf commentedautocomplete.js_.patch queued for re-testing.
Comment #54
skruf CreditAttribution: skruf commentedRe-rolled patch for 7.x
Comment #55
warmth CreditAttribution: warmth commentedGood job! Have you seen this: http://drupal.org/project/autocomplete_deluxe
Comment #56
undersound3 CreditAttribution: undersound3 commented#54: ac_select_event-365241-54.patch queued for re-testing.
Comment #58
a.milkovskyMight this can help somebody.
I use autocomplete change event with some fix - $(this).blur() :
Comment #59
mkalkbrenner#54: ac_select_event-365241-54.patch queued for re-testing.
Comment #60
juampynr CreditAttribution: juampynr commentedPatch at #54 worked perfectly fine.
Comment #61
gaurav-varshney CreditAttribution: gaurav-varshney commentedI have also applied the #54 Patch it works fine every where except in IE8.
is there any way so it works in IE8.
Comment #62
nod_Comment #63
drupov CreditAttribution: drupov commented#54 went ok for me in FF, even with IE8 running through Wine on Ubuntu. I haven't tested it yet in real Windown IE8 environment.
Comment #64
mgifford54: ac_select_event-365241-54.patch queued for re-testing.
Comment #65
Ajithlal CreditAttribution: Ajithlal commentedI am getting error
ReferenceError: context is not defined
I applied #54 patch and my javascript below
$("input#edit-address", context).bind('autocomplete_select', function(event) {
var values = $(this).val();
alert(values);
});
Comment #66
sgabe CreditAttribution: sgabe commentedPatch in #54 applies fine and works fine for Drupal 7.
Comment #67
John Pitcairn CreditAttribution: John Pitcairn commented@Ajithlal: the event is 'autocompleteSelect'.
Patch at #54 applies to 7.34.
Removing the backport tag, D8 uses jQuery UI so there is nothing to backport.
Let's mark this tested and approved, shall we? It doesn't break any existing functionality. IE8 support can be a follow up issue?
Comment #70
David_Rothstein CreditAttribution: David_Rothstein commentedDidn't actually review this, but that's surely a bogus test failure so moving back to RTBC...
I'm not clear on the IE8 situation - is it just that the new functionality doesn't work on IE8 (probably OK) or that it breaks things that used to work on IE8 (not OK) or is fine on IE8 after all?
Comment #73
David_Rothstein CreditAttribution: David_Rothstein commentedAnother bogus test failure, so back to RTBC for now.
Comment #76
mgiffordHopefully we can set this back to RTBC.
Comment #77
othermachines CreditAttribution: othermachines commentedPatch in #54 works for me (7.34).
My test snippet:
Thanks -
* Edit: passed in node obj and demo'd the available data. Took me a bit of fussing to figure it out so maybe it'll help someone.
Comment #78
mgiffordOk, back to RTBC.
Comment #79
David_Rothstein CreditAttribution: David_Rothstein commentedThis seems to replace the double-call to select mentioned earlier in this issue with a double-call to hidePopup... but I guess that's harmless.
It's been many many months and no one else has confirmed any problems with IE8, plus #63 says it works there. So let's go with it.
Committed to 7.x - thanks!
Comment #82
taggartj CreditAttribution: taggartj commentedA quick note on Drupal 8