Since we have found it so useful, and you may too, let’s take a moment to discuss the built-in PHP date( ) function as we have used it. It is, of course, just one of many built-in functions provided by PHP, but a very handy one. The date( ) function can be quite complex, and you may wish to pursue further details about it and other frequently used, predefined PHP functions that we will discuss later.

In the meantime, let’s see what our calls to the date( ) function actually do. The function expects as input a string that specifies the format of the output string (i.e., the returned string value, since this is a value-returning function). The format string that we supplied in our first call to the function was "l, F jS". Unfortunately, the meaning of these symbols is not very mnemonic, and thus not easy to “guess”, so let’s explain what they mean.

First, the lowercase letter 'l' (not the digit 1, which is the first potential point of confusion) says that we want a full textual representation of the day of the week, such as Sunday, Monday, and so on. The next two characters (the comma and the blank space) are to be interpreted literally to give us a comma and a blank space following the day of the week in the output. Then the character F says we also want the full textual representation of the month, such as January, February, and so on. This is again followed by a literal blank space. Finally, the two-character sequence jS gives us the numerical date with an appropriate suffix appended, such as 1st, 2nd, 3rd, or 4th. The character j gives us the date, while the S character gives us the appropriate suffix (st, nd, rd, or th). As we said, somewhat demonic, rather than mnemonic.

Our second call to date( ) has as its input parameter the string "g:ia", which in fact gives us a time rather than a date, and things are no better here on the mnemonic front. The g gives us the current hour using a 12-hour format, without leading zeros, the i gives us the minutes in the current hour, with a leading zero if required, and the a appends a lowercase am or pm, as appropriate. The colon (:) is a literal value used to separate hours and minutes in the output.

See the end-of-chapter References for a link to a description of all the many ways you can describe the kind of output you want from the PHP date( ) function.

If you view the web page generated by welcome.php now, you should see something like what is shown in Figure 8.2. But, if you then choose the “view source” option of your browser, you will not see any PHP code. This should not be surprising, given what we have said earlier. Only the HTML markup resulting from the execution of the PHP code will appear as the source of the web page. As mentioned before, this ensures that clients cannot access the PHP code, which may reveal confidential information about the data stored on the server.

Under “normal” circumstances, when a browser sends information to a server and the server responds by sending a page back to the browser, the entire page must be redisplayed in the browser, even if only a small portion of that page has actually changed. This can cause browser response to slow down and generally appear to be much less satisfying to a user than a typical desktop application. A technology called AJAX can be used to help alleviate this situation. JavaScript (in conjunction with XML, which we will introduce briefly in a later chapter) can be used to communicate with the server and update only the changed part of a web page, thus speeding up the page-refresh process.

Note that AJAX is not a distinct new technology, but simply a way of combining a number of previously existing technologies. For the insight that spawned AJAX we are indebted (as we have pointed out in Chapter 6) to Jesse James Garrett, who also gave us the acronym.

We are now going to use the web page shown in FIGURE 8.3 (HTML markup and PHP script) and FIGURE 8.4 (corresponding browser display) to illustrate several things, only one of which is our need for AJAX.

Let’s begin by explaining how this page works. If you load the page into a browser, all the text will be black, but if you wait for a minute all the text will change color. At the end of each subsequent minute, one of four random colors is chosen and the text appears in that color. This is because the entire page is being “refreshed” every 60 seconds, which is accomplished by the meta element in line 17, whose two attributes (http-equiv="refresh" and content="60") should be self-explanatory. You can arrange for any web page to be refreshed with whatever frequency you desire with a similar meta element and the value of its content attribute set to the required time interval in seconds.

The “problem” with this is that the entire page is refreshed. It’s not a problem if that’s what we want, but if only a small part of a page (the date and time, for example) needs to be updated periodically, then refreshing the entire page represents a lot of wasted effort (and bandwidth). Sometimes the “problem” is just this wasted effort and bandwidth, but a complete page refresh can be a problem in other ways as well. For example, if a user is filling out a form and suddenly the page refreshes, the user may lose some or all of the data entered into the form and will need to start over and try to enter all the form data and submit it before the next refresh. This is likely to generate unhappy users, something no e-commerce website should have.

This is the problem that AJAX solves for us, as we will see in the next example. However, before we leave this example we want to discuss some other aspects of PHP that it illustrates for us.

$_SESSION['pageRefreshCount'] = 0;

In the previous section we discussed an example in which an entire page was refreshed, even though only a part of the page actually needed refreshing. In this section you will see how AJAX helps us to refresh just the part of the page that needs updating.

For this discussion we need to refer to FIGURES 8.5 and 8.6 for the markup and code, and to FIGURE 8.7 for the corresponding browser display. We begin with a high-level view. In Figure 8.5 we have a script element within the head element. This script element contains the definitions of the two JavaScript functions getCurrentTime( ) (lines 25–32) and updatePage( ) (lines 33–42) that we call later on in the second script that appears at the end of the body element in our document (lines 61–64).

Now let’s itemize the things that take place when this page loads:

1. As in the previous example, we start a PHP session and initialize a counter (lines 12–14). Note that this time around we call our counter key timedateRefreshCount rather than the former pageRefreshCount because in this example it is only the time and date information that will be refreshed, not the entire page.

2. The script element in the head element of the document defines two JavaScript functions that we call later.

3. The complete page is displayed for the first (and only) time by lines 46–60. This display includes the content produced by the short PHP script in lines 47–50, which we have discussed previously. Note in passing, however, that the value of the id attribute of the h3 element in the PHP script output is "timedate", since we will want to refer to this later.

   

   A Firefox browser display of ch08/welcome_ajax.php after at least one AJAX request has taken place and the color red has been applied to just the (updated) date and time information lines on the page.

4. Now we come to the script element in lines 61–64. The first thing this script does is call the JavaScript getCurrentTime( ) function, defined above in lines 25–32. This function, in turn, begins by creating an object reference of type HttpXmlRequest (line 27) and assigning it to the variable request. This is the object that will make our AJAX request to the server. To do this it needs to know the name of the script on the server to which it should make its request. We supply the name of the script to the variable url in line 28 and use this variable as one of the parameters in the function call on the next line. There is a bit of subtlety in calling the variable url, even though its value is just the name of a PHP script file. We can use only the file name because that script file is located in the same directory as the web page from which it is being called. But it could be a script that is located elsewhere at a location that would have to be given as a “real” URL for the value of the url variable.

   Next (line 29) a call to the request.open( ) function opens a connection to the script at the given url value (the second parameter), indicating the method for passing the data will be the GET method (the first parameter in the function call, and discussed in detail in section 8.6). The third parameter in the function call is the boolean value true, which in this case indicates that the connection is to be asynchronous. This means that once the connection has been made, the browser can carry on with other business and doesn’t have to wait until the connection is finished doing whatever it has to do and closes.

   The browser needs to know what to do when it hears back from the server. In this case we assign to the request.onreadystatechange property of our request object a reference to our JavaScript updatePage( ) function (line 30). But note that there are no parentheses following the function name in line 30 because we are not calling the function at that point. The function will be called only when the “ready state” of the function changes, in other words only when the browser hears back from the server.

   Finally, now that we are all set up, the AJAX request is sent to the server in line 31. The parameter is null in request.send(null) because we have no additional information to send to our server-side script.

5. Let’s shift to a server-side view and look at the server-side PHP script time.php shown in Figure 8.6. There is really nothing here we haven’t seen before; we have just grouped, consolidated, and rearranged some of the PHP code shown in Figure 8.3. But let’s describe what it does in this new context.

   The script begins by “joining” the PHP session that has already been started by lines 12–14 in Figure 8.5. Since this is the first call to the time.php, the “time date refresh count” will be 0, so the “greeting color” will be reaffirmed to be black. The date and time are then computed and sent back to the browser, along with the hidden paragraph containing the text color. Then, just before the script ends, the count is incremented so that on subsequent runs of this script it will not be 0, and a random color will be chosen for the text of the date and time display.

6. Now we go back to what’s happening in the browser and look again at Figure 8.5. When the time.php script sends its information back to the browser, the “ready state” of the request object will change, and that’s when our second JavaScript function update Page( ) is called. The body of this function (lines 35–41) consists of a single if-statement that tests the readyState value of the request object. It can have several values, but we want it to have the value 4, which essentially means “everything’s OK”. In that case the body of the if-statement is activated, so we get a reference to the h3 element with id value "datetime" and change its text color to whatever color came back from the server as the content of the hidden paragraph.

7. The call to the global JavaScript function setInterval( ) in line 63 of Figure 8.5 says, “Call the getCurrentTime( ) function every 60000 milliseconds (every minute), from now on.” Henceforth, then, the whole process will repeat, and from now on some color other than black will be used. Note, however, that although a “new” random color is chosen every minute, because there are only four colors from which to choose it may well be the case that the same color appears for two (or even more) intervals in a row.

Look first at test_get.html in Figure 8.11, in which the important things to note are method="get" in line 18, and "value1" and "value2" as the values of the name attributes for the two input elements (lines 19 and 20). Second, look at the corresponding display in FIGURE 8.12, in which the numerical values 2 and 5 have been entered into the form. If we now click on the Submit button, we will get the web page response shown in FIGURE 8.13 that is produced by the PHP script shown in FIGURE 8.14.

Look carefully at the content of the browser address bar in Figure 8.13, where you see this:

cs.smu.ca/webbook2e/ch08/test_get.php?value1=2&value2=5&submit=Submit

This is the URL of the script that processes the form data from test_get.html, but with some additional information tacked onto its end. What you’re seeing here is a typical example of how the GET method transfers form data from client (the browser) to server. Note first the two key/value pairs: value1=2 and value2=5. Now value1 and value2 are the “values” of the name attributes of the two input elements that accept the two numbers seen in the form of test_get.html (lines 19 and 20 of Figure 8.11), and 2 and 5 are the numbers we have entered into the textboxes created by those two form elements (see Figure 8.12).

If more form data was being submitted by the GET method, you would see more of these key/value pairs. The other important part of the syntax is this: The key/value pairs are separated by an ampersand character (&), and the sequence of key/value pairs is separated from the URL itself by a question mark character (?). Note that you also see at the very end of the URL the key/value pair submit=Submit. Even though we do not use this data on the server side, the information is sent simply because the corresponding input element has a name attribute (line 21 of Figure 8.11). From this you should be able to see why it is so important for any form control that has data that needs to be transferred to the server to have a name attribute.

So that’s one way that data can be transferred from client to server. How is this data received on the server side? Now you need to look at the PHP script in Figure 8.14 that receives and processes the data, and this is where another superglobal variable, namely $_GET comes into play. When we use the GET method to transfer our form data, the key in each key/value pair becomes a key (or “string index”) in the superglobal $_GET on the server side If this variable does not exist, it will be created. And, probably not surprisingly, the value associated with that key in the $_GET array is the value assigned to that key in the corresponding key/value pair that was passed at the end of the URL when we submitted the form. In other words, for example, in the particular example we discussed above, the value of $_GET['value1'] is 2 and the value of $_GET['value2'] is 5.

In line 12 of Figure 8.14 we use these values to perform a simple calculation and output the result. Nothing unusual there. However, note carefully line 10 of Figure 8.14, in which we simply display these two values. In this case the array values appear within a double-quoted string and now it is important that the key values of the array components within the square brackets not be quoted, if we want to be sure the interpolation happens properly.

You will encounter this difference in the use of quotes quite frequently as time goes on, so you may want to come back and revisit this example. Be sure to read the comments in lines 14 –19 of Figure 8.14, which also summarize what we might think of as a “best practice” for this situation.

Before we leave this example, we should point out that we also use it to illustrate the scope of a variable declared within a PHP function (even though this has nothing to do with GET or POST). Unlike JavaScript, PHP has no var keyword. In JavaScript we recommended always declaring a variable with the var keyword. This would ensure that a variable declared and used inside a function could only be seen inside that function and thus could not be inadvertently changed by something outside the function. Even without a var keyword, a variable declared inside a PHP function is still “local” to that function and cannot be seen outside the function. You should convince yourself that the rest of the script in Figure 8.14 (lines 21–33) illustrates this fact. Note in particular the definition of a simple PHP user-defined function, which is completely analogous to function definitions in JavaScript.

In Figures 8.11 to 8.14 we illustrate the GET method for transferring data from client to server. We also have a similar example illustrating the POST method, but the differences are not sufficient to justify another four figures here in the text. However, you should run the example, study the corresponding files, compare what you see with the analogous displays in Figures 8.11 to 8.14, and we will point out here the only major differences you should observe.

The two files that comprise the example are test_post.html and test_post.php, which correspond to the test_get.html and test_get.php files from the previous example. If you now load test_post.html, you will get a display with a form similar to what you see in Figure 8.12. The markup in test_post.html will, of course, have method="post" instead of method="get" in its opening form tag. If you enter two values and click Submit, you will get a display that looks like just the first two lines of Figure 8.13, since we do not repeat the last part of that example.

The important thing to do at this point is to look at the content of the browser address window of your display. This time you will see only the URL of the test_post.php file, with no data attached to the end of that URL. That’s the major visible difference between GET and POST. In the case of the POST method, the data is transferred “behind the scenes” and is not visible in the address window.

In the previous two examples we have illustrated how to submit form data to a script on the server, first by the GET method, and second by the POST method. However, it is possible to pass data directly to a PHP script without using a form, and often very convenient and useful to be able to do so. All we have to do is attach the data to the end of the script URL using the same syntax that we have already seen in the context of the GET method. The script can then access the passed data using the $_GET superglobal. We sometimes refer to this scenario by saying that GET is the “default” data-transfer mechanism, since we do not have to specify anywhere that we are actually using the GET method. This technique is very useful if several scripts are running on the server, are cooperating to perform a particular task, and some data needs to be passed from one script to another. Chapter 10 will illustrate this at several points.

This is illustrated by FIGURE 8.15 (display) and FIGURE 8.16 (script). Figure 8.15 is obtained by loading the script in Figure 8.16 with the data you see at the end of its URL in the browser address window shown in Figure 8.15. The output in Figure 8.15 is produced by the PHP code in lines 29–37 of Figure 8.16. The new thing in this code is line 33. We said previously that superglobal array keys should not be single-quoted when they appear within double quotes. However, the required interpolation will happen if we enclose the array component within braces (curly brackets), as we do here. We do not recommend this; we show it only because you may run into it and wonder what on earth is going on.

And finally, before leaving this example, note that we have again taken the opportunity to illustrate a couple of new and useful PHP features, in this case to make our script a little more “user-friendly”. You can see what we mean if you just load the script with no data at the end of its URL.

First, if you look at the if-statement starting in line 18 of Figure 8.16, you will see the built-in PHP count( ) function being used to check the size of the superglobal array $_GET. If the function returns a value of 0, that means the array is empty, and thus no data has been passed to the script. In this case, the body of the if-statement is executed, so the user instructions are output by the echo-statement and then the script terminates immediately with the exit(0) function call.

Here the echo-statement itself (lines 20–26) is perhaps more interesting than any we’ve yet seen, and contains what PHP (and some other languages) call a here document. This is kind of an odd name, so just think of it as saying this: here’s some text . . . just output it! Note that the text to output is not a string in the usual sense; that is, it is not enclosed in quotes of any kind. Instead, its beginning is indicated by the <<<INFO marker, and its end by the INFO; marker, where INFO is just a programmer chosen name, capitalized for easier visibility. The text is output “as is”, but note that in this case the text is going to an HTML document, which means that we can include HTML tags (like <pre> and <code>) and expect to have them properly dealt with at the destination.

This example also illustrates the usual syntax for a here document, but we should point out that the closing delimiter (INFO; in this case) must use the same name as the opening delimiter, must be on a line by itself, must start at the left margin, and must have a semicolon (;) at the end (see line 26 of Figure 8.16).

Since we now have these two methods—GET and POST—for transferring data, an obvious question arises: When do we use each? If you think back to the examples we used to illustrate these two methods, you may be able to make an intelligent guess at the answer.

Recall that when we use GET, the information sent appears in the browser address window at the end of the relevant URL. From this we can conclude that we should not use GET for any situation in which we would not want a user (or someone looking over a user’s shoulder) to see the information we are sending. This is just a simple common-sense security precaution.

Somewhat less obvious, but also true, is that when using GET the amount of data we can send is subject to a limit that may depend on both the client and the server, but essentially (once again) because all the data has to be tacked on to the end of the URL.

Both of these problems are solved by using POST. The GET security issue is not present when using POST, because the data transferred is not seen by the user. And the limitation on the amount of data transferred when using GET is not an issue either, since there is virtually no limit on the amount of data that can be transferred using the POST method.

And now you’ll be asking the following question: So why don’t we always just use POST? Well, it has to be admitted that GET is very convenient, especially since we can use it without the bother of setting up a form from which to send the data.

So, the web community seems to have settled on the following guidelines for the use of GET and POST:

1. Use POST if you are transferring a lot of data.

2. Use POST if you don’t want the information you are sending to be visible in the browser’s address box.

3. Use POST if the information you are sending is going to change something at the destination (the content of a database, for example).

4. Use GET if you are just retrieving some information from the destination (getting information from a database, for example).

5. Use GET for short communication between scripts on the server.

6. Definitely use GET if you are sending small amounts of data, you don’t care who sees it, and you don’t want or need to bother setting up a form.

FIGURE 8.17 shows this chapter’s feedback form all filled out and ready to be submitted. When the user clicks the Send Feedback button, the first thing that happens is the validation of the form data. If there is a problem with any of the data items being validated, the form data will not be submitted. Instead, the user will get a message of the type previously seen, and will have to correct the offending data item and resubmit.

On the other hand, if all of the data is valid, the data from the form will be sent to the server for processing by the PHP script shown in FIGURE 8.18, after which the following four things will happen:

• The PHP script sends an email to the business, like the one shown in FIGURE 8.19.

• The PHP script also sends a second email to the client as a permanent confirmation of the feedback submission. This consists of a message like the one shown in FIGURE 8.20.

• The user also gets an immediate browser-display confirmation that the feedback submission has been received, which is shown in FIGURE 8.21.

• Finally, a copy of the email message shown in Figure 8.19 is appended to a textfile on the server’s disk, which contains all previous user feedback submissions from this form. This version of the message looks like the sample shown in FIGURE 8.22. Note that the date of submission has been prepended to the version of the message stored on disk.

In the following sections we discuss in detail how each of these items is constructed and sent to its required destination.

We developed our feedback form and its data validation over Chapters 5, 6, and 7, but only now do we get to finally submit the form and have it processed on the server. The current version of our form is found in the file ch08/nature/pages/feedbackForm.php . We do not reproduce that entire file here. Instead we just remind you that, as we mentioned earlier, the opening form tag now looks like this (lines 13–14 of the file):

<form id="contactForm"
  action="scripts/feedbackFormProcess.php"
  method="post">

Note the absence of an onsubmit attribute and any call to a JavaScript function, because the validation is now being done via the HTML5 pattern attribute. The value of the action attribute of the form element is now a call to the PHP script feedbackFormProcess.php, which lives on the server (in ch08/nature/scripts), and which will process the data that is sent to the server from this form. And also, as we discussed in detail earlier, the method attribute of the form tag has the recommended value of "post" when we are sending information that is going to be stored on the server.

It’s now time to look closely at the PHP code that makes all of this possible: the two emails, the browser display confirming the submission, and a log of the submission being recorded on the server. The relevant PHP script is ch08/nature/scripts/feedbackFormProcess.php, shown in Figure 8.18.

Remember as well that in this context we will not use an integer index on the server side to access any value in the $_POST array. Instead we will think of the names we gave the form controls in our HTML document form (using their name attributes) as the keys to provide access to the corresponding data values input by the user. For example, we will use $_POST['firstName'] for access to the user’s first name because we gave the attribute name='firstName' to the input element into which the user entered his or her first name.

The script essentially consists of string manipulations to dynamically create the two email messages, the web page reply, and the log message. The message is slightly different in each case, depending on the recipient and where it is to be sent. Note that we have inserted descriptive comments to describe the script as a whole, as well as the various logical subsections of the script. The two forward slashes (//) that we used in JavaScript to give us a single-line comment are available for the same purpose in PHP as well, and the /* ... */ delimiters for multi-line comments are also available.

In this section we discuss the code segment in lines 12–17 of Figure 8.18 and the content of the corresponding email message of Figure 8.19. These lines construct the basic message that is sent via email to the business, and that forms the basis of all the messages we will build. This message is constructed using the text values from the input controls of our HTML feedback form, which are available as values of the $_POST array, as discussed earlier. Note once again, as we illustrated in our discussion of GET and POST, when either $_GET or $_POST is used inside double quotes, the key values inside the square brackets used with them should not be enclosed in quotes.

The complete result that is assigned to the variable $messageToBusiness is formed by joining the values from the $_POST array to the necessary “infrastructure” text items, such as

"From: "
"Email address: "

and so on. We are, in effect, putting email header information in front of the message text, because we are, after all, constructing a complete email.

Once the message has been constructed by joining all the required text items with the period (.) concatenation operator, we then assign the completed result to the variable $messageToBusiness.

We are now ready to send our message via email, and in this section we discuss the code segment from lines 21–23 of Figure 8.18, which deal with the actual sending of the email to the business, as shown in Figure 8.19.

The email is sent using the PHP built-in mail( ) function. The mail( ) function creates a message based on the Simple Mail Transfer Protocol (SMTP) specifications. SMTP is an Internet standard for sending email. The mail( ) function creates an SMTP-conforming email message using the following parameters:

• The email address of the recipient

• The subject of the message

• The message itself

• Additional strings that you may want to be appended to the header, such as From:, CC: (Carbon Copy), or BCC: (Blind Carbon Copy) fields. These fields have to be separated from the other fields, and from each other, by the sequence.

Under normal circumstances the business would be the recipient of this email message, but here we are using the email address of the book’s website as a temporary placeholder for “the business”, since we do not have an actual business email address. The subject for the email is whatever the client entered into the input element of the form with name='subject', so it is available from $_POST['subject'], and note that here the quotes enclosing the key value are needed. The message we want to send is the one we constructed above and is now the content of the variable $messageToBusiness.

The only thing still missing is any additional header lines that we may wish to add. We choose to add just a "From: " field by supplying the variable defined in line 21 as the fourth (optional) parameter to the mail( ) function:

$headerToBusiness = "From: $_POST[email]
";

Although this fourth parameter is optional, it is a good idea to include it with at least a "From: " field, because this will indicate, in the recipient’s mail program, who sent the message. This information is in the body of the message as well, of course, but without this “header” information, the mail message may appear, in the recipient’s mail program, to have been sent by a web server and may run the risk of being deleted or sent to a spam folder.

It won’t hurt to point out that in line 21 you are again seeing PHP’s variable interpolation in action, and this is a case where the key value within the square brackets should not be enclosed in single quotes.

Now that we have all four required parameters for the mail( ) function, we can issue the function call that sends the email message to the business, which we do in lines 22–23. This results in the “business” receiving the email message shown in Figure 8.19.

Of course, PHP also has to be able to access the email system on your server, which is another aspect of PHP configuration and you should confirm with your system administrator that your PHP installation has this access.

In this section we discuss the code segment from lines 28–36 of Figure 8.18, which deal with the construction of the email to the client seen in Figure 8.20.

This part of the script builds an additional email message, based on the previous one sent to the business. This time the message is a confirmation to the client. We create this confirmation message by first prepending the message with additional text that includes a greeting to the user using the salutation chosen by the user when filling out the form and the user’s last name (lines 29–31). We finish by appending a string containing a thank-you message and a company “signature” (lines 33–36).

Our feedback form has also given the user the option of asking for a reply by checking the appropriate form checkbox whose name attribute has the value "reply". Thus in our PHP script we can check whether the variable $_POST['reply'] has been set (line 38) , and, if so, deduce that the user wants a reply and thus append another string to our email that informs the user that a reply will be forthcoming (lines 38–39).

The appending is done with the special operator .= in lines 38–39. The behavior of this operator is analogous to that of other similar operators like +=, *=, and so on, that appear in most of the C-based languages, such as JavaScript, in the sense that

$string1  .= $string2

is equivalent to this:

$string1 = $string1 . $string2

In the code segment from lines 42–44 of Figure 8.18 we create the header for sending to the client the email message we constructed in the previous section, and then call mail( ) to actually send it.

There is nothing new going on here, but we should mention the following slight variation: For this version of the email, the subject is modified by preceding it with the string “Re:”, just to help distinguish it more quickly if, during testing, you are sending both emails to the same address, as we have done in our own testing.

In this section we discuss the code segment from lines 48–54 of Figure 8.18, which produces the browser display for immediate feedback to the client seen in Figure 8.21, and which contains exactly the same textual content as the email message to the client.

However, to convert that plain text into HTML markup appropriate for display in a browser there are at least two things we need to do.

First, we need to add to each instance of r the HTML tag <br> to get line breaks in the right places when the page is displayed in the browser. This we accomplish with the built-in PHP str_replace( ) function like this:

$display = str_replace("
", "<br>
", $messageToClient);

The str_replace( ) function takes three parameters. The first parameter is the “old” string that needs to be replaced; in this case that is " ". The second parameter is the new string that will replace the old string; in this case that is "<br> ". Finally, the third parameter is the original containing string that is to be modified by the replacement; in this case that is the string contained in the variable $messageToClient. The string that is returned by the call to the function str_replace( ) is stored in a variable called $display.

Second, in lines 49–53 we surround the contents of $display with appropriate HTML markup so that the displayed page will be a complete and valid HTML5 document. The final value of $display is “echoed” back to the browser for display, resulting in the (very simple) web page shown in Figure 8.21.

In this section we discuss the final code segment of our feedbackFormProcess.php script, lines 58–66. The purpose of this final part of the script is to write the user’s feedback to a file on the server.

A distinguishing feature of server-side programming is its ability to store information obtained from the user on the server, something that cannot be done with client-side technology like JavaScript. This information storage can be achieved in at least two ways:

• By placing the information directly into a file on disk

• By setting up communication with some kind of database and storing the data in the form required by that database

We will be looking at the database option in the following two chapters. In this section, we will look at the simpler case of file storage.

The feedback submitted by the user has already been sent to our business via email. However, it is also a good idea for our business to log all client feedback in a file on the server, so that we have it all in one place and can go through it at a later date to process it in some way, if we wish. We will store all user feedback in a file called feedback.txt in a subdirectory called data.

Whenever we wish to use a PHP script to write data to, or read data from, a file, the first step is opening the file. We accomplish this with another built-in PHP function called fopen( ). Typically this function takes these two parameters

• The name of a file or a URL containing the name of a file

• The mode in which the file is to be opened

and returns a file variable that can be used to work with the file once it has been opened.

The mode depends on the type of operation(s) we want to perform on the file once it has been opened. In our case, we are opening the file data/feedback.txt with the mode value "a" (line 58). This mode means that the file will be opened in “append mode”, which in turn means that any new writing we do will take place after the existing last character of the file. In other words, we’re adding to the end of the file. If the file does not exist, it will be created and then opened for writing. TABLE 8.2 shows a list of other modes that can be used for opening a file.

Let’s get back to our usage of this function. The value returned by the function call in line 58 is stored in a variable called $fileVar. From this point on, we can refer to the file by using the variable name $fileVar, in a read or write operation for example.

We also have another interesting (and somewhat scary) appendage to the function call (line 59):

or die("Error: Could not open the log file.")

This is actually just a handy way of saying that if the function returns an error, terminate the script after displaying the message shown in the argument of the die( ) function.

Note the path to the feedback.txt file in line 58. Because the script that is writing to this file is in the scripts subdirectory, and the data subdirectory containing feedback.txt is at the same level as the scripts subdirectory, we have to move up one level from scripts and then go down into data to reach feedback.txt.

Because we have opened the file for writing, we can use the function fwrite( ) to write to the file. The function fwrite( ) also takes two parameters:

• The first parameter is the file variable returned by the call to fopen( ). In our case, this is the variable $fileVar.

• The second parameter is the string that you want to write to the file.

Now, of course, we want to write to the log file the message string stored in the variable $messageToClient. However, before writing the message itself we want to write a blank line followed by a line of dashes to signal the start of a new log entry and then the date of this entry, and only then the actual message. Thus we have three calls to fwrite( ) (lines 60–66), and, as before, we use the function die( ) to terminate the program with an error message if any one of the writing operations fails for any reason. A typical entry in this log file is shown in Figure 8.22, which also illustrates an alternate date/time format.

This completes our discussion of the server-side processing of our feedback form.

A browser display of our BMI form is shown in FIGURE 8.23, where we have entered reasonable values for the form fields. Note that we have chosen one unit from the metric system (kilograms, for weight) and one non-metric unit (inches, for height), just to remind ourselves that it doesn’t matter.

As with our feedback form, when the user clicks the Compute your BMI button on the BMI calculator form, the first thing that happens is the validation of the form data. Only if all the input data is valid will the form data be uploaded to the server for processing. Otherwise the user will have to correct the invalid data and resubmit.

If all of the input data is valid, the data from the form is sent to the server. Then the following two actions are performed by our PHP script:

• Either a simple report containing the user’s BMI value, or a more detailed report if the user has requested one, is constructed and displayed in the browser. To get the more detailed report, the user must check the box indicating that choice on the form. An example of the detailed version is shown in FIGURE 8.24. In this case, note that the user has also checked the box requesting an email report, as the last line of the display indicates.

• If the user has requested it by checking the corresponding checkbox, an email message containing the chosen BMI report is now sent as well. An example of the email version of the detailed report being read by the roundcube email client is shown in FIGURE 8.25. Note that this email message is in HTML form, not just a plain text email. We will discuss the creation of such messages shortly. Note that if you try the form yourself from the book’s website, for example, and cannot find the email in your INBOX, you should check your SPAM box. Email messages that are coded using HTML are often subjected to stricter spam filtering scrutiny. The problem is further exacerbated by the fact that the sender address may not match the server that is sending the email message, which is yet another reason for the spam filter to be suspicious. This is one of the curses of the proliferation of email messages. You want to make sure that the email is as user-specific as possible, so that the spam filter does not suspect a mass emailing. Also, if you experiment with the BMI form many times, a spam filter may suspect that an automatic mailer is trying to bombard you with multiple copies of the mail and start blocking the message.

In the following sections, we discuss in detail the script that makes the decisions described in the above list and performs the required actions. But first, for the sake of completeness, let’s review the uploading of our BMI form data.

As was the case with our feedback form, we also developed our BMI form and its data validation over Chapters 5, 6, and 7, but only now do we get to finally submit the form and have it processed on the server. The current version of our form is found in the file ch08/nature/pages/bmiForm.php. Once again we do not reproduce that entire file here, but instead just show the revised opening form tag (from lines 16–17 of the file):

<form id="bmiForm" onsubmit="return bmiFormValidate( )" action="scripts/bmiFormProcess.php" method="post">

Unlike our feedback form, this form retains an onsubmit attribute since its data is still being validated by JavaScript. Note in particular the keyword return in front of the call to bmiFormValidate( ) in the value of the onsubmit attribute. The form will not be submitted if this return is not present, even if the function returns a value of true.

The value of the action attribute of the form element is now a call to the PHP script bmiFormProcess.php, which lives on the server (in ch08/nature/scripts), and which will process the data that is sent to the server from this form. And once again the method attribute of the form tag has the recommended value of "post" when we are sending information that is going to be stored on the server.

As you will see shortly, our complete PHP script on this occasion is actually split over two files—bmiFormProcess.php and bmiCalculate.php—but only our higher-level “driver” script in bmiFormProcess.php appears as the value of the action attribute, since the driver script itself takes care of the necessary access to the other script file.

Begin by looking at our PHP “driver” script in the file bmiFormProcss.php, which is shown in FIGURE 8.26. Note first of all that in line 14 of Figure 8.26 we perform a PHP server-side include that includes into this script the contents of the file bmiCalculate.php, which is shown in FIGURE 8.27, and which lives in the same directory as bmiFormProcss.php.

We have already seen how one PHP script can include another. In this case, we can view our use of this server-side include facility as helping us to practice information hiding, since we are, in effect, “hiding” some of our implementation details (some programmer-defined functions, in fact) in the included file.

The “higher-level” functions detailedMessage( ), simpleMessage( ), and mailBMI( ) that are called by the “driver” script in bmiFormProcess.php are defined in the file bmiCalculate.php, along with some auxiliary “lower-level” functions used by these higher-level functions but not called directly from our driver script. We will discuss all of these functions in detail in subsequent sections, but before doing that we need to make some general remarks about programmer-defined functions in PHP.

The first thing to note is that the general format of a function definition in PHP is completely analogous to what we saw in JavaScript:

function nameOfFunction(parameter_list)
{
   ... PHP code to perform whatever the function does ...
}

The first line is the header of the function, and again it begins with the keyword function, which indicates the beginning of a function definition. This keyword is followed by the name of the function, which should (as always) be well chosen to indicate the purpose of the function. This, in turn, is followed by a comma-separated list of parameters the function should receive when it is called, enclosed in parentheses.

The parameters listed in the parentheses differ from their JavaScript equivalents in that each name has to be preceded by a $ sign. In this respect PHP parameters are just like PHP variables. The PHP code that actually performs the task of the function is, as usual, called the function body and is enclosed in the usual pair of braces {. . .} immediately following the function header.

The rest of the PHP script in bmiFormProcess.php is relatively simple. The variable $message is used to store the HTML markup that will be used for browser display as well as for emailing. If the user has requested a detailed report, the variable $_POST['details'] will be set, and we will assign the value returned by the call to the function detailedMessage( ) to the variable $message (lines 16–17). On the other hand, if the user did not check the checkbox named details, the value of the variable $_POST['details'] will not be set, and the variable $message will be assigned the value returned by the call to the function simpleMessage( ) (lines 19–20). In either case, the variable $message is then echoed to a dynamically generated web page similar to the one displayed in Figure 8.24.

The next decision to be made in our bmiFormProcess.php script is whether to send an email or not. This decision is based on whether the user has checked the checkbox named wantMail. If it is checked, then the corresponding variable $_POST['wantMail'] in our PHP script will be set, and we therefore call the function mailBMI( ) to build and send an HTML-encoded email report (line 24). The function takes two parameters:

• $_POST['email'], which contains the value from the textbox named email in the form

• $message, which contains the message we just generated by one or the other of the two message-generating function calls

In this case we also echo a message to the end of the dynamically created web page saying that the BMI report has also been sent via email (line 25).

This completes the overview discussion of our driver script. In the following sections we proceed with a top-down discussion of the programmer-defined functions called by this driver script, namely detailedMessage( ), simpleMessage( ), and mailBMI( ), as well as the lower-level programmer-defined functions that compute the BMI value.

We begin our study of the code from bmiCalculate.php by looking at the two functions simpleMessage( ) and detailedMessage( ), shown in lines 10–43 of Figure 8.27.

Consider the function detailedMessage( ) in lines 19–43 first. This function takes four parameters: $height, $heightUnit, $weight, and $weightUnit. In the body of the function, the very first statement (line 22) is a call to the built-in PHP function sprintf( ). We use it here to format the numerical value and return the result as a string. We should mention that this function is similar to the function by the same name in the programming language C, on the off chance you may have seen it there. Note that here we are making good use of the appropriate built-in PHP function for this particular task, while in JavaScript we wrote our own (for purposes of illustration, as you may recall).

The function can take a variable number of parameters. In our case, we have two:

• The first parameter must be a string indicating a format specification for the number to be printed (the second parameter). We are using the string "%.lf", which means that the value given by the second parameter should be printed as a floating-point value (real number) with one place after the decimal. For a link to details on other formatting options, see the end-of-chapter References.

• The second argument in our case is the actual value that will be printed. It will be the value returned by a call to another programmer-defined function called calculateBMI( ), which also takes four parameters, $height, $heightUnit, $weight, and $weightUnit, and returns the value of the BMI. We discuss this function in the following section.

The string returned by the call to the function sprintf( ) is stored in a variable called $bmi (line 22). The next statement in the function detailedMessage( ) (lines 24–29) builds the HTML-encoded message (i.e., a message containing HTML markup) using the four values that were passed to the function as well as the properly formatted value of the BMI given by the variable $bmi. The complete string thus formed is stored in a variable called $text. Note that in this case, in the interests of brevity and simplicity, we do not bother to create a valid HTML5 page for the display.

Next, based on the range within which the BMI value lies, a message about whether the BMI is low, high, or reasonable is appended via a compound conditional statement. This conditional is really a sequence of nested if-statements of the kind also available in JavaScript.

The final message in the variable $text is returned to the calling function.

The function simpleMessage( ) returns a simpler report, but does similar computations. It contains nothing that requires further discussion, but you should confirm this by reading through its code in any case.

Before we leave this part of the discussion, line 24 of Figure 8.27 deserves some additional comment. Note that the value of the src attribute is an absolute path to the logo image file. In fact, it is a complete URL to that file. As you know, in earlier chapters we have emphasized that relative paths are always to be preferred to absolute paths, but sometimes you just cannot use a relative path, and this is one of those times. Remember that we are preparing some text that may be sent as part of an email message to a user who could be anywhere, and a relative path in that user’s email will be meaningless to that user, so the user’s email program needs to know where (on the Internet) the image file is located. We could have used the full URL to the logo image file in ch08/nature/images, but to make the URL somewhat shorter we have made a new images directory in our home directory and placed a copy of the logo image file there.

In previous sections, we dealt primarily with the string manipulations needed to create dynamic web pages and send emails. In this section, we will look more closely at numerical computations in PHP, which we choose to perform with programmer-defined functions in the same way we did in JavaScript. In fact, what we do here is remarkably similar to what we already did in JavaScript.

As we have already observed, the numerical computations used by the functions simple-Message( ) and detailedMessage( ) are performed by the function calculateBMI( ) (lines 51–58 of Figure 8.27), which takes the four parameters, $height, $heightUnit, $weight, and $weightUnit, and returns the BMI value. Note that prior to calling this function, all input data entered by the user has been validated client-side, so we can assume that the fields height and weight are numbers lying within a reasonable range.

The BMI calculation can be done in various ways, but before doing any calculations we choose to convert all values to the metric system, if they are not metric already. Hence, if the user has entered the height in inches, it is converted to centimeters using the function inchesToCentimetres( ) (line 46) in the first conditional statement (line 53). Similarly, if the user has entered weight in pounds, it is converted to kilograms using the function poundsToKilograms( ) (line 47) in the second conditional statement (line 54). The function calculateBMI( ) then converts the centimeters to meters by dividing the height by 100 and the BMI is simply calculated (in a metric-unit calculation) as the ratio of the weight to the square of the height (lines 55–56).

The functions inchesToCentimetres( ) and poundsToKilograms( ) return the centimeter or kilogram equivalent of inches or pounds using appropriate factors.

In these functions you see the arithmetic operators for multiplication (*) and division (/) in action, and you will be relieved to learn that the usual operators for addition (+), subtraction (-), and modulus (%) are also available in PHP, all conforming to the usual precedence rules, again as in JavaScript.

The email messages that we sent to the business (Figure 8.19) and the client (Figure 8.20) from our feedback form were simple text messages. However, the email message shown in Figure 8.25 is in HTML format. The built-in PHP function mail( ) can actually be used to send any type of mail that is normally sent through most email clients (including HTML email).

Our programmer-defined function mailBMI( ) to handle this is shown in lines 60–67 of Figure 8.27. This function has a little more work to do before it calls the built-in function mail( ) that sends the HTML version of the BMI report, so it needs the following two parameters:

• The email address of the recipient (obtained directly from the submitted form in $_POST['email'], as shown in the call to this function in line 24 of Figure 8.26)

• Our HTML-encoded BMI report

To get the second parameter in the proper form so that the message is sent as HTML rather than plain text by mail( ), we need to make that message conform to the requirements of the SMTP for such messages.

Here this means that we have to provide an appropriate header, which we do in lines 63–64 of Figure 8.27, which will have the effect of notifying the recipient’s email client that this is an HTML email. The rest of the header is the same as before, and again contains the "From: " address (line 65).

Finally, our programmer-defined function mailBMI( ) then calls the built-in PHP function mail( ) to send the message. You should note that some recipients may not receive the message as HTML, either because their email program cannot handle it or because they have this feature turned off in that program. This is less of a problem nowadays but still one to consider.

This completes our discussion of the programmer-defined functions called either directly or indirectly from our driver script bmiFormProcess.php.