Solving Problems with YUI3: AutoComplete
by IsaacSchlueter on Oct 29, 2009
- 5,113 views
Accessibility
Categories
Tags
Upload Details
Uploaded via SlideShare as Apple Keynote
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 7
- Downloads
- 96
- Comments
- 0
- Embed Views
- Views on SlideShare
- 5,090
- Total Views
- 5,113
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
When might not be so obvious until you sit down to create one, though, is that there are like a million different UI paradigms for these things. Also, some of them are hitting a web service, and others are just looking in a local blob of data, so we'll need a way to abstract that stuff all out.
Between these three modules, about 7 trillion people view these pages every 4 seconds, so it has to work reliably, it has to load fast, it has to put almost no extra code on the page.
remember those examples I showed before?
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
So, if you look closely, you'll notice that sometimes it's a list of selections, and sometimes it's a list of other sorts of things, like a picture and a title, and sometimes, like in the search assist case, it's something completely ridiculous. This little widget has to accommodate all of those.
The other advantage is that, by doing it this way, the little bit of code that we do end up having to write can be submitted back to the library.
But just in case, I’ll go over some of the pieces that are relevant in this case.
And, if you’re in the unlucky majority that gets to support MSIE...
Creating a plugin is easy. You expose one function that gets called when it’s plugged into something, and another that’s called when it gets unplugged (in case you have to do any cleanup)
So, as you can see, it's very extremely straightforward, with no problems whatsoever. When the plugin gets plugged into a node, it attaches to the keydown event, and when the user presses a key, we know that something has been entered, so
Also, if you’ve ever tried to do much of anything on keydown or keypress, you quickly find that it’s easy to bog down the UI and users get annoyed because they type and this thing freezes up as they’re doing it.
What about onchange?
Thankfully, YUI gives us a facility for filling in the missing holes in the DOM.
Thankfully, YUI gives us a facility for filling in the missing holes in the DOM.
Thankfully, YUI gives us a facility for filling in the missing holes in the DOM.
Thankfully, YUI gives us a facility for filling in the missing holes in the DOM.
Thankfully, YUI gives us a facility for filling in the missing holes in the DOM.
Here we see a click handler being attached to a YUI Node object. Notice the stopPropagation and preventDefault that you know and love from the DOM.
But while it’s good to be able to use AC however you want, it’s also a bit of a pain to have to do all this for just the simple/common use cases.
Set some defaults, package it up nice, and then when I just want the basic/common autocomplete, I can instantiate it without all the hassle. That means that you don’t need to know how autocomplete works in order to have it work for you.