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