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
<select><option> 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 <option>s. 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.
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.
Indeed.
Greg
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
