[PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
Daevid Vincent wrote: I need to dynamically update a select box with results from a SQL database using AJAX, but I can't find a single example of how to do this. Break it down in to stages. 1. Make the request to the server 2. Have the PHP gather the data from the database 3. Return the data to the client (I'd use JSON for this) 4. Populate the select I can fill in a DIV (as per the ten million examples out there) and that's all fine and dandy, So you can already do the first three stanges then? That just leaves stage 4. One quick google later: http://www.google.com/search?q=JavaScript+dynamically+populate+select And the first hit is: http://www.petenelson.com/aspwatch/ASPWatch%20%20Using%20Javascript%20to%20Dynamically%20Populate%20Select%20Lists.htm Which tells you how to do it (ignore the ASP mention, the article is all JavaScript). -- David Dorward http://blog.dorward.me.uk/ http://dorward.me.uk/ Home is where the ~/.bashrc is -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
Daevid Vincent wrote: I need to dynamically update a select box with results from a SQL database using AJAX, but I can't find a single example of how to do this. Basically I have a text input field, and a select box. As someone types in the input field, I want the select box to fill in the results of matches. I can fill in a DIV (as per the ten million examples out there) and that's all fine and dandy, but way too simplistic for what I need. The best way to do this is indeed to put the entire select in a div, and to replace the innerHTML of that div with the html for the select. Always do as much processing as possible on the server side, or your application will become interminably slow both to load and to run. In my testing, I've found that the latency over high speed internet of passing the entire select is exactly the same as it is from my local machine. When I used to pass an array of data and repopulate using javascript DOM, it was slow as molasses, and I would occasionally have weird timeouts. Don't try to be smart when you can be simple :) Greg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
Greg Beaver wrote: Daevid Vincent wrote: I need to dynamically update a select box with results from a SQL database using AJAX, but I can't find a single example of how to do this. Basically I have a text input field, and a select box. As someone types in the input field, I want the select box to fill in the results of matches. I can fill in a DIV (as per the ten million examples out there) and that's all fine and dandy, but way too simplistic for what I need. The best way to do this is indeed to put the entire select in a div, and to replace the innerHTML of that div with the html for the select. But that is not DOM. Another way to do this is: - run your XMLHttpRequest - have your server-side AJAX target script spit a newline-separated text file, with IDs and names such as: 1 XYZ 2 JWV 3 Something - once the response is on the client, break the text file down with string manipulation functions/methods (split() comes to mind), perform a document.getElementByID(yourselect) and append document.createElement(option)'s to it, obviously setting the value properties on each element, and appending a document.createTextNode(your option text) into every option you create. Always do as much processing as possible on the server side, or your application will become interminably slow both to load and to run. In my testing, I've found that the latency over high speed internet of passing the entire select is exactly the same as it is from my local machine. When I used to pass an array of data and repopulate using javascript DOM, it was slow as molasses, and I would occasionally have weird timeouts. It shouldn't have been slow. DOM manipulation is fast. But you need to remember to instantiate new objects, add children objects first (in the example, the text nodes and options), and add the parent objects to your document then. Otherwise, I can see how your application could get slow. Don't try to be smart when you can be simple :) I'd advise against this, and I'd also advise you to look up a JavaScript-usable serialization microformat for data coming from the server (XML is kind of unwieldy for this). Look for JSON on google. Greg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
Manuel Amador (Rudd-O) wrote:
Greg Beaver wrote:
Daevid Vincent wrote:
I need to dynamically update a select box with results from a SQL
database using AJAX, but I can't find a single example of how to do
this.
Basically I have a text input field, and a select box. As someone
types in the input field, I want the select box to fill in the
results of matches.
I can fill in a DIV (as per the ten million examples out there)
and that's all fine and dandy, but way too simplistic for what I need.
The best way to do this is indeed to put the entire select in a div, and
to replace the innerHTML of that div with the html for the select.
But that is not DOM. Another way to do this is:
It's also not Java or Fortran, but as with these argument, that is
irrelevant information - it is valid javascript, and as we all know, the
J in ajax ain't DOM, it's javascript.
- run your XMLHttpRequest
- have your server-side AJAX target script spit a newline-separated
text file, with IDs and names such as:
1 XYZ
2 JWV
3 Something
- once the response is on the client, break the text file down with
string manipulation functions/methods (split() comes to mind), perform
a document.getElementByID(yourselect) and append
document.createElement(option)'s to it, obviously setting the value
properties on each element, and appending a
document.createTextNode(your option text) into every option you create.
This is far too complicated. You don't need 50 lines of code to convert
from server-side data to HTML when the browser does it for you (and far
more efficiently) with this code:
var someCallback = {
ajaxfunc: function(res) {
document.getElementById('blah').innerHTML = res;
}
}
Always do as much processing as possible on the server side, or your
application will become interminably slow both to load and to run.
In my testing, I've found that the latency over high speed internet of
passing the entire select is exactly the same as it is from my local
machine. When I used to pass an array of data and repopulate using
javascript DOM, it was slow as molasses, and I would occasionally have
weird timeouts.
It shouldn't have been slow. DOM manipulation is fast. But you need
to remember to instantiate new objects, add children objects first (in
the example, the text nodes and options), and add the parent objects
to your document then. Otherwise, I can see how your application
could get slow.
I hate to burst your bubble, but I am an experienced developer, and do
know how to use DOM. My application used these exact techniques, and
was simply slower. The internal rendering code for a browser is just
simply far faster than javascript DOM will ever be.
Another truth is self-evident: all browsers have uniformly implemented
the setting of innerHTML for far longer than the implementation of DOM
has been uniform, and your chances of encountering a bug in a particular
browser implementation are much slimmer.
Don't try to be smart when you can be simple :)
I'd advise against this, and I'd also advise you to look up a
JavaScript-usable serialization microformat for data coming from the
server (XML is kind of unwieldy for this). Look for JSON on google.
You advise against simplicity?
First off, any good programmer will tell you that simplicity is always
the first thing to look for in an application, as complex algorithms are
almost always best implemented with simple (and clever) code, but this
is a tirade for another time. Second, what makes you think I don't
transfer the HTML using JSON?
I use http://pear.php.net/HTML_AJAX for the actual ajax details, and it
has several serialization options, JSON by default.
First off, let's examine why one would use ajax in the first place.
It's not to be correct or rigorous - it is to streamline the user
experience. Ajax of course introduces other concerns such as the danger
of overloading the server with more HTTP requests than traditional apps,
but this is easily fixed by ensuring that examples like the type in
text box and populate select have some appropriate limits on how often
it actually sends the requests for data.
If you still don't believe me, take a straw poll of the most proficient
programmers to see how they are using ajax in real-world time-critical
applications.
Greg
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
Greg Beaver wrote:
This is far too complicated. You don't need 50 lines of code to convert
from server-side data to HTML when the browser does it for you (and far
more efficiently) with this code:
var someCallback = {
ajaxfunc: function(res) {
document.getElementById('blah').innerHTML = res;
}
}
You know you're oversimplifying matters. What if the returned markup is
invalid? What if the server experienced an HTTP 500 error? Why should
anyone want to program their application to return 'tag soup' instead of
formally defining interfaces via standards? That's asking for
maintenance nightmares.
I hate to burst your bubble, but I am an experienced developer, and do
know how to use DOM. My application used these exact techniques, and
was simply slower. The internal rendering code for a browser is just
simply far faster than javascript DOM will ever be.
Another truth is self-evident: all browsers have uniformly implemented
the setting of innerHTML for far longer than the implementation of DOM
has been uniform, and your chances of encountering a bug in a particular
browser implementation are much slimmer.
I'm not talking about using DOM because it's more formal. I'm talking
about using DOM and formally defined interfaces for maintenance cost
reasons. Tag soup is harder to debug and automate/instrument for
tests. Tag soup is a nightmare. Sure, for quickies it can't be
beaten. But try to figure out what the hell you (or one of your
engineers) did six months ago without a formally specified way of
returning values...
Don't try to be smart when you can be simple :)
I'd advise against this, and I'd also advise you to look up a
JavaScript-usable serialization microformat for data coming from the
server (XML is kind of unwieldy for this). Look for JSON on google.
You advise against simplicity?
No. I'm advising against the false trap of initial simplicity.
First off, any good programmer will tell you that simplicity is always
the first thing to look for in an application, as complex algorithms are
almost always best implemented with simple (and clever) code, but this
is a tirade for another time. Second, what makes you think I don't
transfer the HTML using JSON?
If you did that, you would be gaining nothing. Whatever you use as
return value format, it should be easily parsable markup and should be
formally specified (standards of course should be preferred). HTML is
not XML and it's not as easily parsed as XML.
I use http://pear.php.net/HTML_AJAX for the actual ajax details, and it
has several serialization options, JSON by default.
First off, let's examine why one would use ajax in the first place.
It's not to be correct or rigorous - it is to streamline the user
experience. Ajax of course introduces other concerns such as the danger
of overloading the server with more HTTP requests than traditional apps,
but this is easily fixed by ensuring that examples like the type in
text box and populate select have some appropriate limits on how often
it actually sends the requests for data.
That statement I agree with.
If you still don't believe me, take a straw poll of the most proficient
programmers to see how they are using ajax in real-world time-critical
applications.
I've seen real-world AJAX applications succumb to complexity. I'm just
suggesting something to manage complexity which should be fairly obvious
now.
Greg
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
Manuel Amador (Rudd-O) wrote:
Greg Beaver wrote:
This is far too complicated. You don't need 50 lines of code to convert
from server-side data to HTML when the browser does it for you (and far
more efficiently) with this code:
var someCallback = {
ajaxfunc: function(res) {
document.getElementById('blah').innerHTML = res;
}
}
You know you're oversimplifying matters. What if the returned markup is
invalid? What if the server experienced an HTTP 500 error? Why should
anyone want to program their application to return 'tag soup' instead of
formally defining interfaces via standards? That's asking for
maintenance nightmares.
1) what if the returned markup is invalid?
Well, the browser renders it oddly, and through the fact that your
server-side code is straightforward filling in an html template with
actual values, all you need to do is view the source (with the firefox
web debugging extension you can view generated source) or to add an
alert(res) in there.
2) HTTP 500?
This should be handled internally by the ajax mechanism (HTML_AJAX does
handle this)
3) tag soup?
I hardly think a select tag qualifies as tag soup but tag soup is
of course a non-definite term anyways :).
Greg
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
1) what if the returned markup is invalid? Well, the browser renders it oddly, and through the fact that your server-side code is straightforward filling in an html template with actual values, all you need to do is view the source (with the firefox web debugging extension you can view generated source) or to add an alert(res) in there. Now, how do you automate that in a testing suite? Going beyond, how do you set up unit (or other types of) tests in a cheap, straightforward way? How do you assure quality of an application built like this? 2) HTTP 500? This should be handled internally by the ajax mechanism (HTML_AJAX does handle this) That's good. 3) tag soup? I hardly think a select tag qualifies as tag soup but tag soup is of course a non-definite term anyways :). Well, returning an JSON or XML document certainly is more structured than using a simple SELECT and several OPTION HTML tags. The point here is, precisely, decoupling implementation from interface. Sure, your solution mostly works. But what I still wonder is, is it the best solution in terms of software quality? Greg -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
[PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
Hello, on 03/17/2006 11:42 PM Daevid Vincent said the following: I need to dynamically update a select box with results from a SQL database using AJAX, but I can't find a single example of how to do this. Basically I have a text input field, and a select box. As someone types in the input field, I want the select box to fill in the results of matches. I can fill in a DIV (as per the ten million examples out there) and that's all fine and dandy, but way too simplistic for what I need. You may want to take a look at this forms generation class that comes with a plug-in that lets you do precisely what you ask. The linked select input plug-in lets you switch the group of options of a select input upon an arbitrary event, which in your case you need to be when your text input changes its value. The plug-in can work in two modes: static and dynamic. In the static mode it loads all the alternative groups of options with the form. This is not the way you want. In the dynamic mode it makes an AJAX call that performs some action and returns the alternative group of options depending on a value passed from another input to the server. In both modes it can take the alternative option groups from arrays or execute some action that retrives the new options. There specialized variants of the plug-in to take the options from database queries using different API. Currently supported API are: MySQL, or any other database supported by the database abstractions Metabase or PEAR::MDB2 . There is also another plug-in for generic AJAX form submission in case you need more special effects. Here are live examples of the static mode: http://www.phpclasses.org/mirrors.html http://www.phpclasses.org/browse/view/html/file/9879/name/test_linked_select_page.html The example scripts for the dynamic mode come with the class: You may download the class and all plug-ins, examples and documentation from here: http://www.phpclasses.org/formsgeneration -- Regards, Manuel Lemos Metastorage - Data object relational mapping layer generator http://www.metastorage.net/ PHP Classes - Free ready to use OOP components written in PHP http://www.phpclasses.org/ -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
Manuel Amador (Rudd-O) wrote:
1) what if the returned markup is invalid?
Well, the browser renders it oddly, and through the fact that your
server-side code is straightforward filling in an html template with
actual values, all you need to do is view the source (with the firefox
web debugging extension you can view generated source) or to add an
alert(res) in there.
Now, how do you automate that in a testing suite?
This is obvious: you need only test the output of the PHP server class,
which is quite simple, as none of the complexity lies in the
javascript. As long as your ajax javascript is testable for its ability
to work (and HTML_AJAX is), then you are covered. In other words, the
need to test the javascript end is simply unnecessary. All you need to
do is to test that the javascript actually properly initiates the ajax
call. In my case, it involves these lines:
var someCallback = {
doThis: function(res) {
document.getElementById('blah').innerHTML = res;
}
}
function doThisThing(fragment)
{
var c = new backendclass(someCallback);
c.doThis(fragment);
}
Obviously, this is simply not complicated enough to warrant extensive
testing of the interface between the javascript - HTML_AJAX - php code
and back. All we need to test is the HTML_AJAX component, and the PHP code.
Going beyond, how do you set up unit (or other types of) tests in a
cheap, straightforward way? How do you assure quality of an
application built like this?
In order to unit test the javascript, you would need to do the same
stuff that is done for DOM, but it would be far simpler to set up. I've
already answered the PHP end.
3) tag soup?
I hardly think a select tag qualifies as tag soup but tag soup is
of course a non-definite term anyways :).
Well, returning an JSON or XML document certainly is more structured
than using a simple SELECT and several OPTION HTML tags. The point
here is, precisely, decoupling implementation from interface.
What I think is *still* unclear is that the difference between what you
are suggesting and what is actually working on my website is this:
Your solution:
1) PHP code generates the data from the fragment
2) PHP code converts the data into a text file
3) PHP code serializes it to JSON
4) javascript code unserializes the JSON
5) javascript code parses the text file to grab option/value combinations
6) javascript code creates each option node, and adds the value/text
7) javascript code creates the select node, adds each option
8) javascript code adds the select to the document
My solution:
1) PHP code generates the data from the fragment
2) PHP code converts the data into a string containing the
selectoption tags
3) PHP code serializes it to JSON
4) javascript code unserializes the JSON
5) javascript code sets the innerHTML to the new select
In your solution, you need to test steps 1, 2, 5, 6 and 7. In addition,
steps 2, 5, 6, and 7 all require testing in javascript (and time) to
guarantee that you get the result (8).
In my solution, you need to test step 1 and 2 to ensure that bounds are
satisfied and that a proper select tag is always generated, and this
only needs to be done in PHP. Both cases assume you don't need to test
the ajax mechanism itself.
In short, it's just not worth the trouble to triple the number of
necessary tests when the result is identical, and it is actually
*easier* to see what HTML you're going to end up with from the PHP code.
Sure, your solution mostly works. But what I still wonder is, is it
the best solution in terms of software quality?
I think I've made my opinion sufficiently clear on this point.
Greg
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
Greg Beaver wrote:
This is obvious: you need only test the output of the PHP server class,
All the more reasons to use a serialization markup language instead of
just plain HTML. Testing for specific HTML output may break if the HTML
output changes, but not if you're using XML or JSON, because:
1. you are forced to think carefully before changing the output
2. programming techniques such as DOM instead of matching for text are a
reality
which is quite simple, as none of the complexity lies in the
javascript. As long as your ajax javascript is testable for its ability
to work (and HTML_AJAX is), then you are covered. In other words, the
need to test the javascript end is simply unnecessary.
That's so untrue, unit testing frameworks for JavaScript exist.
All you need to
do is to test that the javascript actually properly initiates the ajax
call. In my case, it involves these lines:
var someCallback = {
doThis: function(res) {
document.getElementById('blah').innerHTML = res;
}
}
function doThisThing(fragment)
{
var c = new backendclass(someCallback);
c.doThis(fragment);
}
Going beyond, how do you set up unit (or other types of) tests in a
cheap, straightforward way? How do you assure quality of an
application built like this?
In order to unit test the javascript, you would need to do the same
stuff that is done for DOM, but it would be far simpler to set up. I've
already answered the PHP end.
What I think is *still* unclear is that the difference between what you
are suggesting and what is actually working on my website is this:
Your solution:
1) PHP code generates the data from the fragment
2) PHP code converts the data into a text file
3) PHP code serializes it to JSON
4) javascript code unserializes the JSON
5) javascript code parses the text file to grab option/value combinations
6) javascript code creates each option node, and adds the value/text
7) javascript code creates the select node, adds each option
8) javascript code adds the select to the document
It's evident, from your statements, that you've misunderstood me:
1) You output XML or JSON directly from your PHP script. Whether it's
via print statements or an elaborated class like the DOM XML functions
in PHP, that's your problem.
2) You receive the data and use one of the builtin JavaScript functions
to parse it (if you're transferring a valid XML document, that's a piece
of cake. Generating a valid XML document is also piece of cake, using
DOM-XML in php)
3) You write client-side application code that processes the nodes from
the parsed output and does whatever it has to do to your current
document's DOM tree. See, it's much more generic. You could use the
same output from the server to generate a table, or a SELECT node.
Besides, if you want to avoid writing code, libraries for doing this are
a dime a dozen. Plus if you reuse code you usually end up with a
well-tested choice.
My solution:
1) PHP code generates the data from the fragment
2) PHP code converts the data into a string containing the
selectoption tags
3) PHP code serializes it to JSON
4) javascript code unserializes the JSON
5) javascript code sets the innerHTML to the new select
Like I said, that's a very specific, non-generalizable, brittle
solution. It might work. Then again, it might not. Handling broken
connections and other kinds of impromptu errors is much harder than with
XML or JSON. At least with XML, you can attest to the validity of the
markup before embarking on an innerHTML binge.
In your solution, you need to test steps 1, 2, 5, 6 and 7. In addition,
steps 2, 5, 6, and 7 all require testing in javascript (and time) to
guarantee that you get the result (8).
In my solution, you need to test step 1 and 2 to ensure that bounds are
satisfied and that a proper select tag is always generated, and this
only needs to be done in PHP. Both cases assume you don't need to test
the ajax mechanism itself.
In short, it's just not worth the trouble to triple the number of
necessary tests when the result is identical, and it is actually
*easier* to see what HTML you're going to end up with from the PHP code.
Just for argument's sake: the result is not identical. Assume, for one
second, that you have two PHP functions:
function getCitiesAsHTML($countryName);
function getCitiesAsXML($countryName);
The first issues a snippet of HTML text, with options. The second
issues a serialized XML document.
The first one is engineered to be used with innerHTML. The second one
is engineered to be processed by the client so it can do any generic
transformation.
Which one do you think has the greatest potential for reusability in
your JS client code? Option 1 or Option 2?
Okay, this is the end of the discussion for me. You're stating a bunch
of crap which does not correlate with modern accepted software quality
practices. You're conveniently
Re: [PHP] Re: PHP, SQL, AJAX, JS and populating a SelectBox?
Manuel Amador (Rudd-O) wrote:
Just for argument's sake: the result is not identical. Assume, for
one second, that you have two PHP functions:
function getCitiesAsHTML($countryName);
function getCitiesAsXML($countryName);
The first issues a snippet of HTML text, with options. The second
issues a serialized XML document.
The first one is engineered to be used with innerHTML. The second one
is engineered to be processed by the client so it can do any generic
transformation.
Which one do you think has the greatest potential for reusability in
your JS client code? Option 1 or Option 2?
Okay, this is the end of the discussion for me. You're stating a
bunch of crap which does not correlate with modern accepted software
quality practices. You're conveniently ignoring that server-side
errors and TCP connection errors are out there, and while they may be
only 2% of all traffic, you need your JS application to work 100% of
the time or give reasonable feedback as to why it cannot work. You're
grossly oversimplifying matters to prove your point, which flies right
in the face of orderly, neat, structured, standards-based software
development.
Manuel,
Your insults are not exactly convincing arguments for your case :). If
you had even taken 1 second to investigate http://pear.php.net/HTML_AJAX
you would know that your arguments about TCP and server-side errors are
irrelevant. Why? I'll tell you why!
In fact, to make things easier, I will quote myself from previous
messages. Consider this current email to be Message #4. From Message #2:
2) HTTP 500?
This should be handled internally by the ajax mechanism (HTML_AJAX does
handle this)
To rephrase what I said above, HTML_AJAX handles server-side and TCP
connection errors. I neglected to say exactly how it does so in the
message, perhaps that is the confusion. Upon a timeout or other error,
a javascript alert() is used. Upon a server-side error (a PHP error in
the server-side script), by default a javascript alert() is raised with
the contents of the PHP error complete with backtrace - very handy for
debugging.
So, that kills straw man argument number one, which I will quote again
for clarity: You're conveniently ignoring that server-side errors and
TCP connection errors are out there, and while they may be only 2% of
all traffic...
As we can see, this statement is untrue. So, moving on:
HTML_AJAX is designed such that you register classes that simply return
regular old PHP values, and it then serializes them into JSON or any of
a number of choices (as I have said, let me quote myself from Message #1:
I use http://pear.php.net/HTML_AJAX for the actual ajax details, and it
has several serialization options, JSON by default.)
The fact is, your example php functions miss the point by returning HTML
vs. XML. The return value of my functions are *strings* which are then
serialized into JSON by HTML_AJAX. If you need to do client-side
transformation, that's not a problem, as contrary to a previous post,
HTML inserted via assignment to innerHTML *is* accessible via DOM,
otherwise getElementById() wouldn't work on the select. To prove
this, you can look in Firefox's DOM inspector. After loading HTML
inserted via innerHTML, at first it will not show any changes, but by
closing the DOM inspector and re-opening it, it will refresh with the
current page value, and all of the new innerHTMLed HTML will show up.
Also, let's remember back to the original question from Daevid Vincent,
which was (and I quote):
I need to dynamically update a select box with results from a SQL
database using AJAX, but I can't find a single example of how to do this.
A select box is not a need to do client-side manipulation. It is a
select box. Should you need to re-format the data in another format,
there are several options which all boil down to one of:
1) re-factor so that you don't need to re-format on the client side (my
personal favorite)
2) return another format such as an array and manipulate the data on the
client-side
However, it is not useful to talk about some generic time down the road
- what is important is to design your application so that it is easy to
change it. If you have a whole bunch of complicated client-side logic,
this makes it more difficult to re-factor. After all, only one of two
things are certain in programming:
You *will* have to refactor that code in the future, or you will quit.
Whichever comes first.
So, straw man argument #2: You're grossly oversimplifying matters to
prove your point, which flies right in the face of orderly, neat,
structured, standards-based software development.
is simply insulting :). I was posting *actual* javascript code from a
well-working application with only the function names changed. Want the
original code as written? Here you go:
var addressesCallback = {
searchAddressesGetHTMLOptions: function(res) {
