Re: 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