AJAX In Action [54]
header("Content-type: application/xml");
Tell client we are returning XML
echo "\n";
$db=mysql_connect("my_db_server","mysql_user"); mysql_select_db("mydb",$db);
Fetch the
$sql="SELECT id,title,description,price,colors,sizes"
results from
."FROM garments WHERE category=\"{$cat}\"";
the database
$result=mysql_query($sql,$db);
echo " while ($myrow = mysql_fetch_row($result)) { Iterate through resultset printf(" Web server MVC 95 ." $myrow["id"], $myrow["title"], $myrow["description"], $myrow["price"]); if (!is_null($myrow["colors"])){ echo " } if (!is_null($myrow["sizes"])){ echo " } echo " } echo "
?>
The PHP page in listing 3.5 will generate an XML page for us, looking something like listing 3.6, in the case where we have two matching products in our database. Indentation has been added for readability. We’ve chosen XML as the communication medium between client and server because it is commonly used for this purpose and because we saw in chapter 2 how to consume an XML document generated by the server using the XMLHttpRequest object. In chapter 5, we’ll explore the various other options in more detail.
Listing 3.6 Sample XML output from listing 3.5
Real itchy. As worn by the great detective Sherlock Holmes. Pipe is model's own.
So, we have a web server application of sorts, assuming that there’s a nice Ajax front end to consume our XML. Let’s look to the future. Suppose that as our product range expands, we want to add subcategories (Smart, Casual, Outdoor, for Licensed to jonathan zheng 96 CHAPTER 3 Introducing order to Ajax example) and also a “search by season” function, maybe keyword searching, and a link to clearance items. All of these features could reasonably be served by a similar XML stream. Let’s look at how we might reuse our current code for these purposes and what the barriers might be. Problems with reusability There are several barriers to reusing our script as it stands. First, we have hardwired the SQL query into the page. If we wanted to search again by category or keyword, we would need to modify the SQL generation. We could end up with an ugly set of if statements accumulating over time as we add more search options, and a growing list of optional search parameters. There is an even worse alternative: simply accepting a free-form WHERE clause in the CGI parameters, that is, $sql="SELECT id,title,description,price,colors,sizes" ."FROM garments WHERE ".$sqlWhere; which we can then call directly from the URL, for example: garments.php?sqlWhere=CATEGORY="Menswear" This solution confuses the Model and the View even further, exposing raw SQL in the presentation code. It also opens the door to malicious SQL injection attacks, and, although modern versions of PHP have some built-in defenses against these, it’s foolish to rely on them. Second, we’ve hardwired the XML data format into the page—it’s been buried in there among the printf and echo statements somewhere. There are several reasons why we might want to change the data format. Maybe we want to show an original price alongside the sale price, to try to persuade some poor sap to buy all those itchy golfing socks that we ordered! Third, the database result set itself is used to generate the XML. This may look like