AJAX form_autocomplete() field

Works on Firefox @ MacOS.

Don't mean to throw a spanner in the works, but I get an error if the request I type does not match any in the database/ file it is looking through.
-- Begin Error --
JavaScript
An HTTP error undefined occured.
http://brandedthoughts.co.uk/recipe/ingredient/autocomplete
-- End Error --

Would it be best to have it display an ' informative' error message, or stop trying to 'guess' if it definately can't find a match?

BTW: I am using Safari 2.0 Mac OsX (you don't say :P )

The error no longer shows, so that issue seems to be fixed (in Safari 2 anyway. As far as I can tell, this is the only browser that it occcured in).

one more nit - pressing escape should ideally caused tghe autocomplete div to disappear. sometimes it is not wanted.

please submit a patch against HEAD, if possible.

After typing a number of short terms, I start getting incorrect results. It seems mostly to happen with words starting with the letter "b", oddly enough.

In Opera, the page scrolls when you use arrows to select results. The cursor doesn't move to the end of the selected word after you press Enter. If the list is open with an item selected and you tab away, the list doesn't disappear.

I also so some weirdness in Firefox and Opera when using the mouse to select entries. Sometimes the drop-down wouldn't disappear.

I tested with Opera 8.0 and an internal build of 8.01 on Windows XP. I'll see if I can find a way to reproduce the problem. E-mail me if you have any questions about getting stuff working in Opera.

What is the status of this? I'd like to see this move forward. Are you going to roll a patch Thox?

I believe UnConeD (Steven) provide some feedback on IRC. Is that correct? I hope this patch can be committed shortly but I'll hold back this patch until approved/reviewed by UnConeD.

No new patch attached?

Sometimes JS function names start with a capital letter, somethings with a lower-case letter. Please stick to lower-case letters.

What does one write in English: auto-complete, auto complete, autocomplete or AutoComplete? The patch mixes these.

The patch does not respect my clean URL setting. It tries to access user/autocomplete whereas that should be ?q=user/autocomplete.

Is the exit() required to avoid the output of user/autocomplete from getting cached? If so, please document this in the code.

Can't this be implemented as an extension of form_textfield()? A form_textfield() with callback set to NULL would fall-back on being a regular textfield. Like that, it is _easy_ to disable the AJAX-ity of a textfield (eg. when it turns out to be a performance problem).

If there are performance concerns, I'd prefer to have a global setting where I could swictnh Ajax off for my site.

Also, I think the permission for user/autocomplete isn't right. Anon users shouldn't have access, I suggest 'access user profiles' or 'acess content' as permission.

Hmm, now I see it has changed from the first version of the patch. "administer users" is a bit too stong, IMHO. We should keep other use cases in mind.

allthough i think Gerhard is right about the access users thing, I beleive we should not let this AJAX thing be held back because of that. The user blocks like latest users et al display lists of users too, even if one has no permissions to access user profiles. IMO the user system needs some rethinking, to provide lower level access permissions, But that is far out of scope for this ajax thing.

+1 for simply returning all users.

Elsewhere we print usernames too. We deny access to the profile pages, not to the user names. But yes, we should be careful about other people (external sites) abusing another site's autocomplete callback to obtain sensible information.

Can we remove the $limit parameter from the callback? It let's people (external sites) retrieve all usernames in one go. I think we can safely hard-code the number 10. It makes the callback less vulnerable to abuse.

Everybody seems to think that if I complain about permissions I'd be complaining about too loose permissions. This time I have been complaining about too strict permissions...

But I can of course implement my own callback, so just forget my comment.

Here is an improved patch:

• Use more neutral color scheme (grays). I wanted to use CSS2 system colors (WindowText, HighlightText), but Safari does not support them.
• Get rid of hand cursor (confusing), use arrow instead.
• Fix 404 with clean URLs off
• Implement global killswitch: it checks which browser/js-features are supported and only if all are supported is any JS executed.
• Make codestyle more like Drupal's.
  Note: in #drupal we agreed to use studlyCaps instead of drupal_naming for Javascript. This is consistent with the DOM's casing and thus cleaner. JavaScript also has the convention of keeping acronyms at the beginning of names uppercase. So "getFile" but "HTTPGet" and "XMLHttpRequest".
• In menu callback: implode, then escape all usernames at once (tiny bit faster).
• Added "form-autocomplete" class to editbox
• Added support for a 'throbber': a little indicator of what the box is doing. The JS sets a class that can be styled by the theme, but by default there is no throbber.
• Hardcode $limit to prevent abuse

Here is an example throbber. It uses the CSS sprites technique so it does not need any pre-loading for the animated part.

Copy the .gif to misc/ and then put this at the bottom of drupal.css:

input.form-autocomplete {
  background: url('throbber.gif') no-repeat 100% 2px;
}
input.throbbing {
  background-position: 100% -19px;
}

Shipping such an indicator with core could be considered a usabilty improvement, and it also makes Ajax features easier to use and more visible.

CVS diff seems to freak out on this patch, there were two broken lines in it. I also left in some debug code.

Hopefully this patch will work.

(sorry for the patch-tsunami)

I was examining Gerhard's autocomplete feature for folksonomy tags and noticed a usability problem:
the suggestion's text in the list must be exactly the same as the value that is going to be entered in the text box.

Thus, when you have the text "drupal, coding, f" in the folksonomy tags box, the suggestion list might offer you:
drupal, coding, flowers
drupal, coding, fun
drupal, coding, foo

This is not a very good way to present things: as you add more tags, the suggestion list gets more and more cluttered with tags you already have. Furthermore, Gerhard actually underestimated the folksonomy patch: you can enter tags with commas in them by using quotes. And to use quotes inside quotes, you must "do it ""like this"". ". Wouldn't it be nice if the suggestions list showed the actual tag name rather than its escaped form?

Sure and there is an easy way to solve it: instead of returning an array of strings, return an array of key/value pairs. The key is the string that will end up in the textbox, while the value is the string that is displayed in the suggestion list.

This allows us to show only:

flowers
sex, drugs and rock and roll
foo

but still correctly fill in the value in the box when you select one of them (drupal, coding, "sex, drugs and rock and roll").

The logic for which value belongs to which key is all done inside PHP so you get a lot of flexibility in this. To the end-user, it looks like we have some advanced JS that can fill in the ajaxed tag suggestion into the list ;).

In fact, you can start presenting rich results: e.g. image thumbnails or popularity scores for folksonomy tags (or larger font). We have a lot of possibilities with this for the future and it makes the form_autocomplete API even more interesting.

There was also another problem: results are returned as a string with pipe (|) separated items. If a string contains a pipe, the results are messed up because no escaping is done.

To make all this easy, I added a function drupal_implode_autocomplete(). It takes a PHP array, whose keys are the textfield values (e.g. "drupal, coding, flowers") while the values are the suggestion list strings ("flowers").

The function replaces pipes in keys and values with the entity &#124; (to prevent conflicts), puts a single pipe between each key and value, and two pipes between each array item. This format is decoded again in the Javascript and used automatically. The suggested textbox values are stored in the DOM nodes for the suggestion <li>s, so they are automatically freed when the suggestion box is hidden.

Because the changes in this patch are very much tied to Gerhard's patch, I integrated the two patches into this one. They are both excellent, clean applications of autocompletion.

Last one, I promise :P. Missed a space.

The function names are not consistent. Sometimes underscores are used, sometimes not. Sometimes HTTP is used, sometimes Http. Sometimes function names start with a capital letter (AbsolutePosition), sometimes with a small letter.

Otherwise, this patch looks perfect.

No rest for the wicked?

Bah, read your follow up too late =P. I cleaned up the naming in the .js files so they are all studlyCaps now (save for the abovementioned leading acronym rule for functionnames/classes). The only inconsistency is in the DOM where event names are always lowercase "onkeydown" and not "onKeyDown". Nothing we can do about that.

If you give me the green light to commit, that would be nice. I don't feel like submitting yet another patch ;).

Feel free to commit. Glance over the JS names once more, just to make sure. Now we are working on JS, can we (Thox, Steven, et al) take a look at the collapsible page elements. ;-) Rock on guys.

Committed to HEAD.

It doesn't work correctly under Konqueror 3.4. Items cannot be selected with the keyboard.

Also: I want to know whether I would be able to disable any AJAX functionality on my Drupal-based site if I upgrade to a future version which includes AJAX. Would this be possible?

Killes sayeth:

If there are performance concerns, I'd prefer to have a global setting where I could switch Ajax off for my site.

Is it possible to set different throttle threshold levels for different modules? If so, it would be smart to set a very low threshold for the ajax "module" (it's not a module is it?)...

This way it would drop out when the site started to get busy.

Maybe the ajax functions should do some self-throttling...

-Jeff

This is very cool, but I have some other enhancements i'd like to see. ;-)

1. The ability to have more than one autocomplete on a form.
2. The ability to have autocomplete set a seperate field as an id. Eg you choose an username based on the spelling, but it sets a field with the actual "id" of the user. This would be user more whith node_autocomplete perhaps.

Simon

1. The ability to have more than one autocomplete on a form.
2. The ability to have autocomplete set a seperate field as an id. Eg you choose an username based on the spelling, but it sets a field with the actual "id" of the user. This would be user more whith node_autocomplete perhaps.

would really be cool and usefull

whats about a autocomplete feature for the search box?

Wonderful work, I'm currently trying to adapt this to live searches.

I for my part am a bit worried about 2 things:

1 - Ajax stands for Asynchronous javascript and XML, and the xml part is somewhat important IMHO.
the reason is that we are all moving to webservices, and I think the format returned currently by the user_autocomplete for example is a bit worrysome, because it's not standard at all.

the best way to do that would be to have an alternate search results page, displaying the results in an xml formatted way, and then parse that into the component..

that would allow other sites to perform searches on your site in a compatible, formatted way.
of course that wouldnt be an option for user searches, but why not go the standard way anyhow ??

DOM parsing can be powerful too, and the overhead compared to the pipe separated list would be well earned.

for example there is no easy way to extend the autocomplete component to handle more than a key:value pair.
what If I want to include a "last updated" field, or a 'user' and a 'section' field.

multiple field results would be handled really easily by an xml formatted response.

2 - that's not completely related, and more of a personal preference, but the inclusion of drupal.js, autocomplete.js etc... is causing me worries, because I already use my own flavour of web2.0 widgets and such.
for the record, I use
- prototype.js (ajax+js framework),
- behaviour.js (unobtrusive js, elegant window.onload handling),
- and script.aculo.us libraries (kick ass effects),

I'd be happily discarding them to use the drupal options, if they provided me with the same flexibility, but that's not the case.

Thus, I have 2 sets of ajax frameworks, and more and more duplicated funcitonnality.

Why recreate the wheel, these libs are becoming more and more widespread, and provide more than the drupal developped ones could, because of the dedicated work on these.

Reopening as the last comment is valid IMHO and deserves at least some discussions. If this issue is closed, noone will notice...

The goal of Ajax in Drupal is to provide a more responsive UI, not to provide webservices. If you really want to use Drupal as a service, you're much better off using standardized formats, like RSS or OpenSearch. XML or not, our Ajax calls are still going to use a compact, proprietary data structure that is suited for the task at hand.

For example, the autocomplete API is limited to key/value pairs because that is all that is needed: the key is the textfield value for this suggestion, the value is the HTML for the suggestion. You can put anything you want in there: user pictures, popularity counts, etc. The HTML that is sent is themed, so it is site-specific. There is nothing webservice-like about it.

Now if you need extensibility in your datastructure, then JSON (JavaScript Object Notation) is the way to go: the benefits over XML are huge. It is more compact, is child's play to parse and use in JS (eval()), and child's play to construct and send from the PHP side too (take a look at the tiny Drupal API call to generate JSON). Why should we force the data into a bloaty XML structure when JS and PHP's data-structures are so similar?

I'd be happily discarding them to use the drupal options, if they provided me with the same flexibility, but that's not the case. Thus, I have 2 sets of ajax frameworks, and more and more duplicated funcitonnality. Why recreate the wheel, these libs are becoming more and more widespread, and provide more than the drupal developped ones could, because of the dedicated work on these.

Nothing prevents you from using your own library: Drupal's JS is architected so that only those files are included that are actually required on the current page. If you don't use any of the Ajax-using APIs in your module, none of Drupal's .js files will be loaded.

The reason we have our own code is because we simply don't need an extensive library in core. Drupal's modularity and themability means that there is very little certainty about the HTML output. Graceful degradation is a must. Conclusion: we're not going to rewrite the UI to a whizz-bang Ajax application anytime soon.

Still, Drupal's current JS code was written with the typical architecture of today's JS/Ajax libraries in mind (e.g. adopting a "widget"-like approach for the different bits and pieces of UI). This means that if we want to switch over to a different library in the future, doing so will not be difficult.

Hi,

I patched my drupal 4.6.5 using the latest autocomplete patch. However, when I attempted to use the user automcomplete feature, I got a window poping up and had the following error:

An Http error 404 occured
http://www.kzeng.info/user/autocomplete

Could you please tell me what is wrong? Thanks a lot!

I've submitted a bug report.

http://drupal.org/node/52365