Thursday, October 26th, 2006
Script.aculo.us Select Box
Category: Component, Prototype
JAVASCRIPT:
-
-
new Ajax.SelectBox(id_of_text_field, id_of_div_to_populate, url, id_of_result_value, options);
-
I would stay away from gratuitous use myself, but there are some usecases where it could come in handy.
Related Content:
3.1 rating from 118 votes
It’s pretty, but the response is too slow. This cannot be used in business applications.
Nice
But it does not seems to work on Safari :(
As a dev Safari, not IE, is the browser that always manages to break my code. I own an imac to test with and think its important to have safari support. That said… everything that’s released now-a-days is in beta. I am sure within a day or so Safari will get supported by this. 8P
It needs to cache its ajax results instead of querying the server for each click…. it = tooo slow
Slow. unresponsive, useless. The list appears one second after I click…
Do we really have to recreate the select box to make it Ajaxified? Why break user standards just for dynamic select boxes. OR, if you want to change the select box, really change it. I’ve used a similar technique to make a color swatch chooser, but I didn’t make it look like a select box that really wasn’t a select box.
Nice concept, has uses I agree, but becareful. (but really, who hasn’t gone thru the phase of wanting re-create the wheel by making their own select box)
looks cool …but very very slow. That latency between the click on the display is killer to usability.
Ok, that is slow is one thing we know, but this is a matter of hosting it on the right server. Ajax depends on the server, so that is the only reason it is slow. Other then that; it doesn’t replace a selectbox at all. It just “generates code” that looks like a selectbox, to bad, nice try though.. 3 out of 5 rating.
The most common problem with recreating system-level widgets (despite the effort, which I respect!), is that I have yet to see an implementation that faithfully reproduces all of the standard UI behaviours provided by the native OS-level widgets. Select boxes are one of the most difficult.
For example, if you click the “down arrow” and the list drops down, you should be able to click the down arrow again to reset it. ESC should have the same effect, and once focused/highlighted, you should be able to use the arrow keys to scroll through the items in the list.
While the example shown here looks nice, one of the challenges is taking care to recreate all of those standard behaviours. Users are used to many of them because that’s the way the OS works, so it helps to consider them when building custom widgets.
this widget is made with the use of the auto-completer so its not really a selectbox widget its an autocomplete formfield with a drop down button…… this is just something fast and small and very nice idea…
by fast i mean small….
Ryan Lowe,
Your color picker is nice but very laggy in FireFox. Nice and smooth in IE though.
I can’t wait until someone creates a div-based textbox, because that would rawk. Oh, wait, textboxes already exist.
Really, for all the above mentioned reasons, don’t ever use this, or any other version of this tool. Its like those cheesy sites that tried to recreate the checkbox using images. The browser is way better at implementing standard behaviour than you are, no matter who you are. Spend your time creating something useful.
Manso el pachi, si señor!
Yes, Agree, performance is way too slow. IE7 makes it even worser..Need to optimize to perform better
soooooooooo slow
Wow! That damn widget is slow! Like VIC=20 slow. Scriptaslowicious slow.
Hi Dion – have to agree with most of the comments so far – why re-invent the select box. You mention that there are some usecases where this might come in handy – would you mind sharing your thoughts on where?
the obvious place is wherever a selectbox (full windowed control in IE6) might be covered or partially covered by a positioned html element (drop down menu is one I see all the time), it will be visible, whatever the z-index, precisely because it is a full windowed control. I always use a custom dhtml ‘selectbox’ to avoid this. I agree with the comment above, if you’re going to build a custom ‘selectbox’ it should behave like a selectbox.
It’s too slow = useless for anything in a business setting. sorry.
Doesn’t play very nicely with IE6
This could really be pretty cool (a la the skinning) if they could speed it up a bit.
muy buena aplicacion pachi! :)
Uh, I must have missed the memo… are we recreating the browser inside the browser now?
Also, gleefully ignores the tab key…skips right over it. Users see something that looks like a pulldown, they expect it to act like one.
For quite some time (even before prototype age) :
http://momche.net/publish/article.php?page=acdropdown
too bad it doesn’t work in Safari
Interesting. But how about misspelled option? If I hit DELETE, my browsers jump one page back (I didn’t test the source actually, only the sample above). Same is also with an ordinary SELECT-box.
It’s quite fast for me.
Los unicos que posteamos en español somos amigos de pachi…
It is no longer slow in IE or Firefox and works in Safari, so clearly these problems have been fixed. It works great for me. It even has some unadvertised capabilities, which you can discover by looking at the very short code (just an extension of the Scriptaculous Autocompleter.Base class). It wouldn’t hurt to have some familiarity with Scriptaculous.