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
