Dynamic combo box refreshed when clicked?
Wenguang Wang
My web page has a dynamic combo box which contains some dynamic
information queried from the database. Currently I am using php to
generate such a page with the dynamic information.
However, I want it to be more dynamic: when I click the combo box,
before the combo box shows me all options, it should query the
database and get the latest results. Otherwise, the user has to
manually click the refresh button.
Is there a way to achieve such thing using combo box? If not, what
control and what technique should I use?
Thanks!
-Wenguang
Alan Gutierrez
The select element has a DOM interface that allows you to add and remove
options. I assume you mean "SELECT" since there is no real combo box in
available in the DOM.
https://developer.mozilla.org/en/DOM/select
To get the information, your going to need to fetch it using XMLHttpRequest.
http://www.w3.org/TR/XMLHttpRequest/
Then you'd return JSON from your PHP script and evaluate the response.
This would be the way to do it with raw JavaScript. A library like
Prototype or jQuery could also be very helpful, but people on this
newsgroup do not like them because they leak memory on older browsers.
--
Alan Gutierrez - al...@blogometer.com - http://twitter.com/bigeasy
David Mark
> Wenguang Wang wrote:
> > Hi,
>
> > My web page has a dynamic combo box which contains some dynamic
> > information queried from the database. Currently I am using php to
> > generate such a page with the dynamic information.
>
> > However, I want it to be more dynamic: when I click the combo box,
> > before the combo box shows me all options, it should query the
> > database and get the latest results. Otherwise, the user has to
> > manually click the refresh button.
>
> > Is there a way to achieve such thing using combo box? If not, what
> > control and what technique should I use?
>
> The select element has a DOM interface that allows you to add and remove
> options. I assume you mean "SELECT" since there is no real combo box in
> available in the DOM.
>
> https://developer.mozilla.org/en/DOM/select
>
> To get the information, your going to need to fetch it using XMLHttpRequest.
Not necessarily. He could also do script injection (for example).
>
> http://www.w3.org/TR/XMLHttpRequest/
>
> Then you'd return JSON from your PHP script and evaluate the response.
Also not necessarily. The X in XHR stands for XML after all. ;)
>
> This would be the way to do it with raw JavaScript.
JavaScript is a trademarked brand name that refers to just one
ECMAScript implementations. It would be better to refer to it as
"Javascript", "javascript" or simply "JS". And no, I don't mean for
legal reasons.
> A library like
> Prototype or jQuery could also be very helpful, but people on this
> newsgroup do not like them because they leak memory on older browsers.
>
Is that what you got out of the link I cited in that other thread?
You need to revisit that one too. Seriously.
JFTR, memory leaks are the least of the worries with using either of
those two libraries. And it is not that people "on this newsgroup" do
not like libraries (though many do not like those two for obvious
reasons).
One problem arises when posted code veers off into a (sometimes
unnamed) library, which makes spotting the problems that much more
difficult (if not impossible) And often users of these libraries
cannot post a simplified test case as they don't know how to write the
equivalent without the library.
And yes, many such users storm off in frustration claiming anti-
library bias. :)
Alan Gutierrez
> Wenguang Wang wrote:
>> Hi,
>>
>> My web page has a dynamic combo box which contains some dynamic
>> information queried from the database. Currently I am using php to
>> generate such a page with the dynamic information.
>>
>> However, I want it to be more dynamic: when I click the combo box,
>> before the combo box shows me all options, it should query the
>> database and get the latest results. Otherwise, the user has to
>> manually click the refresh button.
>>
>> Is there a way to achieve such thing using combo box? If not, what
>> control and what technique should I use?
>
> The select element has a DOM interface that allows you to add and remove
> options. I assume you mean "SELECT" since there is no real combo box in
> available in the DOM.
>
> https://developer.mozilla.org/en/DOM/select
This will get you started...
<html>
<head>
<script type="text/javascript">
function setSelect() {
var select = document.getElementById('menu');
populate(select, [ 'a', 'b', 'c' ]);
}
function populate(select, items) {
select.options.length = 0;
for (var i = 0; i < items.length; i++) {
select.options[select.options.length] = new Option(items[i]);
}
}
</script>
</head>
<body onload="setSelect()">
<select id="menu"></select>
</body>
</html>
Gregor Kofler
> http://www.w3.org/TR/XMLHttpRequest/
>
> Then you'd return JSON from your PHP script and evaluate the response.
>
> This would be the way to do it with raw JavaScript. A library like
> Prototype or jQuery could also be very helpful, but people on this
> newsgroup do not like them because they leak memory on older browsers.
This could be *a* reason. For the above problem, say 50 lines of "raw"
JS would suffice (the cross-browser issues of XHR are a mild problem at
best). In addition one would know what his or her XHR JS routines are
doing. Any of the mentioned and not-mentioned libraries heap a bunch of
abstraction layers on that along with plenty of unnecessary code.
I suppose you already knew that, and just wanted to throw in some
trolling comment, to fire up David again.
Besides: This memory leaking can be a *real* showstopper. I got involved
with a huge project doing some sort of traffic monitoring, polling data
via XHR. The customers were *all* on IE and the application was running
24/7. Or rather /should/ run 24/7, since it frequently crashed IE and
Win after 10 to 12 hours. The page was ridden with libraries - I can
recall jQuery and Spry.
Gregor
Alan Gutierrez
> Am 2010-07-24 06:47, Alan Gutierrez meinte:
>
>> http://www.w3.org/TR/XMLHttpRequest/
>>
>> Then you'd return JSON from your PHP script and evaluate the response.
>>
>> This would be the way to do it with raw JavaScript. A library like
>> Prototype or jQuery could also be very helpful, but people on this
>> newsgroup do not like them because they leak memory on older browsers.
>
> This could be *a* reason. For the above problem, say 50 lines of "raw"
> JS would suffice (the cross-browser issues of XHR are a mild problem at
> best). In addition one would know what his or her XHR JS routines are
> doing. Any of the mentioned and not-mentioned libraries heap a bunch of
> abstraction layers on that along with plenty of unnecessary code.
>
> I suppose you already knew that, and just wanted to throw in some
> trolling comment, to fire up David again.
The position taken on libraries is not self-evident. Any production
language has a lot of code that is unnecessary code that I don't use. I
can build a web application in Java, and the JDK I use includes AWT and
Swing. This is not going to lead me to create my own bundle.
While there is a cost for the library to download, there are going to be
a lot of cases where I'm find with the cost of bandwidth because my time
is more important.
And then there is the prevalence of the libraries, the demand for people
who know them, and successful applications built with them.
> Besides: This memory leaking can be a *real* showstopper. I got involved
> with a huge project doing some sort of traffic monitoring, polling data
> via XHR. The customers were *all* on IE and the application was running
> 24/7. Or rather /should/ run 24/7, since it frequently crashed IE and
> Win after 10 to 12 hours. The page was ridden with libraries - I can
> recall jQuery and Spry.
Sounds awful, but this comes down to a platform choice, or lack of
platform choice. Another strategy would be to dictate the browser and
choose one that doesn't leak and treat JavaScript as a if it were a
garbage collected language, which it is. (Yes, you can still leak memory
in a garbage collected language.)
Gregor Kofler
>> Besides: This memory leaking can be a *real* showstopper.
> Sounds awful, but this comes down to a platform choice, or lack of
> platform choice. Another strategy would be to dictate the browser [snip]
It rather boils down to "bad quality of libraries" (at least in some
important departments), and lack of understanding of JS and browser
internals of both the library authors and the people who put together
the web application. The latter ones are hard to blame, when they are
frequently advised to use "a library to make things easier".
Gregor
David Mark
> Gregor Kofler wrote:
> > Am 2010-07-24 06:47, Alan Gutierrez meinte:
>
> >>http://www.w3.org/TR/XMLHttpRequest/
>
> >> Then you'd return JSON from your PHP script and evaluate the response.
>
> >> This would be the way to do it with raw JavaScript. A library like
> >> Prototype or jQuery could also be very helpful, but people on this
> >> newsgroup do not like them because they leak memory on older browsers.
>
> > This could be *a* reason. For the above problem, say 50 lines of "raw"
> > JS would suffice (the cross-browser issues of XHR are a mild problem at
> > best). In addition one would know what his or her XHR JS routines are
> > doing. Any of the mentioned and not-mentioned libraries heap a bunch of
> > abstraction layers on that along with plenty of unnecessary code.
>
> > I suppose you already knew that, and just wanted to throw in some
> > trolling comment, to fire up David again.
>
> The position taken on libraries is not self-evident.
Then you didn't read that recent post I sent you to (at least not
carefully). The point was not that jQuery leaked memory (though that
is certainly not a good thing).
> Any production
> language has a lot of code that is unnecessary code that I don't use.
We aren't talking about a language but silly little scripts that have
been demonstrated to be of grade Z quality (e.g. jQuery and
Prototype).
> I
> can build a web application in Java, and the JDK I use includes AWT and
> Swing. This is not going to lead me to create my own bundle.
You notice nobody uses Java on the client side anymore. For one it
was too bloated.
>
> While there is a cost for the library to download, there are going to be
> a lot of cases where I'm find with the cost of bandwidth because my time
> is more important.
That assumes it takes less time to write an app with a dubious third-
party library written by people who demonstrably lack experience and
proficiency in browser scripting. Doesn't really follow does it? But
that's been their sales pitch.
>
> And then there is the prevalence of the libraries, the demand for people
> who know them, and successful applications built with them.
What does the demand for "people who know them" have to do with the
quality of an application (or lack thereof). Or are you more
concerned with your future employment possibilities than your clients?
In any event, there is far more demand for those can write HTML/CSS/JS
in competent fashion than those who pretend to.
And success is *relative*. Show me any "successful" site written by
jQuery cargo cultists and I will show you a site that could have been
so much better. ;)
>
> > Besides: This memory leaking can be a *real* showstopper. I got involved
> > with a huge project doing some sort of traffic monitoring, polling data
> > via XHR. The customers were *all* on IE and the application was running
> > 24/7. Or rather /should/ run 24/7, since it frequently crashed IE and
> > Win after 10 to 12 hours. The page was ridden with libraries - I can
> > recall jQuery and Spry.
>
> Sounds awful, but this comes down to a platform choice, or lack of
> platform choice.
A platform choice? It's just another example of a site gone wrong due
to using jQuery (and the like) as crutches.
> Another strategy would be to dictate the browser and
> choose one that doesn't leak and treat JavaScript as a if it were a
> garbage collected language, which it is.
I see. So rather than doing a competent job for your client, you
would seek to limit end-users to a browser that exposes less holes in
your application. Regardless, you can't do that on the Web. Some
users can't/won't change their browsers to suit your site.
Wenguang Wang
JSON output generated by php, and got it working. Thank you very
much!
One thing is that I don't know what event of the select box I should
use to trigger the ajax event. When I use the OnFocus event, it is
acting funny that sometimes it does not refresh the list. So now I am
using OnMouseOver. May not be very efficient, but it works. I hope I
could get an event right before the drop down box is shown so I can
fill the list in that event. Is this possible?
Thanks!
-Wenguang
> Alan Gutierrez - a...@blogometer.com -http://twitter.com/bigeasy
David Mark
> Very helpful! I used AJAX to send the query, and parsed the received
> JSON output generated by php, and got it working. Thank you very
> much!
>
> One thing is that I don't know what event of the select box I should
> use to trigger the ajax event. When I use the OnFocus event, it is
> acting funny that sometimes it does not refresh the list.
Nothing funny about that. You do realize that an XHR call may take a
while to finish, right? It's not as if you can block the SELECT from
doing its thing in the meantime. Well, you could block a click, but
you'd have no (standard) way to force the SELECT to show its wares
after rebuilding the list.
> So now I am
> using OnMouseOver. May not be very efficient, but it works.
No it doesn't; though perhaps it seems to in your limited testing.
Besides, think of keyboard users.
> I hope I
> could get an event right before the drop down box is shown so I can
> fill the list in that event. Is this possible?
>
Nope. Re-think your design.
Alan Gutierrez
> On Jul 23, 9:47 pm, Alan Gutierrez <a...@blogometer.com> wrote:
>> Wenguang Wang wrote:
>>> Hi,
>>> My web page has a dynamic combo box which contains some dynamic
>>> information queried from the database. Currently I am using php to
>>> generate such a page with the dynamic information.
>>> However, I want it to be more dynamic: when I click the combo box,
>>> before the combo box shows me all options, it should query the
>>> database and get the latest results. Otherwise, the user has to
>>> manually click the refresh button.
>>> Is there a way to achieve such thing using combo box? If not, what
>>> control and what technique should I use?
>> The select element has a DOM interface that allows you to add and remove
>> options. I assume you mean "SELECT" since there is no real combo box in
>> available in the DOM.
>>
>> https://developer.mozilla.org/en/DOM/select
>>
>> To get the information, your going to need to fetch it using XMLHttpRequest.
>>
>> http://www.w3.org/TR/XMLHttpRequest/
>>
>> Then you'd return JSON from your PHP script and evaluate the response.
>>
>> This would be the way to do it with raw JavaScript. A library like
>> Prototype or jQuery could also be very helpful, but people on this
>> newsgroup do not like them because they leak memory on older browsers.
> Very helpful! I used AJAX to send the query, and parsed the received
> JSON output generated by php, and got it working. Thank you very
> much!
>
> One thing is that I don't know what event of the select box I should
> use to trigger the ajax event. When I use the OnFocus event, it is
> acting funny that sometimes it does not refresh the list. So now I am
> using OnMouseOver. May not be very efficient, but it works. I hope I
> could get an event right before the drop down box is shown so I can
> fill the list in that event. Is this possible?
Please don't top post. A little nit. It is easier to keep the dialog
going from top to bottom.
You're now talking about auto-complete, which means you'll want to use
something besides the standard drop-down "SELECT" control. You really do
want a combo box.
Have a look at jQuery UI auto-complete.
http://jqueryui.com/demos/autocomplete/
There are other implementations of auto-complete, too. I've used this
one before to good effect.
The concept is that it will drop down a div beneath a text field with
options. You can populate this drop-down using AJAX and it will update
as the user types in characters.
David Mark
Well, there's no such thing. What he wants is a read-only text input,
a button and a list (a faux SELECT basically).
>
> Have a look at jQuery UI auto-complete.
>
[...]
Don't bother. Not only is it the wrong widget, but it requires
including a dubious 70K of jQuery to boot.
>
> There are other implementations of auto-complete, too.
Loads (most of them awful). But the OP is not after an auto-complete
widget.
> I've used this
> one before to good effect.
As you see it. Of course, it is piled on top of the shambles that is
jQuery, so...
>
> The concept is that it will drop down a div beneath a text field with
> options.
Options? That's an unfortunately confusing term in this context. You
drop down a list (perhaps wrapped in a DIV).
> You can populate this drop-down using AJAX and it will update
> as the user types in characters.
>
You populate the list with list items, much in the same way that you
populated the SELECT in the previous (aborted) example. Instead of
creating OPTION elements, you create LI's. You use
document.createElement to create them and the appendChild method of
the list to append them. When the list (or DIV) is first created, it
is styled to be invisible and absent from the layout (display:none).
When the user clicks the button, you set the display style of the list
to an empty string (""), which adds it to the layout and makes it
visible (the default display style will apply).
As for positioning, the textbox and button should be placed in a
relatively positioned DIV (position:relative) and the list (or
containing DIV) should be absolutely positioned with left/top styles
that put it just below the textbox and aligned to its left edge. If
elTextbox references the text input and elDiv references a DIV
containing the list:-
elDiv.style.left = elTextbox.offsetLeft + 'px';
elDiv.style.top = (elTextbox.offsetTop + elTextbox.offsetHeight) +
'px';
...then display it like this:-
elDiv.style.display = '';
It should be clear what to do when the user clicks the outer container
while the list is displayed. The target will either be a list item,
the text node contained in a list item or something else. If the
target node type is a text node (nodeType property), reference its
parent (parentNode property).
The first two cases set the value property of the text input to the
text contained by the list item (see innerText and textContent).
Regardless of the target, all clicks set the display style of the list
(or containing DIV) back to 'none'. One caveat to this, which is a
matter of taste, is that clicking the button while the list is
displayed may be treated as if it didn't happen (the list remains
displayed). Another is that you may want to attach the click handler
to the BODY element (or HTML element is the body has margins) so that
the list goes away on clicking anywhere in the document.
As for cross-browser compatibility; it should hopefully go without
saying in this case, but don't put a border on the outer container as
some browser's offsetLeft/Top properties include the border width
(which is obviously unwanted here). In fact, explicitly set the
border style to 'none' (or set the border-width to '0') in the
*script* (the inline style will be less likely to be stepped on by
user style sheets or future developers twiddling with the
presentation).
For the purposes of progressive enhancement, you should start with a
standard SELECT and then replace it with a newly created DIV as
prescribed above (but only after appropriate feature detection, of
course). That way the input will work when scripting is disabled and
for browsers/configurations that do not support the required features.
Once you get the basic concept working, save the script and style
sheet for future use. Repeat for other types of widgets as needed and
eventually you will have a nice "toolkit". If something goes wrong
with one of them, you'll know exactly where to look. And if you can't
figure it out, you can post the dependency-free "plain old Javascript"
to a forum such as this one and have some hope of getting a timely
answer.
That's about it and it's not nearly as complicated as it might sound.
An experienced developer should be able to put together a working and
aesthetically pleasing rendition, including the XHR bit, in an hour
(at most). That's why most experienced developers demand relatively
exorbitant rates. ;)
Of course, the average jQuery user will take that long to download the
UI library and wade through the documentation for an inappropriate
widget. Then they will display an unnecessarily complex "creation"
that is not their own and therefore bound to the whims of the jQuery/
jQueryUI developers (who necessarily do not have any concept of the
specific project's context).
And take my word for it, they are a very whimsical bunch. All it
takes is one "wouldn't it be cool if..." suggestion that they think
can be easily implemented and it's off to the races adding more
complexity that may never be needed by the project at hand and that
may well cause problems on the next download (I've seen it happen a
thousand times over the years).
You will likely write more at the outset, but ultimately you will save
time by avoiding endless jQuery/jQueryUI "upgrades" and
incompatibilities, bugs introduced by new features that you don't
need, less-than-helpful support forums, etc. Don't let any "pro
library" zealot tell you different. They are just jealous that you
don't use a library (and thus likely command higher rates). :)
Wenguang Wang
the onMouseOver hack will work well for now.
The solution you described does look very complicated to me
(especially I couldn't find an example), because I am a very novice
developer of web apps.
-Wenguang
David Mark
> Thanks for your very detailed answer. My users always use mouse, so
> the onMouseOver hack will work well for now.
But it has the same problem as the focus "solution", just less
pronounced (depending on circumstances).
>
> The solution you described does look very complicated to me
> (especially I couldn't find an example), because I am a very novice
> developer of web apps.
It's not nearly as complicated as it sounds. You've already for the
XHR bit and successfully stocked a SELECT with options. Stocking,
positioning and displaying a list is not a huge leap from there.
I'm sorry I didn't have time to write the whole thing for you, but
that wouldn't have helped you learn anyway.
And please stop top-posting here. It destroys the flow and context of
the conversation (which I don't have time to put back).
David Mark
> On Jul 25, 10:39 am, Wenguang Wang <wenguang.w...@gmail.com> wrote:
>
> > Thanks for your very detailed answer. My users always use mouse, so
> > the onMouseOver hack will work well for now.
>
> But it has the same problem as the focus "solution", just less
> pronounced (depending on circumstances).
>
>
>
> > The solution you described does look very complicated to me
> > (especially I couldn't find an example), because I am a very novice
> > developer of web apps.
>
> It's not nearly as complicated as it sounds. You've already for the
> XHR bit and successfully stocked a SELECT with options. Stocking,
> positioning and displaying a list is not a huge leap from there.
>
> I'm sorry I didn't have time to write the whole thing for you, but
> that wouldn't have helped you learn anyway.
>
Also, the OP should remember what I said about re-thinking the
design. There's no reason that a standard SELECT can't be used for
this. It's just that the refresh of its options cannot be triggered
by user interaction with the control. Perhaps this control is part of
a tabbed interface and can be refreshed on displaying its containing
tab. Or maybe a time-based trigger would be appropriate. As always,
it depends on the context and designs should eliminate impossibilities
and consider what is left.
Thomas 'PointedEars' Lahn
> I assume you mean "SELECT" since there is no real combo box in
> available in the DOM.
You mean not in _(X)HTML_. Please learn the difference before you give
further advice.
PointedEars
--
var bugRiddenCrashPronePieceOfJunk = (
navigator.userAgent.indexOf('MSIE 5') != -1
&& navigator.userAgent.indexOf('Mac') != -1
) // Plone, register_function.js:16