Week 8

David’s taken care to convert line by line as similarly as possible, if you’re interested in opening both side-by-side and comparing them to notice differences. (For your convenience, here’s speller.c.)

These four functions were what we wrote in dictionary.c for Problem Set 5, but now we can rewrite them in PHP. Notice how we declare functions with function, and pass in variables not with a type but just the variable name with a $ in front.

Notice that line 5 was all it took to declare a hash table. In line 3, we create a variable to store the size of the hash table, just like we would in C.

Notice that we have to start by mentioning the global variables we want to use in our function (which we didn’t have to in C).

Then we use a new foreach construct. file($dictionary) returns the dictionary file as an array of strings, which we can iterate over, and refer to each string as $word.

With each $word, we set the value in the hash table for that word to be true, signifying that it is a valid word.

chop removes the \n in each word (or trailing whitespace more generally), since each line that is passed in from $dictionary will have a \n that we don’t want to keep.

We’ll also keep track of the size, and then return true.

All we have to do is refer to the global variable $size and return it.

First, we want to have access to the global $table variable. Then, we return true if our hash table has a value set for $word (after we convert it to lowercase).

Notice that we can simplify this even more by returning the value of our condition, instead of returning true if our condition is true and false if our condition is false:

...
    function check($word)
    {
        global $table;
        return isset($table[strtolower($word)]);
    }
...

Notice that the URL has changed to register-0.php, and even though the formatting isn’t very pretty, we see that the values were passed in.

The page has printed what looks like an Array in which these three values were stored.

But also notice that the URL doesn’t include the queries as strings, like we saw with Google and /search?q=cats.

all it does is print out the $_POST variable. We see that line 9 has a <?php tag, nested inside a <pre> HTML tag that means "preformatted text," or text we want monospaced like a typewriter.

print_r is the "print recursive" function that prints everything in its argument.

And inside, we pass in $_POST, which contains everything the browser passed in, stored for us by PHP.

which brings us to:

So there’s more interesting code here, particularly lines 4-8. The comment says that this chunk of code is validating the submission.

The form looks the same, but when we submit it, we see this:

The real frosh IMs program would just email the proctor in charge the form information, but here we’ve programmed it to email jharvard@cs50.harvard.edu so we can see what happens.

We start by opening the <?php tag, and then requiring a special library called phpmailer in line 4, like how we might include one in C.

Then we validate the submission, and if none of the fields are empty, we "instantiate mailer" in line 9, which is just asking for a new PHPMailer, which is an object, that we put into $mail.

In lines 13-16, we set the protocol for sending our email to SMTP, the host to Harvard’s servers, the port to 587, and adding security with TLS, a protocol for securing communication with those servers. (We figured all this out by asking HUIT’s help desk.)

But then in line 19, it looks like we can send email from anyone to anyone, followed by a subject and a body of the email.

In PHP, the dot (.) operator allows us to concatenate strings (put strings together), as we do in lines 29-33, since we’re mixing variables with text.

Finally, in line 36, we try to send the email by calling the send function with $mail->Send(), and, if that doesn’t work for some reason, die with an error (no, seriously) in line 38.

Otherwise, if we didn’t meet the condition that all input was not empty (looking back up to line 7), then we send the user back to froshims-3.php in line 43, which is our original registration form.

If everything went successfully, though, we’d get to line 55, "You are registered! (Really.)", which is what we saw at the beginning of this example.

$_COOKIE

$_GET

$_POST

$_SERVER

$_SESSION

…​

So somehow the page knows how many times we’ve been there, even though the page finishes loading and the connection is closed.

It looks like we’re calling a function, session_start(), in line 4, which does what it says, start our session, which really means that we’re creating a shopping cart, or bucket, that we can store values in and get again later when the user comes back. (Technically, this "bucket" is stored as a cookie in the user’s browser, so if they clear their cookies, we won’t have the values anymore.)

So in line 7, we check if the value for counter is set in $_SESSION, and if it is, set $counter, our local variable, to it. Otherwise, we set it to 0.

Then we increment the value of $counter, and put it back in our shopping cart (i.e., $_SESSION superglobal). (Remember that $_SESSION, like $_POST, is like a hash table — an associative array that we can index into using words.)

This looks like version 0 of CS50’s website, with links to Lectures and the Syllabus in what looks like an unordered list (<ul>). We can right click the page and View Source to confirm such:

So it looks like the Lectures page links to each week (although we only have 0 and 1 for now) and each week has a link for the slides for each day.

There’s a README file that probably has an explanation of the code, index.php, which is what webservers usually use as the default page if no URL is specified. Earlier, we just visited http://localhost/src8m/mvc/0/, and our server just knew to return index.php by convention.

If we look back at index.php from mvc/0, we notice that there are many parts that are reused in all our files:

<!DOCTYPE html>

<html>
    <head>
        <title>CS50</title>
    </head>
    <body>
        <h1>CS50</h1>
        <ul>
            <li><a href="lectures.php">Lectures</a></li>
            <li><a href="http://cdn.cs50.net/2014/fall/lectures/0/w/syllabus/syllabus.html">Syllabus</a></li>
        </ul>
    </body>
</html>

For example, lines 1-9 would probably be almost identical, apart from the parts that say CS50.

And lines 12-14 are probably also the same, with lines 10 and 11 being the only main differences.

It looks a bit more complicated before, but all it does is replace some of the repeated lines earlier with line 1 and line 8. (We left the lines with <ul> there in case some pages didn’t have a list.)

require is like #include in C, where the files are effectively copied and pasted in that location. So we can see that header.php contains the header of our page:

<!DOCTYPE html>

<html>
    <head>
        <title>CS50</title>
    </head>
    <body>
        <h1>CS50</h1>

And footer.php just contains the footer, the bottom, of our page:

    </body>
</html>

Now we’re requiring some helpers.php file, which, like helpers.c from Problem 3, is where we place helper functions.

Line 3 looks a little different, which looks like it’s calling a function called renderHeader and passing, inside its parentheses, square brackets that represent an associative array. In C, we had to pass in the same number of arguments in the same order to functions every time, but now we can pass in any number of key-value pairs in any order. title is the name of an argument and CS50 is its value. We can go into helpers.php and see how this is handled.

In line 6, we define a function by simply stating function, with no need to declare a return type, and ($data = []) means that our function renderFooter takes an associative array as an argument named $data, and if one isn’t passed in, we assume it’s = [], an empty array (a feature that C doesn’t have).

In line 8, extract just takes the keys in $data and creates variables from them.

So in index.php we passed in ["title" ⇒ "CS50"], and in helpers.php, renderHeader extracts that data and requires header.php, which now looks like:

<!DOCTYPE html>

<html>
    <head>
        <title><?= htmlspecialchars($title) ?></title>
    </head>
    <body>
        <h1><?= htmlspecialchars($title) ?></h1>

Now we don’t have hardcoded titles, but rather htmlspecialchars($title), which takes whatever we passed in with the key title and cleans away characters like < and > that might break the site by closing or opening tags, if they were printed as-is. (Or even worse, run scripts that alert or redirect the user.)

Notice too that this time our code is starting with <?= instead of <?php, which is shorthand for <?php echo, or print with PHP, whatever is inside those tags.

We realized that renderHeader and renderFooter were almost identical functions, so we combined them into one function, render, that takes another argument, the name of the template, or file to render, and optionally some key-value pairs (which we want for the header but not the footer).

It’s a bit more complex, since we take the first argument, $template, and look for the file we want to use, instead of hardcoding it, but otherwise works the same way.

We’ve kept everything else the same, but moved helpers.php to a folder called includes, and updated line 1 to call the file in that directory now.

header.php and footer.php live in templates now, another step toward better design. Instead of mixing together HTML and CSS and PHP, which is hard to maintain, we want to factor out as much as we can, just like how we had separate functions and even files in C.

We can use .. to access the parent directory, since index.php is in public and we need to go up one level.

We’ll put our programming logic, the brains of our website, into files that we’ll start calling controllers. We’ll have views, like templates, that has the aesthetics - taking the data and formatting them with color and layout. Finally, we’ll eventually get to the model, databases that we can store and retrieve data from.