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
