[MUSIC PLAYING] DAVID J. MALAN: All right, this is CS50. And this is already week nine. And this means this is the
week where we synthesize the past several weeks, from Python
to SQL to HTML to CSS to JavaScript. Each of those languages that we've
rather looked at in isolation now rather come together
toward an end of just making more modern applications, be them web
based or be they mobile based as well. So, up until now, we've been using,
to serve all of the web stuff that you've done, this
program called HTTP server. Now, this isn't a CS50 thing. It's just a standard program that
we've installed into Codespaces. So it's a Linux program that
just runs your own web server. And it allows you to run
it on nonstandard ports. For instance, you've been
using it on port 80, 80 only because Codespaces is using 80 and
443, recall, which were the defaults. But, up until now, this
program's purpose in life was just to serve static content,
so like web pages written in HTML, maybe some CSS, maybe some
JavaScript that you wrote in advance that just never really
changes until such time as you log back into the server, save
the file after making some edits, and then someone reloads their page. But, of course, the web that we all
use today, be it Gmail or any website, is so much more interactive. When you search for
something on Google, there's no Google engineer that, in
advance, has written up an HTML page containing a list
of 10 cats or 10 dogs or 10 birds just waiting for someone
to search for that particular keyword. Rather, there's some database involved. The HTML's being dynamically generated. And it's all indeed very dynamic. So whereas, last week,
we focused on websites, this week we'll focus
really on web applications. And, really, the key difference
is just that applications take input and produce output whereas
websites are really generally thought of as static. But it's a blurry line. It's not necessarily a
technical distinction. But today things start to
get much more interactive. So we're not going to be able
to use HTTP server alone. We're going to need something
a little smarter that knows how to take input from users via the URL. So, in fact, let's look at some sample
URLs that we looked at last week just to remind ourselves of some of
the jargon and really the syntax. So here's a standard
URL and Flask, recall, is just the default page on the server. And, usually, the file is
called index.html by convention. But, depending on the operating
system or web server you're using, it could be a different file. But index.html is probably
the most common default. So you could explicitly state
the file name on most web servers like file.html,
index.html, whatever it is. You can have folders or
directories on a web server. And this would imply that
your index.html file is in a folder called folder in this case. Or you can have a folder/file or even
folder/folder/folder/file and so forth. So this is a very direct mapping
from the URL to the file system, so to speak, like the
hard drive on the server. But, today, we're going to do, like
most computer scientists tend to do, is more of an abstraction of this. This is how URLs look. But it turns out, once you
control the web server with code, you don't need things to line up
with actual file names and files. You can really put your
content wherever you want. And so, in general, we're
going to focus today on just thinking of everything
after the domain name as a path, generally speaking. And a synonym for this, in the context
of the web, would also just be a route. So a route is just some number of
letters, maybe some slashes, maybe a file extension that refers to
some part of your application. But, more interestingly-- and this
is what makes things an application and not just a static website-- recall, that this is how
websites can take input in the form of URLs, a question
mark, then key equals value pair. Or if you want two or
maybe three or four, you separate them with ampersands. But that's kind of it. The web today is going to work
just like it did last week, but we're going to start leveraging
these primitives in a much more powerful, more interactive way. So here, recall, is what might
be inside of the virtual envelope when you search for
something on google.com. It's going to request of
the web server/search, which is the name, by convention,
of Google's search application because they've got a lot of
businesses running on their servers. And if you have ?q=cats, this
is essentially the message, the HTTP message that would've been
in last week's virtual envelope when I searched for cats. Hopefully, you get back a
response from the server containing those actual cats. But, again, there's probably a lot
more logic going on with a database and somehow generating that HTML
that Google is doing for us. So we, today, are going
to introduce really what's called a framework or
technically a microframework, which means it's relatively small versus
alternatives that are out there. And it's called Flask. So Flask is really a
third-party library-- and it's popular in the
Python world-- that's just going to make it easier to
implement web applications using Python. There are alternatives. A very popular one is called
Django, which some of you might've heard of before. And there's dozens of others in
decreasing popularity daresay. But Flask is among the most
popular microframeworks, which means you can really just
solve a few problems pretty simply without feeling like you're
learning some third-party library as much as you are learning
concepts that transcend one particular implementation. So we're going to introduce you
to a framework called Flask. And that's going to
allow us, ultimately, to start web applications not
by running HTTP server today but literally running flask space run. So this framework literally
gives you a command, on your Mac, your PC, your
codespace once it's installed, that allows you to start
a web server by running flask run instead of HTTP server. So, again, last week, it was
all about static websites. This week, it's all about
dynamic websites instead. And, by framework, we really
generally mean-- not just using some third-party code
but third-party conventions that just some human or
humans decided is the way you will build your applications. Usually, this is just based on lessons
learned after making application after application. Humans around the internet
realized, you know what? We should probably standardize the names
of our files, the names of our folders, and how things are laid out. And so, even though this is
not the only way to do things, the way that Flask prescribes that
we programmers do things is this. We'll, starting today, always have
a Python program called app.py by convention, like in our folder. And we're going to have a folder
called templates, inside of which is any of the actual HTML, maybe
CSS, maybe JavaScript that we write. But you can actually put some
of that content elsewhere. And, in fact, you'll see
there's going to be generally two other files or folders you'll
see me create or me use today. One is called requirements.txt,
which is literally just a simple text file wherein you specify one per
line what third-party libraries you want to use. This file just makes it easy to
install those libraries with a command. And then, lastly, a static folder. And it's in this folder that you put
images or .css files or .js files, literally files that are meant to be
static that you might change them once in a while, but they're
not changing every day. And so you just want to isolate
them to a particular folder. Why is it this way? Eh, a bunch of humans decided
this feels like a clean solution. But reasonable people will disagree
and different frameworks lay things out differently. So, when using a framework for the first
time, you take a class or read a book or read the documentation. And it will essentially guide you to
how you should lay out your application. So let's go ahead and do exactly that
and make an application that quite simply and, by design, underwhelmingly
implements Hello, world. But, rather than do
this statically, let me do it in a way that starts
to use this framework so that, in the next version of it,
we can actually take user input and have it say not Hello,
world but maybe Hello, David, or Hello, Yulia or anyone else. All right, so let me go
over here to VS Code. And let me go ahead, and, initially,
let me start with the familiar. And let me go ahead and start by simply
creating the HTML page that I really want to show to my visitors
when they visit my application. So I'm going to go ahead and,
somewhat incorrectly, initially, but just to make a point,
I'm going to go ahead and do code index.html to open up a new tab. I'll hide my terminal window just
to give myself some more room. And then really fast I'm going to
type out some boilerplate HTML. So DOCTYPE html, just like last week,
open bracket html Lang equals en just to tell the VS Code that I'm-- to tell the web that I'm
largely using English here. In the head of my page, I'm going to
have, of course, the title of the page. And I'll keep it simple and
just say something like hello. But just so that this website actually
renders nicely on mobile devices, I'm going to use one of those
meta tags we talked briefly about last week whereby if I
say meta name equals viewport-- and viewport refers to just the big
rectangular region of your browser-- the content of this meta tag
is going to be initial scale equals 1 and width equals device width. I always have to copy-paste
this or look it up myself. But this line here
essentially tells the browser that, no matter how wide
the device is, whether it's a laptop or desktop or maybe a
vertical cell phone or tablet, size the viewport to that device. Otherwise, your website might
look super small on mobile devices if you don't use this tag to tell
the browser, take into account the actual device width rather
than shrinking the 12-point font to something that's
hard for folks to read. So, for now, I'm just going to
generally copy-paste that or type it out from my printout here. All right, beyond that, we
need the body of the page. We'll keep that simple. So body, and then, in
here, hello comma world. So that's it for my website thus far. It's static. Nothing about this is going to
incorporate my name or anyone else's. So I could technically use HTTP
server to serve up this web page, open it in a browser, and I
would see the actual contents. But let's instead create
a bit of work for us and sort of overengineer this problem
but to set the stage for actually taking in dynamic input
like a user's name. So let me go ahead and to do this. I'm going to go ahead and
open my terminal window again. I'm going to close the index.html file. I'm going to make a new
directory called templates, which, again, was the
default folder name I mentioned that this framework expects. And I'm going to move index.html into
that templates folder using mv, a Linux command. If you're more comfy, you can open up
the file, the File Explorer at right. You'll see, in advance,
I downloaded a directory. I'll occasionally borrow
content from today called src9, but there is my templates folder. And you could click in
the GUI in order to do what I just did at the command line. All right, and, after this, let's
go ahead and create one other file, app.py. And, in app.py, let me
go ahead now and do this. I'm going to import some functions that
come with this framework called Flask. So I'm going to say from flask, in
lowercase, import Flask, capital F, and also a function called render
template and an object called request. Now, how to do this? You literally read the documentation,
or you listen to someone like me tell you to begin
your program this way. In the Flask framework comes
three pieces of functionality that are just useful to incorporate into
my own program as we're about to see. Here's the line of code via
which I can tell this framework to treat my file, app.py,
as indeed a web application. I create a variable,
typically called app. I set that equal to the
return value of calling this Flask function and pass
in it, somewhat weirdly, the name of this file. So this is the only weird thing for
now in that we haven't used this much, if at all. __name__ is a special
variable in Python that literally refers to the current file's name,
no matter what file name you gave it. So it's a nice way of
referring to yourself without manually typing the file name,
which might change down the line. And then, lastly, I'm going to do this. And this is one other piece
of new syntax for now. I'm going to use an @ and say app.route. And then in quotes, as an
argument to this route function, I'm going to specify the route for
which I'm implementing some code / being the default, by convention. I'm going to define immediately
below that a function that I can technically
call anything I want, but I'm going to get in the habit
of using reasonable defaults. So I'm going to call this
function index by default. But that's not a hard requirement. And then, inside of this
function, I'm simply going to return this, return
"hello, world", quote, unquote. And that's it. This I now claim is a beginning
of an actual web application. It looks a little magical or
cryptic as to what's going on. But, per the jargon I introduced
earlier, this function here app.route is defining a route for
this application that implies that whenever
a human visit slash on this application,
what should happen is this function index should get called. And that function's purpose
in life, at the moment, is just to return, quote, unquote,
"hello, world", and that's it. So let me go ahead and do this. Let me open my terminal
and just to keep everything clean because we're going to
have a bunch of applications today in the works. I'm going to create one
other folder called hello. And I'm going to move app.py and
templates into that hello folder. So if I now type ls in
my own personal account, I've got that folder hello and also
src9, which I brought with me today. So if I now cd into
hello and type ls again, I'll see the two things we
just created together, app.py and the templates folder. And if I go one step further
in ls templates itself, I should see, of course, index.html. All right, so a lot of steps to
go through just to get started. But you'll see that this is
fairly boilerplate eventually. I'm not going to run
an HTTP server, but I am going to run flask run, which will
turn this app.py into a working web application. The output after I hit Enter is
going to look a little more cryptic. It's going to warn me this
is a development server. You should not use that same
command in the real world. You should actually configure Flask
a little differently if you're going to use it in the real world. But it does show me the random
URL that GitHub created for me. And I'm going to go
ahead and open this URL. It's going to open in a new tab. And, voila, that is my web application. Completely underwhelming,
but you'll notice that, even though Chrome
is hiding this, this is the equivalent of my having visited
at the end of this URL simply a slash. All right, if I zoom out here, though,
and maybe right-click or Control-click, and I choose View page source-- recall, this is available
in most every browser-- you'll see that this isn't actually
HTML because, at the moment, I'm literally just returning,
quote, unquote, "hello, world". So, yes, it's text. It's being rendered as a web page. But it's not technically a
web page that has valid HTML. So what I'm going to do here is this. I'm going to go back into VS Code. I'm going to open a second
terminal by clicking the plus icon toward the
bottom right of my screen, just so I can keep the server running. But-- actually, nope, let
me go ahead and do this. Let me kill this terminal. Let me actually-- oops,
I killed the wrong one. Let me instead go into
my hello directory again. Let me open up app.py. And this time, instead of saying
hello, world, let me do this. I want to return the
contents of index.html, which is that whole file I created,
but I can't just specify its file name. But I can do this. I can call a function
called render_template, which comes with Flask. And its purpose in life is to
go get that file from a folder called templates, open
it up and then send all of those bytes,
all of those characters to the user's actual browser. So let me go ahead and do this. Let me open my terminal again. Let me do flask run inside
of this same folder hello. I'm now going to go back to
my tab here, click Reload, and nothing appears to have changed. But if I right-click and choose View
source this time after reloading, now you'll see all of
the HTML that I composed. All right, so this has
taken way more steps to do what we achieved by just
running HTTP server last week. But here's where now things can
get a little interesting, whereby now that we have this
framework laid out, we can actually introduce
other features of the framework to make things more dynamic. So, for instance, what
I'm going to do is this. I'm going to now introduce
a feature of that variable that I also imported called request,
which refers to any HTTP request. And it turns out,
there's a property inside of there called args,
which is actually going to be a dictionary of all
of the key value pairs that the human might've
provided via the URL. So I don't have to figure out, how do I
find the thing after the question mark? I don't have to worry about
parsing the ampersands. Flask does all of that
for me and just hands me anything after the URL in
a Python dictionary instead. So let me do this. Let me go back to VS Code here. Let me go ahead and hide the terminal. But, in app.py, let me go ahead and
make a relatively simple change. Let me go ahead and do this. Let me go ahead and open up in my hello
folder, let me open up index.html. And let me go ahead and get rid of
world and just put a placeholder here. Using curly brackets, two of
them, on the left and right, I'm going to go ahead and
plug in a variable like name. So here's now where I'm treating
index.html not as literally an HTML page anymore, but more as
a template in the literal sense. So a template is kind of
like a blueprint whereby you can construct most of what
you want the human to see but then leave little placeholders
in, a la a blueprint where you can fill in certain blanks. The double curly quotes
here is actually a feature of technically another
language-- it's not a programming language-- called Jinja. But Jinja is simply a language
that a bunch of other humans came up with that
standardizes what syntax you can use for these placeholders
and some other features as well. So this is going to happen more
and more as you progress more in programming and CS. It's not going to be as simple as, oh,
I'm implementing something in Python. Or, oh, I'm implementing something
in C. It's generally going to be, oh, I'm implementing something
with this full stack of software, including HTML, CSS, Python, some
SQL, some Jinja, and so forth. So into your vocabulary is now going to
generally come a list of technologies that you're using when
solving some problem, no longer individual languages. So, by this, I just mean this. The Flask framework took a look
around the internet and saw, OK, the humans at the
Jinja group came up with a nice simple syntax
for putting placeholders in. Let's support that syntax in Flask. So it's sort of one framework
collaborating with another. So if I go back to app.py now, how do
I actually pass from my application to that template whatever
the human has typed in? Well, it turns out I can
go ahead and do this. Let me go ahead and in my
index function, which, again, is what's going to get called anytime
someone visits that slash route, I'm going to go ahead and
create a variable called name. I'm going to set it
equal to requests.args. And then I'm going to go ahead and
say, how about, quote, unquote, "name". I claimed, a moment ago, that
args is a dictionary that just comes automatically
with Flask and whenever a human makes a request
to the server, and it puts in that dictionary all of
the key value pairs from the URL. And the last thing I'm
going to do here is this. I'm going to actually say--
and, actually, just let me make this more explicit. Let me call this placeholder
literally placeholder. And what I'm going to do
now is, in render template, I'm going to take advantage of one other
feature that comes with this function. It can take one or more arguments. And if you pass in more,
you can specify variables that you want the function
to have access to. So I can literally do something
like this, placeholder equals name. So recall that Python supports
named parameters, which just means that you can pass in
multiple arguments to a function. But you can specify them by name. So I am calling one of
these arguments placeholder. And I'm setting the
value of that argument equal to name, which
itself is a variable that I defined just a moment ago. So, now, what's going to happen? Well, let me actually
go back to my VS Code. I'm going to go ahead and
run Flask as I did before. The URL is not going
to change in this case, I'm going to go back to my other tab. I'm going to go ahead now and change
the URL manually-- let me zoom in here-- to be /?name=David. I'm not going to hit Enter yet. Let me zoom out. But, when I do zoom out here, I think
we should see now, hello, David. So here we go. Enter. And, voila, we see hello, David. But, more interestingly,
if I view source here by right-clicking or
Control-clicking on the page or opening developer tools and so forth
and go to View page source, it appears that what the
server sent to my browser is literally a web page
that says hello, David. There is no more placeholder. There is no more curly braces. Literally, the content that came
from the server is that string. And so this is the
distinction now between being a static application versus dynamic. What I wrote statically was
literally this index.html file. But what got served
dynamically is that file plus the substitution or interpolation
of that placeholder variable. So we have the beginnings, it
would seem, of a web application. And think back to Google. Google is essentially implemented
the same way, /search?q=cats. So they're doing more with the key value
pair than just spitting it back out, but we have the beginnings
now of a dynamic application. Any questions on any of this
code or this framework thus far? Any questions thus far. No, all right, well,
let's see what happens if I don't cooperate like a human. Let me actually go ahead and get rid
of that parameter, hit Enter again, and I actually now
got an HTTP 400 error. So this actually seems bad. And it's a little subtle, but if I zoom
into the tab here, it indeed says 400. That's one of the HTTP status
codes that you generally shouldn't see unless something goes wrong. 200 meant OK. 404 meant file not found. 400 means that something went wrong. I guess I didn't pass in a
name as I was supposed to. But that's only because I was sort
of blindly expecting this placeholder to exist. So let me be a little smarter and code a
little more defensively now as follows. Let me say this. How about if there is a name
parameter in the requests arguments, then go ahead and create
a variable called name, set it equal to request.args,
quote, unquote, "name". So treat it as a
dictionary with that key. Else, if there is no
name in the URL, let's just default this variable to
being something sensible like, quote, unquote, "world". So, now, let's proactively, using
some sort of "week one style" conditional code, albeit in
Python now from week six, let's just check is name in
the URL, if so grab its value. Otherwise, default to world instead. So I'm still going to
leave this code as is, passing in the placeholder for this
template to get plugged in here. But, now, if I go back to the browser
and I just reload without passing in name=David or anything else,
now we have a sensible default. And if I go back to my View source tab
and reload, I'll see that I have hello, world in this case. However, if I go back up to that URL
and do /?name=David, now we have David. If I change the URL to be
name=Carter, now we have Carter. So, indeed, we do have the beginnings
of something that's more dynamic. Of course, this is a
little tedious to have to write out this if and this else. There's ways to condense this code to
be a little tighter and a little faster to actually implement. And, in fact, let me go
ahead and propose that. We just do this. Instead of treating
args as a dictionary as we did with square brackets--
which can cause problems if that key does not exist. In fact, let me go back to that version. Let me undo, undo, undo,
whereby I'm just blindly going into request.args to get name. In fact, instead of just blindly
indexing into this dictionary called args, which turns
out we can do this instead. Let me go ahead and
say request.args.get, which is a function that
comes with a dictionary, and I can specify the name of
the key that I want to get. And, by default, if there is no
key called name in a dictionary, you're going to get back
a default value of none, which is kind of like
Python's equivalent of null, but it's none, capital N, in Python. But if you want to give
it a different default, it's handy to know
that this get function, which you can use with
dictionaries in general can take a second argument,
which will be the default value that you do get back if, in
fact, there is no such key called name. So what this means is I can actually
now keep all of the code the same, but it's a little tighter. There's no if or else. I can go back to my other
browser window, click reload, and it still works for Carter. But if I get rid of that,
I can now have hello, world still working just as before. And just to add one more potential
point of confusion to the mix, it's a little dopey to say placeholder
literally in your template, especially if you're going to be using
multiple pairs of curly braces for one variable or another or another. So better style would
be to actually call the variable what makes sense for
what it is you're plugging in. So hello, name, with the
name in curly braces. This is-- I show this, though,
because it gets a little confusing if your variable's called
name, and that's still going to be the value you pass in. You're going to very often
see in the world of Flask this convention, where you literally
write something equals something where the names there are exactly the same. And the only thing to keep in
mind here is that the name-- this is the name of this parameter. This is the value of this parameter. The fact that everything seems
to be called name in this program is because these technical terms
are colliding with the English word that you and I know as name for my
name, Carter's name, and so forth. But get past that only because it
will be very common to literally see something equals something,
where just for visual convenience the variable's name is exactly the
value that you want to pass in. So that too here is conventional. All right, a little cryptic. But common boilerplate that you'll
start to see again and again. Any questions now about this? No? OK, so let's make things a little
more interesting and representative of a real-world app. Let me propose that, now,
we go about implementing maybe a second template altogether. In fact, let me go ahead and do this. It'd be nice if the human doesn't need
to be technologically savvy enough to say that, oh, if you want
to be greeted by this website, you have to literally change the
URL yourself, type in name equals-- no one does that. That's just not how the web
works in terms of user interface, but that is how browsers
and servers do work. But, of course, on the web,
we almost always use forms. So let me go ahead and do this. Let me go into index.html, and let
me get rid of just this hello, body. And, instead, let me
actually create an HTML form. This form is going to use the
get method if only so that we can see what's going on inside of the URL. This form is going to have an input
where I'm going to turn autocomplete off, just like last week. I'm going to do auto focus just to move
the cursor there nicely by default. Somewhat confusingly, I'm going
to give this input a name of name because I want Carter's name, my
name, or someone else's human name. But I'm going to give
it placeholder text of, quote, unquote, "Name",
capitalized, just to be grammatically clear as to
what we're prompting the user for. And the type of this
field is going to be text. Although, that's the implied
default if I don't give it a type. I'm going to lastly have a button
in this form, the type of which is submit so that the browser
knows to submit this form. And the label I'm going to
put on this button is Greet. So I'm going to type in
my name, click Greet. And I want to see hello,
David or the like. But I need to specify
the action for this form. And recall that, when we implemented
"Google", quote, unquote, we did a little something like this. Https://www.google.com/search,
well, we're not going to punt to Google today. We are implementing
our own applications. So if this were a search application,
I could literally have an action of /search, but let's do something
a little more semantically sensible. Let's create our brand
new route called /greet. This is not the name of a folder. It's not the name of a file. It's more generically a path or a route
that is now up to me to implement. If I go back, though, to this
application and reload this page, notice that I have the beginnings
of a more user-friendly form that's asking me for this name. However, if I do type in
David and click Greet-- I'll zoom in just a moment-- notice that the URL does change to
/greet?name=David just like google.com works. But, of course, we're getting
a 404 not found because I haven't implemented this route yet. So let me zoom out. Let me go back to VS Code. Let me open app.py and make a
little bit of a change there. Let me make a little bit of a
change and say this in app.py. In app.py, instead of just getting
the user's name and this default, let's simplify the index route and
just have it sole purpose in life be to render index.html, the
thing that contains the form. I'm going to now, though, create a
second route, so app.route, quote, unquote, "/greet". And I could call this
route anything I want. But greet seems sensible. I'm going to call the function
below it anything I want. But, just to keep myself sane, I'm going
to call it the same thing as the route even though that's
not strictly required. And then, in this route, I'm
going to go ahead and do this. I'm going to create a variable called
name, set it equal to request.args.get, quote, unquote, "name", then,
quote, unquote, "world", so the exact same line as before. And then I'm going to return
render_template, which is the function that comes with Flask. I'm going to specify this time, though,
render a template called greet.html-- which doesn't exist yet, but that's not
going to be a hard problem to solve-- and pass in that variable. So the last thing I need to do is this. And I'm going to cheat
and copy and, in a moment, paste the contents of index.html into a
new file called greet.html as follows. Let me open up VS Code
here in my other terminal. Let me go ahead and write
code templates/greet.html. Notice that I'm making sure to put
the new file in the templates folder. Or I could cd into it and
then run the code command. That's going to give me a new file. I'm going to hide my
terminal, paste that code, and I'm going to get rid of the form. And, frankly, I should've just
copied and pasted this earlier because the only thing I'm going
to put in greet.html is hello and then, in curly braces,
my placeholder, which we started to call name a moment ago. So, to recap if I go into my
terminal again, if I type ls, I've still got app.py. I've still got templates. But if I look inside of templates now,
I've got two templates-- index.html and greet.html. index.html is the thing
you see when you visit my website. greet.html is the thing you see when
you submit that form, it would seem. So, indeed, if I go back to
my browser and hit back-- so I get back to that form. For good measure, I'm
going to reload because I want to make sure I have the
latest version of everything. I'm going to now try
typing my name David. I'll zoom in. You'll see that the URL will again
change to /greet with the question mark and my name. But, hopefully, we now
indeed don't see a 404 because the new route actually exists. And if I zoom out,
right-click or Control-click and go to View page
source, you still see what appears to be a HTML file just
for me even though it was dynamically generated instead. All right, if you're on board that
this seems to be a correct application insofar as it does
what I wanted it to do, let's critique the design as
we've been in the habit of doing. I've now got three files, app.py,
greet.html, and index.html. What might you not like about the
design of this web application even if you've never
done this stuff before? Yeah. AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Yeah, greet and
index.html have the same contents, except for that one or few
lines in the middle of the body. I mean, I literally copied
and pasted, which, generally, even though I do it sometimes
in class to save time, if I end up with the
same code in my files, that's probably cutting some
corner and not the best design. Why? Well, what if I want to go in and
change the title of this application from hello to something else. It's not a huge deal. But I have to change it in two places. What if I've got some
pretty CSS that I've added? And so I've got some
CSS up here in one file. I need to copy it into another
file, change it both places. Generally, having duplication
of anything is bad design. So it turns out, there
is a way to solve this. And this is one of the
features that you really start to get from a web framework,
be it Flask or anything else. You get solutions to these problems. So what I'm going to do now is this. I'm going to create a third and
final file for this application by starting by copying
what I have already. Let me go back to my
terminal window here. And let me create a third template
in the templates folder called layout.html. It doesn't have to be called
that, but that's the convention. So I'll always do that here. And, when I create this
file and hide my terminal, I'm going to go ahead and
copy-paste all of that content. But I'm going to go inside of the
body of this file, called layout.html, which is otherwise identical
across all of my files. And what I'm going to do is
use slightly weird syntax. This is more of that Jinja syntax
that some other humans came up with years ago. And I'm going to do this. Single curly brace and a percent sign. I'm going to specify the word block and
then any name I want for this block. And, by convention, I'm
going to keep it simple and just use the exact same
thing as the name of the tag that I'm inside, so block body. And then I'm going to put a percent
sign just before the close curly brace. I don't need anything inside of this. So this too's going to
look weird at first glance. But it's a convention. I'm going to do another curly
brace with the percent sign and then literally the
word endblock, no space. And I'm going to open and
close what isn't an HTML tag. It's a Jinja tag, if you will. So, again, you see yet more
evidence of reasonable humans in the world kind of
disagreeing on syntax or at least using syntax
that's similar in spirit but doesn't clash with the syntax, the
angled brackets that HTML already uses. Long story short, this
is a way of specifying that you want a placeholder, not
just for a single variable's value but for a whole block of code. Maybe it's simply a sentence. Maybe it's a whole-- a
web form element or more. This is a placeholder
now for a block of code. And the way I can do this-- or
the way I can use this template-- and this is where template now
is getting all the more literal in the sense of what templates do. I'm going to go ahead and do this. I'm going to go into my two
other files, like greet.html. The only line that's different
in this file vis-a-vis index.html is which line number? 9 is the only line that is unique. So what I'm going to do is this. I'm going to highlight that and copy it. And then I'm going to delete
everything else in this file because it's just redundant. Everything I need is in layout.html. At the top of this file, I'm going to
use another curly brace and a percent sign, but I'm going to
use a special keyword that comes with Jinja called extends. And I'm going to specify in quotes
here the name of the template that I want to extend, so to speak. So this is an example of what's in
computer science known as inheritance. I want to take everything from
that layout and inherit from it all of its lines but
plug in some of my own, sort of from a
parent-child relationship. Inside of this file,
now, I'm going to specify that the custom body that I want is
this block body just like before. And then, down here, I'm going
to preemptively say endblock just to finish my thought in advance. And then, inside of this block body, I'm
going to simply paste that line of code that I Stole from the original version. So I'll concede that
this is pretty ugly. I've added three cryptic-looking
lines, all of which relate to Jinja
templating, again, syntax that humans invented to give you
the ability to write templates, or blueprints. But the point is that this
single line, now line 5, is going to get plugged into that
template, called layout.html, wherever that body block is meant to go. Lastly, I'm going to
go ahead and do this. The only lines in index.html that are
unique are these here, 9, 10, 11, 12. So I'm going to highlight those
and delete everything else. And then I'm going to do the exact same
thing, extends layout.html at the top of this file, then,
below that, block body. Inside of the block body, I'm going
to then say endblock at the end. And, in the middle of that, I'm
going to paste those lines of code. Just stylistically, I'm going to indent
them just so I'm super clear visually on what is inside of what. But that's it. So ugly? Yes, but, as soon as your web
pages get longer and longer, this ends up being a drop in the bucket. It's three ugly-looking lines
relative to a lot of HTML that you might be plugging in and
customizing for your application. So now index.html looks like this. greet.html looks like this. And the only way they differ is the
actual contents of that block of code. layout.html is the main
blueprint that's going to govern what the whole website looks like. I can change the title in one place. I can add some pretty CSS
in one place and so forth. It's going to apply to
each of those files. And, now, somewhat
underwhelmingly perhaps, if I go back to this
application and I click reload, nothing is different
because it still just works. But I've made arguably a
better design because now, when I change things to Carter
here or I get rid of it altogether and just visit the default-- rather, if I just visit slash
there, I'll get the form. I've at least handled
the situation where-- I've eliminated the situation
where I've just copied and pasted the same boilerplate code. So odds are someone like Google
is doing something like this. It's probably fancier
certainly than this example. But any time you search for something on
Google, generally, the top of the page looks the same. Maybe the bottom of the
page looks the same. There's maybe some
ads always at the top. And then there's 10 search results. So, probably, what they've done is they
have some template that looks roughly like this with all of
the boilerplate stuff that they want every human to see
on every page of search results. And then they're just somehow
customizing the block-- a block of code somewhere
there in the middle. All right, questions on any of
this actual templating technique? Anything at all? All right, how about another
question about design? If I go back to this URL here and
I search for something like David, it's not that big a deal
that it ends up in the URL. And, in fact, what's nice about
HTTP parameters ending up in the URL is that URLs are therefore stateful. If you copy this URL and
paste it into an email, assuming the web server is still up and
running at that URL, it will just work. And the human to whom
you send that link, they will see David or
Carter or whatever name's actually in that form, which
may be as useful behavior. Not so much for this
application, but imagine now that you want to send someone a
link of Google search results. It's a good thing that Google puts
q=cats or dogs or birds or whatever in the URL because then
the URL itself is stateful. What you see is what
the recipient will see because all of the inputs of the
server that's requisite is in that URL. But suppose that this
form field, if I go back, wasn't asking for my name but my credit
card number or my password up here. That should start to rub
you the wrong way because it feels like no good will come from
exposing private information in the URL because if you have a nosy
sibling look over your shoulder. There it is in your search history. A roommate goes through your
autocomplete and finds the data there. Or if you do, for whatever
reason, copy-paste it, you're accidentally including
private information in these URLs. So I said last week that there is
an alternative to sending things in the URL and that
alternative is to use something that's not called get but
a verb in the world of HTTP that's called post instead. And it's actually a
relatively simple change. If I go into index.html, I can simply
change the method from get to post. Get is the default.
Post is an alternative. Even though, in some contexts,
you'll see capitals, in HTML, it should be lowercase, another example
of left hand not talking to right. But, in this case, if I go now
to my other tab with the browser, reload the page because I want to
get the latest version of the form, if I now type David-- and I'll zoom in-- before hitting
Enter, if you watch the URL now, you should not see that
?name=David is up there, nor would be your credit
card or your password. Unfortunately, we're
seeing another HTTP status code we haven't seen yet,
405, Method Not Allowed. Well, why is that? That's because now that I
fully control the web server, I need to tell the web server that
I do want to support not just get which is the default but post as well. The method the user is
using is not supported. So this is an easy fix
even though it's going to look a little cryptic at first. If you want your greet method to
support not just get but post, you can specify another
argument to this route function. So the default is literally this,
methods= and then in square brackets, quote, unquote, "GET". So what is this? Methods is apparently a named argument
being passed into the route function. I claim its default value is this. What do the square brackets
indicate in Python? Not a dictionary. Square brackets. A list, so it's a list of
strings or strs in this case. This is the implicit default. So you don't have to type this. It's just what works out
of the box automatically. But if you want to change
this from get to post, you have to include methods
equals a list of the methods that you do want to support. For another time, there's
other HTTP methods. There's delete. There's put. Those are the two biggies
that you might use as well. Those are generally not supported
as easily in the world of browsers, but get and post certainly are. If you wanted to support
both for whatever reason, you can literally have a comma
separated list of those methods instead. But we don't really need
both for privacy's sake. I claim I'm only going to use post now. So now if I go back to
my other tab, go back to the form, reload to make
sure everything is as expected, and now type in David and zoom in,
you won't see my name in the URL. But you will-- or you won't see
it-- oh, good, not intended. But nor will you see it even
in the body of the web page. So it's super secure. Why? I screwed up, but why? Yes. AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Yes, so good intuition. Even if you knew that before, you
might think through rationally, how might this be-- why might this be behaving this way? Well, if I go into app.py, it seems
that if world is the value of the name placeholder, well, it must be
the case that there is no name key in request.args in this case. However, there's an
alternative to request.args, and it's called request.form. This is another example of visible and
hidden being opposites of one another, request.args and
request.form, at least for me, are not obvious mappings to
GET and POST, respectively. But that's what the Flask folks did. And so the simple fix now,
if I go back to VS Code, is to change request.args
to request.form if you want to use post instead of get. This is a weird misnomer because
they're both coming from forms, whether you're using GET or POST. But this is what some folks decided. So let me go back to my browser, go
back to the original form, reload to make sure I get the fresh
HTML, type in my name now, David, zoom in, and click Greet. And, this time, you won't
see my name in the URL, but you should see it
in the body of the page. So we've achieved some form
of privacy, if you will. Better applied to things like credit
card numbers, passwords, and the like. Phew, other questions? On any of this thus far? Anything yet? No, all right, yes, in the middle. AUDIENCE: [INAUDIBLE] post and
get, the request [INAUDIBLE]?? DAVID J. MALAN: A good question. To repeat if you were
supporting both GET and POST, should we have a second line
that's also checking request.args? Yes, if you were. I, though, decided, at the last
minute, only to support POST not GET. So I don't have to bother with that. But your question's a perfect segue to a
final example of this Hello application where you can actually consolidate
different types of functionality into individual routes. Why? Well, at the moment, this
application is super simple. It's literally got one form
and then one resulting page. But it's implemented, therefore, with
a pair of routes, a pair of functions. No big deal for small applications. But if you imagine a more
complicated application, be it Google or anything else
that has many different web forms on different pages,
it's a little annoying if every form needs to separate
routes if only because you now have to keep track of literally
twice as many functions. Your colleagues, your
teaching fellow needs to know which one is related to which. So there's something
to be said design-wise about consolidating related
functionality into one single route so that everything is together. Well, we can achieve that
relatively simply as follows. So let me go ahead and completely
eliminate this greet route and simply have everything exist in the /route. And I'm going to go ahead and highlight
and cut these lines out of there altogether. But if I want my single /route
to support multiple methods, I indeed need to use methods equals and
then, in square brackets, GET and POST. Order doesn't matter. But I'll keep them
alphabetical in this case. Inside of my index route, I need to
in advance is the user visiting me via GET or POST? Because if it's via GET, I
want them to see the form. If it's via POST, I want to
process, the form, that is, do something with the user's input. So it turns out it's relatively simple. If request.method equals equals
"POST", then I can do the following. So you can literally check the request
object, which comes with Flask, to figure out, was the word GET or the
word POST in that virtual envelope? And, depending on the answer,
you can do something like this. I can paste those lines
from earlier, whereby I get the variable name from request.form. And then I render the template
greet.html, passing in that name. Otherwise, you know what? I could just do else,
return the template itself. So if the method is POST, go ahead and
process the form just as we did before. Else, go ahead and just render the
index template which contains the form. Strictly speaking, I
don't even need the else. I can get rid of that, just to
tighten this up a little bit, and unindent my last line. Why? Because recall that, from C, from
Python, as soon as you return a value, nothing in that function is
going to get executed thereafter. So you might as well kind
of tighten up the code so that you don't bother adding
undue indentation if not needed. So notice, now, if I go back
to my browser, reload here, it's not going to work yet. But let's see if you
can diagnose the issue. If I type in David here
and click Greet, now I'm back to getting a 404 but
for different reasons. AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Good, I haven't
changed-- not the method. But I haven't changed the
action in the form itself. So if I go back to VS Code here
and I go into the web forms, the HTML, POST is still fine. But there is no /greet route anymore. So I actually can just specify slash. Or it turns out if you omit that
altogether, the form will assume that you want to submit it to
the very route from which you came so that is fine as well. I'm going to go ahead now and go
back to that other tab and go back. I'm going to reload the page. And, just for good
measure, this time, I'm going to Control-click or
right-click View page source. And, here, yep, the
action has indeed updated. So I think I fixed the bug. Now if I type in David and click greet,
we're back in business with it working. So notice that this still
allows me the convenience of having two separate templates,
one for the form which shows the-- which collects the user input
and one for the actual greeting which displays the user input. So I'd argue that it still makes
sense to keep those separate. But I can avoid bloating
my app.py by having two methods for every single feature
that I might want to implement. Now, there is still a bug
in this implementation even though it's a little bit subtle. So recall that, previously, we
introduced this default value of world just in case the form doesn't
actually contain the word world as might've happened if I didn't-- if
I [INAUDIBLE] into the URL that I was requesting manually as I did before. But it turns out that if you're
using an actual form and not, of course, expecting the human to
type anything into the URL bar, which no human would do, it turns
out that the browser is still going to submit a name parameter
even if its value is blank, that is, empty, the
so-called empty string. And so even if it's
the empty string, it's still going to be
considered to be a value and, therefore, not worthy of having
the default value of world plugged in. In other words, if I open up my
terminal window here, rerun flask run, and go back over to my browser, and
load this example, if I type in David, as before, I'm going to be
greeted with hello, David. But if I try this again and don't
provide an actual name but just click Greet, it turns out the
name parameter's still going to be submitted to the server,
in which case request.form.get is not going to rely on the default value
but rather that empty string value. And so we see what appears to be a bit
of an aesthetic bug hello, nothing. So how can we go about fixing this? Well, perhaps the simplest way is
to no longer rely on this default value here inside of app.py. So, in fact, let me go ahead and
delete that default value altogether and pass name in as the variable it
still is into greet.html, our template. But, in greet.html,
let's add a bit of logic there whereby we conditionally display
the name if and only if it's not empty. In other words, before I output blindly
name inside of these curly braces, let me borrow some syntax from Python
and actually use, within my Jinja template, a conditional like this. Open curly brace and then a
percent sign because, this time, I want logic, not just
interpolation of a variable. And I'm going to say if name. And then I'm going to do another
percent sign and a single curly brace. And then, after that, I'm going
to still use my variable name name inside of two curly braces. But, after that, I'm going to do again
a single curly brace, a single percent sign, and then I'm going to say else
followed by one more percent sign. And then, after that, I'm going to go
ahead and actually put my default value world and then close this if
conditional with a single curly brace, a single percent sign, and endif. And then I'm going to go ahead
and close that tag there. So, in Jinja, it turns out that we
can use it not only to plug in values. We can also do a bit of
lightweight conditional logic using an if and an else and an
endif in this case, which isn't quite like Python-- indeed
the endif is a little bit different. But this is particular
now to the Jinja template. And I've done it all on
one line just because this is a fairly bit-sized conditional,
either print out the name or print out world. Otherwise, I could actually put these
template tags on their own lines in order to spread
things out all the more. We'll see now, before
long, that there's actually some other control flow capabilities
of Jinja including loops and more. But, for now, this is a nice way to
solve that one problem because now, when I go back into my application
and I go back to the form and type in D-A-V-I-D, it's still going to
work as expected, hello, David. But if I go back one final time,
type nothing in thereby sending an empty value to the server and click
Greet here to demonstrate as much, now we do, in fact, see hello, world. All right, any questions on this
final example of just saying hello? From those basics come pretty much
all of dynamic web applications today. No? All right, so if you'll indulge me,
here's an actual web application that I made back in the day. So, when I was a sophomore, I
think I was not very athletic, so I didn't so much do freshman
intramural sports as I did run them with a roommate of mine. So we were sophomores in Mather House. He was the athlete. I was the aspiring computer scientist. And so this was actually a screenshot
of the very first web application I ever made. And this will sound old too. But, back in my day,
freshman year, when we registered for Frosh IMs, or
Freshman Intramural Sports, you would literally
walk across Harvard yard to Wigglesworth, where a certain proctor
or RA lived who was running Frosh IMs. And you would literally
slide a sheet of paper under the door with your name
on it and your choice of sports that you want to register for. So that was the state
of the art in 1995. This was ripe for disruption
as people would now say. And, once I actually took CS50 in
the fall of 1996, which did not teach, funny enough, web
programming at the time, I think I spent that winter
or spring figuring out how to do stuff with web programming,
not using C and not even using Python. At the time, I was using a language
called Perl, which is still with us but not as popular as
it was back in the day. But what you're seeing here
is a hideous screenshot of what the user interface was. This was me learning how to repeat
background in images infinitely, no matter how big the page was. Back in the day, there was no
CSS, I think, even at the time. So every one of these menu
options was actually an image. And even though-- this is a
screenshot, so it's not animated. If you would hover over
any of these words, what I would do using JavaScript,
which did exist in an early form, was just change the image from
a blue image to a red image, creating the illusion of the trickery
we did last week with text decoration, as you might recall in hover. So the web's come a long way. But this is still representative,
amazingly, some 20 years later of how web applications still work. I used a different language. I used a different backend
for my data or database. But everything I did then we
will now do effectively today and beyond because the
principles have not changed. It's all based ultimately
on HTTP and all of the stuff we discussed thus far this
past week and now this. So let's go ahead and make the
beginnings of this website, though, perhaps without as many of
the hideous images underneath it. In my VS Code, I'm going to go ahead
and close all of my prior tabs. I'll open up my terminal, and
I'll hit Control-c to exit out of Flask just like you can hit Control-c
to exit out of the HTTP server. I'm going to go ahead and hit cd
to go back to my main workspace. And I'm going to create a new
folder with mkdir called froshims so that all of my new application
is inside of this folder. I'm going to cd into froshims. And let's go ahead and make
a very simple application that essentially pretends to let
first years register for a sport. So I'm going to need to do
a bit of typing up front. But I'll do the first one from scratch. And then we'll start just
evolving that same example. Let me go ahead and do this. Let me go ahead and-- actually, we'll do this. We'll cut one corner. I'm going to go ahead and copy, from my
hello example, app.py into this folder. I'm going to go ahead and
copy from my hello examples templates my layout into this folder. I'm going to create a new
folder called templates. I'm going to move that
copied layout into templates so that, at this point in the story,
if I clear my screen and type ls, I've got the beginnings
of a web application, even though it's specific
to just saying hello. But I'm going to go ahead
and into the templates folder and go into layout.html. Let's just change this ever so
slightly to say froshims as the title just so we know we're looking
at the right application. And, now, let me go ahead and
create a new file called how about index.html inside
of templates that, just as before, is going to extend that
there template, so extends layout.html. Inside of here, I'm going to
say block body just as before. Preemptively going to say endblock. And then, inside of
here, I'm going to make the beginnings of a super simple
web page for first-year intramural. So I'm going to use an h1 tag
that's sort of big and bold that just says register at the top of
the page sort of like a title. Below that, I'm going to have a form. The action of this form I'm going
to say proactively is going to say to /register. So that's a to do. We're going to have to go
implement a register route. The method I'm going to use is
post just for privacy's sake so that if roommates are
sharing the same computer, they don't see, in the autocomplete,
who's registered for what. Inside of that form, I'm going to
have a single input first where autocomplete is off. Autofocus is on. The name of this field
will be name because I want to ask the humans for their human name. The placeholder, just
to be self-describing, is going to be, quote, unquote,
"Name", capital N grammatically. And then, lastly, the type of this
field, though it's the default, is text. So, so far, this is actually pretty
darn similar to the hello example soliciting someone's name. But now I want to maybe
implement a dropdown menu via which you can select a sport. And, back in the day, I think
the first version of froshims, students could only register
for basketball, soccer, and ultimate Frisbee. So those were three of the fall sports. So let me do this. It's a little weirdly named,
but a dropdown menu in HTML is called a select menu because
you select something from it. The name of this input, which is really
what it is, is going to be sport. Though, I could call the
input anything I want. And, inside of this select element,
I'm going to have a few options. I'm going to have one where the
option is how about basketball? Another option, the
value of which is soccer. And, lastly, a third option, the
value of which is ultimate Frisbee. So just those three sports. But suffice it to say
we could add even more. And then, outside of
this select menu, I'm going to have a button just like
the hello example, the type of which is submit, just to be super
explicit even though that's not strictly necessary. But it's another attribute
you'll see in the wild. And then the name on the value
of this button will be register. So it's clear that
you're not being greeted, but you're actually
registering for sports. Now, we're not quite good to go yet,
but let me go into VS code's terminal again. Let me open up app.py and
close my terminal again. And let's just whittle this
down to something super simple. I don't want to get
overwhelmed just yet. I don't want to support even POST. So let's just whittle this
down to the essence of this. So I can do a quick check
mentally and make sure now, when I run flask, that I'm
serving up that registration form. So, in my terminal, I'm going to
run flask run in my froshims folder. So far, so good. It's going to be by default the same
URL unless I've rebuilt or created a brand new codespace. So let me go back to my other
tab and reload that URL. And, OK, we've got the beginnings
of a more interesting form now. So it's got place for my name. It's got a dropdown
for the three sports. So let's see what happens,
D-A-V-I-D. We'll say soccer. And, when I click Register, just
to be clear, what route will I find myself at per my URL? Slash. What was it to be? If I go back into my index. /register. But what error will I see
presumably at this point in time, given that app.py has only been
implemented to this extent? So probably 404 because
the route won't be found. So if I click Register, I
indeed end up at /register. But if I zoom in up top
here, 404 not found. All right, so it's the
beginnings of an application. But I've not-- I've implemented
the front end, so to speak, the user interface but not the back
end, the business logic that actually does something with the user input. But a couple of enhancements here. But these are largely niceties in HTML. It's a little bad user
experience that by default you're registering for basketball. I mean, that's fine. But, arguably, you're biasing people
toward registering for basketball. Or they might not realize that they're
registering for basketball because they didn't explicitly choose a sport. So having a random, an
arbitrary default that just happens to be the
first word alphabetically is a little weak when
it comes to design. So there's different ways to fix this. But one way is to do this. Add a new option at the very top. But go ahead and disable it so
that the user can't themselves select it because you want
them to select an actual sport. By default, you can specify
that it's indeed selected. And it has no value. So not to judge any sport, but this
particular option has no value. But what the human sees is
the word sport, for instance. So this is kind of a hack. Ideally, the Select menu would
just have a placeholder attribute like the actual input boxes does. But that does not exist. So if I reload now, it looks
a little more user friendly. So it says sport. I can't select sport ever again. But it is the default, but I can
select one of these three sports which just increases the
probability that the human does what you might expect. Of course, there's something
else I can add here. Suppose I don't even give my name. It still went through. It didn't work. It's still a 405, but the-- 404. But the browser didn't stop me. So recall that we do
have some other tricks. For instance, I can say that
this dropdown, this select menu is itself required--
or, sorry, not this one. The text box is itself
required, for instance. So now if I go back
to the form and reload and I just ignore the name
question and click Register, the browser's going to yell at me. Now, recall that this is not robust. Client-side validation is not good. Why? What'd we learn last week? Yeah, I mean, I can literally
right-click or Control-click and open up Developer Tools. I can go into that form
using the Developer Tools. I can literally find the word
required, delete it, and voila. This form will now go
through because the browser's going to do what I change. So it's useful for user experience,
making just things a little prettier and faster to validate. But it's not going to be robust defense. All right, so let's go back now
to VS Code into my actual route and implement at least something
here that resembles registration. So I'm going to go into app.py. And, in app.py, let's
create this second route. So, at app.route, quote,
unquote, "/register" to match what is in my HTML. Let me define a function. I can call it anything I want. But, again, good convention to just
call it the same thing as the route name so you don't get out of sync. And then there's a couple of
things I might want to do. When you register for
this particular form, what are the two things that the
server should probably check for? What kind of logic should I have here? Yeah. AUDIENCE: [INAUDIBLE] at
anything for [INAUDIBLE].. DAVID J. MALAN: OK, so let's make
sure that the name is present and the sport is present, ideally. So let's actually validate the
user's input just like get int did back in week one. Just like get string, get
float, and all of those, they made sure that
you actually got input. So there's a bunch of
ways I can do this, but I'm going to go ahead and take
a relatively canonical approach. If not request.form.get,
quote, unquote, "name", I'm going to go ahead and then
return, how about let's just see, failure, quote, unquote, "failure"
just as a quick and dirty solution. So if it is not the case that there
is a value for the name field, just assume that there's a failure. So how can I test this? Let me go back to the other tab. Let me go ahead and not type
in my name and click Register. And notice-- well, OK, I need
to get rid of the required if I actually want to see
this thing go through. So you know what? Let's just change the template. Let's get rid of that so I
don't have to hack into it and delete things manually. So let me reload the form. Let me not type a name. Click register. And, oh, dang it. 405, Method Not Allowed. What's the fix for this in my app.py? What line number needs to change? Yeah, over there. AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Yeah, I need to allow
both or at least POST at this point. So I'll keep it more restrictive. So methods equals and then
in a list, quote, unquote, POST because that's what I'm using
in my template as the method. All right, let's try again. I'm going to go back. I'm going to not type a name,
and I'm going to click Register. OK, so we caught the fact that
the name was not provided. Let's now go back and try
again and actually cooperate. David, Register, OK, now
internal server error. So something's gone even worse here. And, unfortunately, you're
going to start to see this over the next couple of weeks. This is like Python and the web's
equivalent of segmentation fault. It's a different issue, but it's going
to hurt just the same, unfortunately. So let's go back to VS Code here. Nothing seems to have gone wrong, but
that's because I've hidden my terminal. Let me open my terminal
window, and, oh, OK, so it looks like I made a crazy
number of mistakes here somehow. But let me go ahead and focus on-- and the formatting's a
little weird for some reason. Here we go. It's a little cryptic at
first glance, but here's the most important line of output. The view function for, quote,
unquote, "Register" did not return a valid response. So you're not going to
see this one too often most likely unless you do what I did,
which was you didn't have an else. You didn't handle the
situation where there is a name and something should've come back. So maybe I could do this. By default, I could just say
something like success as a catch all even though I've not
done anything useful yet. Let me try this again. Let me go back. David is typed in. No sport, Register. OK, so now I'm making progress again. So just like week one stuff, I make
sure I'm always returning some value, whether it's success or
failure in this case. All right, let's do something a
little more interesting, though. I could do this. How about elif not
request.form.get sport. I could similarly return failure. But this is a little silly to have
two nearly identical conditionals. So, actually, let me
just tighten this up. Let me go ahead and, instead,
get rid of those two lines and maybe just do something like this
in Python or not request.form.get sport. This is maybe the tightest way just to
ask two questions that are essentially the same but for two different keys. But returning, quote, unquote,
"failure"'s a little weak. That's not a valid web page. It's literally the word failure. So maybe we do this, render_template,
quote, unquote, "failure.html". And you know what? Down here, render_template success.html. So we actually send the browser
a valid web page, not just a single English word. Of course, we're going
to need those templates. So let me go in and do
something like this. If I go into, how about,
my terminal window. I need another terminal because
Flask is still running in that one. Let me go into froshims and let me
do code of templates success.html. I'm going to save a few keystrokes and
copy-paste all that stuff from index. But I'm going to delete most of it. And I'm just going to keep
it super simple today. You are registered. And then-- well, really,
not really because we're not going to bother doing anything
yet with the user's input. Let me do something
similar now for failure. So code templates failure.html. I'm going to copy-paste the same thing. And now I'm going to say the
opposite, You are not registered. But I'm not going to be
very useful, and I'm not going to even yet tell the
user what they have done wrong. But at least now we have the
beginnings of a froshims app. So let me go back, reload everything. Let me not cooperate at
all and click Register. OK, so you are not registered
because of some failure. I'll type in my name. OK, let's at least do that much. I'm still not registered. Let's go back. Let's leave David and choose soccer. Now, OK, now you are registered. So I got the success template instead. All right, so that seems to be better
progress or at least the beginnings of an actually useful application. But let's actually do more validation. Why? Because notice what the
human could still do. Suppose that, out of
principle, you really want to register for a different sport. So you're not a fan of soccer. You want American football. So let's right-click or
Control-click on that. Choose Inspect. And you can even do this client side. Let me write click on the Select menu. In Chrome, let me select Edit as HTML. You can start adding any HTML you want. So let me add an option
football close option enter. And, aha, now you have to
support football as well. Of course, this is going to work
because if I type in David and football and Register even though I'm not
doing anything with the response, I got through that validation
filter because I was just checking that there's an actual value. So this is now no longer really correct
because some annoying first year who's just taken CS50 is now
going to do something like this to my web application. And we're going to have bogus
data in the database, ultimately. So how do you defend against this
properly when it really is that easy? And, honestly, as soon as you put
a web application on the internet, bad things will happen to it because
people with too much free time. So how do we defend against it? What would be a better approach? Yeah. AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Nice, so
add another conditional such that the only things allowed
are the sports we actually are offering this semester. And, in fact, you know what? We can take this one step further. The fact that I hardcoded into my form,
my select menu, those three sports-- it'd be nice to maybe factor
out those sports altogether so that I have one authoritative list
that's used for generating the form and also validating the user's input. So let me do this. In app.py, let me go in here. And I can put this, how about, the
top of my file, to be conventional. I'm going to create a global
variable called sports. By convention, in Python, I'm going to
make it all uppercase even though that doesn't mean anything functional. There's no const keyword in Python. So it's more on the honor system
that no one else should touch this. But, inside of my list
here, let's go ahead and do only the official
three, basketball, soccer, and ultimate Frisbee. So now I have a Python
list of values that it would be nice to use to
generate that other form. So this is maybe nonobvious. But I think it's just an
application of past ideas. What if I do this? What if I pass into
my index.html template a placeholder called sports
and set it equal to the value of that global variable sports. Now, I'm trying to
adhere to best practices. The placeholder is called
sports in lowercase. But the actual variable I
called all uppercase just to make clear that it's a constant
even though that's on the honor system. But this too is conventional. This is a Pythonic way or a
Flask-centric way to do this. But now, in index.html, this is
where Jinja gets interesting. This lightweight syntax
for using placeholders gets interesting because I can
now do something like this. I'm going to delete
all three of the sports but not the disabled option, which
is just the placeholder text, inside of this select menu. Now I'm going to do this. Just like Python, I'm
going to say for sport in sports using the curly brace
notation and the percent signs, which are Jinja specific even though Jinja
and Python use almost the same syntax. And that's one of the upsides of it. You're not learning two things. You're learning 1.1 new things. endfor, which looks stupid,
but this is a convention in a lot of languages to literally
say end and the name of the keyword that you are ending with no space. Inside of this Jinja loop, I'm going to
write an option element once, option. And then, inside of the
two option tags, I'm going to do my placeholder
syntax with two curly braces and just say sport like this. And if I now go back into my
browser tab and hit back here and I reload the page,
notice that I still have a dropdown that's still
automatically populated because indeed if I go to View page
source and look at the actual HTML, there's some extra weird
whitespace, but that's because I hit Enter in my template. And it's generating literally what
I put inside of that Jinja tag. It's generating that list of sports. And it turns out-- I'm going to do this
just to be thorough. It turns out that the option
element technically lets you specify a value for that sport. Often, they're one and the same. What the human sees is what
the value of the option is. It's kind of like the a href
thing in the world of URLs. But this is not going to
change the functionality. But it's going to do this. If I reload now and I View page
source, this is maybe a more common way to see options where, in
orange, in my browser, is what the server is going to receive. In white is what the
human's going to see. They don't have to be one and the
same for reasons we'll soon see. But what's nice now is
that if I do actually want to officially support American
football, I can go in here, add "football", quote,
unquote, to my list, go back to the form, reload, and voila. Now I have a list of all four. But I haven't done the second
side of what you proposed, which is actually validate those sports. So let me do that. Let me go over to app.py. And, in app.py-- and we'll no
longer support football there-- let's do this in my registration route. So, instead of just
checking, is there a value? And the whole point of using
not is kind of like in C where you use an exclamation
point to invert the meaning. So if it's empty but it's not, then
it's-- the whole value is true. Let's get rid of this line. And let's instead do
something like this. How about if not request.form.get name. So let's still just check for a name. Or request.form.get, quote, unquote,
"sport" is not in the sports list. Now go ahead and say there's a failure. So what does this mean? If I go back to the browser and
reload, I now see only three sports. And I think this will work, OK, David. We'll register, say, for soccer,
Register, and it seems to work. But if some hacker
comes along and really wants to register for American
football, I'll right-click there. I'll inspect this. I'm going to hack the form
and add a bogus option at the very end just for myself. And, down here, I'm going to say
option value equals, quote, unquote, "football". And then, inside of
the option, I'm going to say football just to be consistent
even though they're one and the same. Save that. Close the developer tools. Choose the hacked option. Register, but, no, we
caught it this time. So this is hugely important. And there are so many darn
websites in the real world where the programmers either
don't know or don't care to actually validate stuff server side. This is how servers
quite often get hacked. You might have client-side
validation using HTML or JavaScript. And it looks nice. It's immediate. It's very pretty and graphical. But if you're not also paranoically
checking on the server, this is indeed how servers get hacked. Or, at least in the best
case here, your data set is sort of polluted with sports that
you're not actually going to offer. So this is not a very
harmful attack, but it's representative of what kind of
actions can be taken on your server if you don't distrust the user. So, unfortunately, this
is kind of a negative day. Never, ever trust user input. We saw that already with
SQL and injection attacks. All right, any other questions? Any questions thus far on this? Otherwise, we'll add a bit
of spice in just a moment. No? All right, well, just to show
you an alternative to this, let me change the GUI, the
Graphical User Interface, slightly. Drop-down menus pretty compelling here. But there's other techniques. And we won't dwell on HTML tags,
which you can pick up largely online. But let me go into maybe
index.html just to show you one different approach here. And if you really like radio
buttons, the little circles that are mutually exclusive-- this is a
throwback to radios, before my time, in cars where, when you pushed
the button for one radio station, it would pop out the buttons
for another, essentially, for your favorite channels. Radio buttons are, by definition,
therefore, mutually exclusive. So if I want to see those radio
buttons and not a select menu, let me go into index.html. And, instead of this select menu,
let me actually delete that. And even though this isn't going
to be super pretty, let me do this. for sport in sports, just as
before, endfor, just preemptively. Inside of this Jinja loop,
I'm going to do this. I'm going to do an actual input tag. But it's not going to be text. But the name of this tag-- of this element is going to be sport. The type of this element is going
to be radio for radio buttons. And the value of this button is
going to be whatever that sport is. But what the human is going to see
next to the radio button to the right is the same thing,
the name of the sport. So this is going to
look a little different. And it is going to look ugly in my black
and white viewport here with no CSS. But it does speak to how you can
change the user interface just using different building blocks. Let me reload. And, OK, it's probably
not the right call here because it's just kind
of making things ugly. But it's as simple as that because if
I now click on this or this or this, they're indeed mutually exclusive. However, suppose that you want to allow
the particularly athletic first years to sign up for not one but
two sports or all three. In no case now can you
support that right now. The workaround now for
a bad website would be, oh, just go register twice,
or go register three times. It's not a huge deal
because you just hit back. And then you change the
dropdown and submit. You hit back you change
the dropdown and submit. But that's just bad design. Surely, we can do better than that. So, in fact, let's make one
change here and use checkboxes. And if you've never really thought
hard about this in the web, radio buttons and checkboxes
have this distinct property where the former is mutually
exclusive, and the latter is inclusive whereby you can check 0
or more of those boxes collectively. So if I actually just go
into that same template and change the type of this
input from radio to checkbox and then go back to
the browser and reload, you immediately get what you and I
see in the real world as checkboxes. And the upside of this is that you
can check now 0 or more of them. But the catch-- and this is subtle-- the catch with our code right now is
that we're only expecting one value. So it's a minor fix, but
it's a useful thing to know. If I go back to app.py, if I actually
want to get all of the sports from the users, I'm going to have
to change my validation slightly. So I'm going to do this. I'm going to check for the
presence of a name as before. But then I'm going to use a loop
to validate the sports because I don't want them to slip, like
football, back into the list even if it's not there. So I'm going to say this in Python. for each sport in request.form.getall. If you know it's a checkbox, you want to
get all of the checked values, not one, for the sport parameter,
then go ahead and do this. If the current sport is not
in that sports list up top, then go ahead and return
render_template failure.html. Did I make a mistake here? I think we're good there. So we're checking against every
value that was checked on the form. Is it actually valid? And so now if I go in here, reload,
type in my name David, and I'll just check one of them, for instance,
because I've not hacked the form and added something bogus like football. Maybe someone was alluding to this. I see now an error. So let's do this together. Not sure what I did wrong. I'm going to open up my
terminal and go to here. And, oh, interesting, my
spacing's a little weird here. But attribute error. Immutable dictionary
has no attribute getall. So this is me lying to you. I don't think so. But [INAUDIBLE], are you here? Did Flask change since I last did this? No. OK, so Flask post form getall. All right, here we go. About 2012, this is
probably out of date. But ah. You know, that's not a bad idea, OK. All right, OK, in Flask, how
do I get all of the values from an HTML input of type
checkbox from request.form? Well, this is horrifying. getlist! Damn it, OK. What a good duck. All right, so-- all right,
so we'll rewind in time. So thank you. [APPLAUSE] So that's a good lesson. Just do as I do. All right, so getlist will get
you a list of all of those values. So now if I go ahead
and register as David, click just soccer without
injecting something like American football
and Register, now I'm, in fact, registered but not
really, not really in the sense that we haven't actually
done anything with the data. So this is to say, ultimately, that
there's a lot of these building blocks, not only in HTML, which is mostly a
throwback to last week but also now, in Flask, where you can process
all of those building blocks and take control over
what up, until now, is usually the domain of Google or
the websites that you actually use. Now you actually have more of
the building blocks via which to implement these things yourself. So let's go ahead and add some
final features to froshims here where we're actually doing
something with the results. And, for this, I'm going to
open up a version in advance. So I'm going to go over to VS Code here. And let me go ahead and close these tabs
but go into my second terminal window. And I'm going to go into
today's src9 directory. And I'm going to go into
version 4 of froshims, which has everything we just did plus a bit more. In particular, I'm going
to go ahead and do this. I'm going to show you
app.py, which, additionally, has some comments throughout. But, in app.py, what you'll notice
is that, after all of my validation, I'm actually got a couple
of new features here. It's a little weak in terms of
UI to just tell the user failure. You are not registered. That's all my template previously did. But what if I borrow an idea from my
index template where all of this time, for hello and froshims,
I've been passing in input. So what if I do this? Let me show you. In templates, failure.html-- or, rather,
let's see, in templates, error.html. So notice this, I can
make the beginnings of a common format for an error page. So, in error.html of
this fourth example, I've just got some big, bold
error message at the top. But I have a paragraph
tag inside of which is a placeholder for an error message. And then I've gone one step further just
because and put a happy cat or grumpy cat as an image to let you down
easy that something has gone wrong. But this is like now every website where
there's generally some customized error message when something has
gone wrong or when you have not cooperated with the rules of the form. So what am I doing instead? Instead of rendering
failure.html very generically, I'm rendering this new
template error.html. And I'm passing in a custom message. Why? Because now, in my app.py,
my logic, I can actually say, you're missing your name. You're missing a sport. Or I can tell the human what the error,
which is much better user interface. Down here, though, on
this new line, here's where I'm now beginning to
actually register registrants. What's the easiest way to do this? Well, let me scroll to
the top of this file. And you'll see that, in addition,
to a big list of sports, I also have an empty dictionary
initially of registrants. Why? Well, dictionaries are this nice Swiss
army knife, key-value pair, key, value, key, value. Names could be keys. And maybe sports could
be values, at least if I'm supporting just single sports. So I could have a fancier
structure, but this seems sufficient, two columns, key,
value, for name, sport, name, sport, and so forth. So how do I put a person's name
into that global dictionary? Well, I'll use the syntax from
week six, registrants bracket name equals sport that associates
that value with that key. And, now, what you'll see in that
I've added a new route /registrants. And this is where
things get interesting. If I look at this premade
route as you will too, as you look at code that's been
written for you in the weeks to come, well, this sort of invites me
to look at registrants.html. Why? Apparently, this
registrants.html template is being passed this global dictionary. How might I use that? Well, let me go into VS Code's terminal. Let me take a look at registrants.html. And, interesting, we
haven't used this HTML much. I used it super briefly last week. This is an HTML table. It's not going to look
super pretty because I'm not using bootstrap or CSS more generally. But notice that, in the
table's head, there's name and sport from left to
right in the two columns. And then, in the table
body or tbody, notice that I have a whole bunch of tr, tr, tr,
one for every registrant in that Jinja loop. Each of the cells, the table
datas have the person's name. And then if you go inside of that
dictionary and look up the name, you get the value thereof,
so name, sport, name, sport. And the route, of course, again, is
just this, render registrants.html by passing in that dictionary. So what is registrants.html? It's just this. So I think if we go and run
this version of the application, we have some nice new features. Let me go ahead and do Flask-- let me kill Flask in the other window
just so it's not using the same port. Let me do flask run inside of froshims4. So far, so good. Let me go over to my other tab. Let me reload. So I get the latest HTML. I'm going to go ahead and
type in something like David but select no sport using radio buttons. So, again, you can only pick one. And now not only am I
seeing one grumpy cat there. It's also telling me at the
top that I'm missing the sport. Conversely, if I reload the
page, don't give my name. But do give the sport and register. Now you see that I'm
missing name and not sport. So, again, the UI is not very pretty,
but it has the building blocks of being much more appropriate. Let me now cooperate on both fronts. David wants to register
for soccer, Register. And now notice where I am. Apparently, I got redirected
to the registrants route, inside of which is
this two column table. It's not very interesting yet. So let me go back to the form. And let me register
Carter, for instance, for, say, basketball, Register. And now there's two of us. Let me actually go back to the form. And let me register Yulia for
ultimate Frisbee, Register. Now there's three of us. And, again, the CSS is ugly,
but I do have an HTML table. And if I right-click
and View page source, you'll see David, soccer; Carter,
basketball; Yulia, ultimate Frisbee all as tr, tr, tr. So, again, if you now think about
an app like Gmail in your inbox, odds are if your inbox
is indeed a big table, then it's probably tr, tr, tr, tr. And Google is rendering all
of that HTML dynamically based on all of the emails
in some variable somewhere. Well, let me go back here and
see, how did that redirect work? Let's watch this a little more slowly. Let me go up to the main form at slash. Let me type in David. Let me type in-- select soccer. And let me Zoom in to the URL. And notice that, when
I submit this form, even though the action is /register,
I'm indeed ending up at /registrants. So how is that actually happening? Well, let me go back
and do it one more time. But, this time, let me
open up Developer Tools. Let me go to the Network tab, which,
recall, we played with last week. And let me go ahead and do this again. So David, Soccer, and I'm
going to click Register. And now, notice, interesting, two
routes were actually involved. The first one here is Register. But notice if I go to
headers, ah, 302 found. 302 indicated some kind of redirect. What's the redirect going to? Well, if I look-- scroll down
here at response headers, there's a lot of stuff
that's not interesting, but location was the one we cared
about last week. /registrants, oh, that's why the second request over
here at left is actually /registrants. And it is 200 OK because it's
all of these basic building blocks from last week and now this. Where did that redirect come from? Well, now you have the
ability to do this. Notice that, in my register route,
the last thing I said we had done was add the name and the value
to this global dictionary. But the very last thing I did was
redirect the user to the /registrants route. What is redirect? Well, at the very top
of this file, notice that I proactively imported not just
flask, render_template, and request. I also imported redirect
this time, which is a function that comes with Flask
that automatically issues the HTTP 302 redirect for you without you having
to know anything about those numbers or otherwise. Let's do one final example
before we break for snacks. In this final example, froshims5,
let's actually do something with SQL. SQL, after all, allows us to persist
the data because this version here, with this global dictionary, what's the
downside of using this global variable to store all of our registrants? What's the downside? Yeah. AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Exactly, so,
as soon as the server quits or if something goes wrong
like maybe the power goes out, or we have multiple servers
or something like that, we'll lose the contents
of that dictionary. And so that's not really
good to store data that you care about in the
computer's memory alone or RAM. You want to store it on disk using
something like fopen and fwrite and all of the file I/O
stuff we talked about. But, in week seven,
recall, we introduced SQL. So that writes things
to disk in a .db file. So let's actually do that
with one final example. Let me go ahead and close
these tabs here in my terminal. Let me go ahead and close
the old version of froshims and go into froshims5 now. And, in this version, let me show
you, in app.py, the following. It's almost the same in terms of
what we're importing from Flask. But I'm also going to
import from CS50's library a SQL function, which we used
briefly when we wrote code in Python to talk to a SQLite database. This is the one example
of a CS50 training wheel that we actually do keep on
deliberately through the end of the term because it's actually
just really annoying to use most third-party libraries
with SQL in as user friendly a way. You're welcome to, but I do think
that, even though you shouldn't be using get in getstring, getfloat
anymore the SQL function's actually pretty darn useful, I would say. So how do we use this? Everything in this file so far is pretty
much the same except for that import, including these lines here. But notice that I am opening
up a file called froshims.db. And that's a database
that's empty initially. But it is in my account. So, actually, let me do this. Let me run sqlite3 on froshims.db. Let me increase the size of my terminal. Hit Enter. What can I type to see the
structure of this database? Sorry. Wait, what? AUDIENCE: [INAUDIBLE] DAVID J. MALAN: Oh, yes, thank you. .schema should show me. OK, it's actually a very simple
database, a registrants table with one, two, three columns, an ID
for a unique identifier, a primary key, the name of
the person, and the sport for which they're registering. And, presumably, the ID will be
automatically incremented for me. So let me exit out of that. Go back to app.py. And this line 8 here is just giving
me access to that SQLite database. And recall that the three
slashes are appropriate. It's not a typo relative
to something like a URL. Here is my three sports
that I want to support. Looks like my index route
is pretty much the same. So nothing new there. In fact, I'm using that
same lesson as before in passing in the whole sports list. Notice that, OK, this is interesting. Deregister, this version is going to
let users sort of bow out of a sport as tends to happen over
the course of a semester. But we'll come back to that. But let's look at register now. register is almost the same even
though I do have some comments here. We're making sure to validate the form. But this is where it gets interesting. I'm now inserting rows into the
database to register these registrants. Notice that I'm using CS50's library
to insert into the registrants table into these two columns name
and sport, these two values. And I'm being very careful to use
question marks to escape the user's input to avoid injection attacks. And then I just redirect the user. But what's going to be interesting
about this version is this too, /registrants no longer just uses Jinja
and iterates over a global variable. In this version, we're
selecting all of the registrants and getting back a list of dictionaries. And then we're passing
that list of dictionaries into the Jinja template
called registrants.html. So, just to make clear
what's going on there, let me open up templates
and registrants.html. It's almost the same as before. Notice that I'm using the dot notation
this time, which Jinja also supports. And it's almost always the same
as the square bracket notation. So you'll see both in
documentation online. But notice that I have a third
column in the registrants table that's a little interesting. And this will be the
final lesson for froshims. A button via which people can deregister
themselves, like a bow out of froshims. So let's do this. Open the terminal. Let's do flask run in
version 5 of this here. Let me go into my other tab, close
the Developer Tools, go to the /route, and I have a form quite like before. But now, when I register,
David for soccer and click Register, notice that it's ugly UI. But there's a button next to
David to deregister themselves. Let's go back to slash. Let me also register Carter, for
instance, for basketball and so forth. There's now two buttons. This, now, is what really ties
together our discussion of SQL and primary keys with
the world of the web. Suppose that there were two Davids
in the class, which there surely are, two Carters, two Yulias,
two of any names. We clearly can't rely
on first names alone to uniquely identify
humans in a room like this. So we probably should
use opaque identifiers, that is, those numbers, 1, 2, 3. Indeed, if I go into VS Code-- let me open another
terminal and make it bigger. And, in my src9 froshims version 5,
let me run sqlite3 of froshims.db. And, sure enough, if I do SELECT * FROM
registrants; I'll see the two of us thus far. And we've indeed been
automatically-- been assigned an auto-incrementing
primary key, 1, 2, respectively. That's useful now in the web especially
or user interfaces in general. If I view this page as
source, here in my browser, notice that both David and Carter
have their own form in a third td element next to them. And that's what gives us this. But notice that form, even
though it's an ugly UI, is a form that will post to a
/deregister route a hidden input, the name of which is ID to
match the primary key column, the value of which is 1
for me and 2 for Carter. So this is how you stitch
together a browser and a server. When there's a database
involved, you just uniquely identify the things you
care about by passing numbers around from browser to server and back. You might visually show David and
Soccer and Carter and Basketball. But the server only needs
the unique identifier. And that's why we dwelled
so much, in week seven, on these primary keys and,
in turn, foreign keys. So, when I go back to this form
here and click on deregister, this is going to submit ID equals 1 to
the /deregister route which should-- and this was the only route
we didn't look at earlier. Let me open up app.py again. You'll see that this
happens in deregister. In the deregister route,
which only supports POST, I'm going to get the ID from the form. If there is, in fact, an ID and
it wasn't missing for some reason, I'm going to execute
delete from registrants where ID equals question mark as a
placeholder, passing in that number. And then I'm just going to redirect
the user back to registrants so they can see who is
still actually registered. So if I go back to my browser
here and I deregister myself, we should see that now that's gone. And if I deregister
Carter, that's now gone. And if I indeed go back to VS Code, open
up my terminal window, make it bigger, run SELECT * FROM registrants, now
no one is registered for the sport. And so we've effectively stitched
all of these things together. So that's all how we
might implement froshims. Just so you've heard the
vocabulary, what we've implemented is a paradigm known MVC,
Model View Controller, where the view is everything the human
sees, the templates, the HTML, the CSS, the JavaScript. The controller is everything
that's in app.py, the logic that we've actually been implementing. But, as soon as you introduce
a database especially or even a global dictionary, then you
have the M in MVC, a model, which is where all of your data is stored. Now, you don't have to
think about it this way. But humans, over time, realized
that, wow, most of our web apps follow this similar paradigm. So they started thinking about
different components of the application as having these different identifiers. So there's still a lot more. We have not yet considered how,
when you log into a website, the website remembers
that you've logged in. We've not remembered how
you can keep track of what's inside of someone's shopping cart. This was a lot of effort
just for two-second joke. But let's go-- with that
said, for roll-ups and snacks as served, let's take a 10-minute break. We'll see you in 10 for
that and more as we wrap up. All right, we are back,
and let's consider now how web applications typically
work when you actually have to log into them, which is
most every web application nowadays. Somehow or other, even
though you only log in once, at least at the start of the day
or the start of the browser tab that you open, somehow
or other, websites are still able to remember
that you've logged in already. And that's how you see your Gmail inbox
or your social media feed or the like. So here, for instance, is a
representative login form. This one here for Gmail or
for all of Google services. And let's consider what actually
happens underneath the hood with respect to those virtual envelopes when you do
log in with your username and password to a site like this. Well, typically, inside
of the virtual envelope that your browser sends to Google
servers, that is, accounts.google.com, is a request maybe for that form. So GET slash HTTP version 2 or whatever
version your browser's actually working and some other headers dot, dot, dot. But, for the most part, that's
what we've seen thus far. When you then actually log in-- or, rather, when you visit
that page, hopefully, you get back a response from the server
saying that everything is OK. That is 200, OK. And the response that comes back
is text/html, so same as last week. This is just what's inside of those
virtual envelopes back and forth. But, when you log in to a
server, it turns out, typically, what's happening is that the
server is, unbeknownst to you, kind of stamping your hand once
it's verified your username and your password to remember
that you have logged in. In particular, what
Google server is going to send back after you visited that form
and submitted that form as via POST, is you're going to get back a
response that looks like this. It's going to, hopefully, say 200, OK. It's probably going to be a
web page written in text/html. But an additional HTTP header that
we didn't focus on last week, which is this one, the Set-Cookie header. And the Set-Cookie header
specifies yet another one of these key-value
pairs, the name of which can actually be anything depending
on the server, the value of which is some unique identifier. So you've all probably heard about
cookies in the context of the web. You've probably heard that
they're not good for your privacy. And that's generally true. But cookies need to exist
if you want web pages to be or websites to be stateful, that is,
remember a little something about you. And so session is the name of the-- session is a word that
describes the maintenance of state between a client and a server. That is to say, if the server's
remembering something about you, you have a session with that server, the
equivalent, really, of a shopping cart. So, in fact, if you go to amazon.com or
any website via which you can not only log in but add items to a shopping
cart or equivalent, that is a session. Shopping cart is the
real-world equivalent thereof. So this Set-Cookie header
is essentially a directive from the server to your browser to
store this value in the browser's memory somewhere, either for the life
of the browser tab or maybe even longer, for an hour, a day, a year, depending
on the expiration time that's actually set. The idea, though, is that because your
browser is designed to understand HTTP also, just like the server, you're
on the honor system, your browser, such that the next time you
visit Google's same server, you should remind the
server what cookie was set. That is to say, the browser
should send back to the server, not set cookie because it's already
been set, but a cookie header that contains exactly that same value. So the metaphor here
is kind of like when you go into maybe a bar or
a club or an amusement park, and you showed your ticket, or
you paid your fees, ideally, they'd do something like stamp your
hand such that the next time you go through the line, you don't have to
take out your ticket again or your ID and prove that you have paid
or that you belong there. You just show your hand stamp. And the idea is that
the bouncer can trust that if you're presenting
this hand stamp and maybe it's the right color and the
right picture for that particular day, they should just let you in
without prompting you again for your ticket or your money or, in
this case, your username and password. So cookies are a very
good thing functionally. They are a feature of HTTP. And they are how servers implement
state between themselves and you because, after all, when you
click on a link on a web page or another link on a
web page, eventually, the browser icon stops spinning. And it's no longer
connected to you typically. But, so long as the next link you click
results in a virtual envelope going from client to server
containing this header, it's the equivalent of just
reminding the server who you are. This value is generally a big
number, a big alphanumeric number, so it's some unique identifier. Generally speaking, cookies do not
need to contain your actual username, your actual password. That's generally frowned upon. The useful information
like your username, your password, what's
in your shopping cart can be stored entirely server side. This cookie is just a reminder
to the server who you are. The problem with
cookies, though, nowadays is that they're used so
often for advertising, for tracking, and the like. Why is that? Well, this is a natural result
of that basic primitive. If your browser unbeknownst to you
is in the habit of just presenting this hand stamp every
time it visits a website, you're proactively
reminding websites who you are again and
again, at least who you are in the sense of if you logged in. Now they'll always know who you are. Even if you're in incognito mode,
for instance, private mode browsing, your hand is still getting stamped. Your incognito window is still
sending that same unique identifier again and again. And, so long as you don't
log in, they might not know that your Carter
or David, but they do know you're the same user or the same
person using that browser or, rather, the same browser visiting the
website because that hand stamp is going to be sent again and again. But, when you clear your cookies or
when you close your incognito window, that's like washing your
hand and starting fresh, getting a new unique identifier. So you appear to be someone
different even though, as an aside, even if you're in the habit
of using incognito mode and clearing your browser
tabs and all of that, with very, very high probability,
servers can still track you nowadays based on your IP
address, of course, which is on the outside of those envelopes,
based on the particular browser extensions that you have installed,
based on the various fonts that you have installed. There's some
crazy-high-percentage likelihood that a browser can uniquely identify
you even if you're scrubbing your tracks in this way, so just FYI. But, for today's purposes, it all
derives from this thing called cookies. And this is how they are then set. So let's actually use this
a little more productively and leverage it in the context of Flask
by using another global variable that comes with Flask that you can
import that gives you access to the equivalent of a shopping cart. That is to say, Flask deals
with all of this stuff like setting cookies and checking
for cookies and all of the plumbing. Someone else have solved that for you. And Flask just handles the
contents of the shopping cart or the username to you in
the context of a variable. So let me go over to VS Code here. And, during the break, I created
a new folder called login. If I type ls, I've got the beginnings
of an app.py and a templates folder. And, in the templates folder,
I've got the beginnings of a layout.html and
an index.html just so I don't have to type quite as
many characters to get started. What I'm going to do
with this app, though, is let's implement a very simple
app that allows the user to log in and demonstrates how a server can
remember that you are, in fact, logged in. So let me open up app.py. And, at the very top of this
file, which is otherwise-- let me shorten this even further
so it looks as simple as possible. In this app.py, let me go ahead
and simply add one more import up here called session. And that's going to give me
the equivalent of a shopping cart at my disposal. But I do need to configure it. And there's some different
ways to configure it. But the conventional
way or a recommended way here is as follows, to run app.config. And then set this configuration
variable, which is flask specific, called SESSION_PERMANENT equals
false so that this will indeed be treated as a session cookie. So, as soon as you quit your browser
or close your tabs, typically, what's in the session will be deleted. This does tend to vary by browser. Sometimes things might be kept
around longer than you expect. But, by default, this is going to
ensure that, essentially, the cookie is deleted when you quit the browser. I'm also going to do this
app.config SESSION_TYPE is going to equal, quote, unquote, "filesystem". This just ensures that the contents
of your shopping cart or equivalent are stored in the servers-- in the server's files, not in the
cookie itself for privacy's sake. And, lastly, I'm going to
activate sections on this app by just running this line of code. These, for today's purposes, are
sort of copy-paste-able lines that just get sessions working
in a recommended manner for you. Hereafter, now, we can just use
them as we expect, as we would hope. So let me do this. Let me now open up another file in
templates called, say, index.html. And, in index.html, I'm going to
make a very simple web page that's just going to check if the
user is logged in or not and explain as much if they are. So, in the body block of index.html,
which I prepared in advance, I'm going to do this. I'm going to use Jinja, not to
have a loop or a placeholder, but an actual conditional like this. If the user is logged in with a name,
then go ahead and output inside of-- and let me do this else here. And, actually, let me
proactively do this just so you can see the structure, endif. So I've got the beginnings
of an if else block in Jinja. If there's a name variable
in this template, say this, You are logged in as name period. And then let's give the human a link-- actually, nope, let's do this. Else, if you are not logged
in, you are not logged in. So super simple English text
that's just going to tell us, is the user logged in with a name? Or are they not? And I'm not even going to
bother with a password. We're going to keep it simple
with just a name to demonstrate. All right, so now what am I
going to do in my controller, that is to say, app.py? Let's go ahead and do this. Let's go ahead and create
an app.py called login. So I have a route that just
handles logins for the user. And I'm going to go ahead and do this. Initially, I'm going to define
a function called login. And I'm going to have it return
render template of login.html. So this is going to be
a login form by default. Well, let's create that. Let me go into my templates directory. I'm going to go ahead and create
a new file called login.html. And, in login.html, I'm
going to borrow some of this HTML-- this template from before. In login.html, I'm going to just
have a very simple form for logging in, again, no password per
se, just a user's name. So let's keep it simple as follows. form action equals,
quote, unquote, /login. The method for privacy's
sake will be post. Inside of this form, let's just ask
the user for an input with autocomplete off by default and autofocus on. And the name of this field will
be name for the human name. The placeholder text, as before, will
be, quote, unquote, "Name," capital N. And the type of this field will be
the default, which is just text. And then, lastly, let's have
a button, the type of which is submit because its purpose
in life is to submit this form. And, inside of that button,
we'll see the words login. So very similar to greet,
very similar to register. But we're now just
implementing a login form. OK, now let's go back to app.py. The only thing login does
right now is display this form. But let's actually handle
the user's logging in. So I'm going to do this. If the request.method equals,
quote, unquote, "POST" and, therefore, the form was
logically submitted, let's do this. Let's use this session variable. So this session variable
that I imported globally here is essentially a dictionary. It's an empty dictionary
with two columns ready to receive keys and values. So if I want to put in someone's
name from this login form, I can just tuck it in the session. And it's similar in spirit to this thing
that we did last time for froshims, giving myself a global dictionary. But the problem with that was
that, as soon as the server quits, all of the memory contents are lost. And it was also global. So no matter whether it was me or
Carter or Yulia visiting the same URL, there was no distinction among users. All of us were treated as the same user. But what's brilliant about this session
variable is that flask, because it knows about HTTP and
Set-Cookie and cookie, it creates the illusion that
whether you, the programmer, have one user or a million
users, the contents of session are guaranteed to always be unique
for me or for Carter or Yulia or whatever human is visiting
your code at that moment in time. You have the illusion that everyone has
their own session object or dictionary or, really, everyone has
their own shopping cart just like you would
expect on an amazon.com. So let's use this session
object like a dictionary. Let's do this, let's remember the user's
name from the form by going in session, quote, unquote, "name" and set the value
of that key equal to request.form.get name. So whatever's in the form, let's plop
it into this global session dictionary to remember the user. And you know what? Just for user interfaces'
sake, let's do this, let's return a redirect, a
302 or whatever, to slash. Let's just redirect the user back to the
home page to see if they are, in fact, logged in at that point. So I think, at this point, that's
the entirety of my login route. If the user has submitted their name via
POST, store their name in the session, and then redirect the user
back to the home page. The home page meanwhile
looks again like this. If there is a name in this template,
we're going to see that person's name. Else, we're going to see
that they're not logged in. So how do we get at that name? Back to app.py. Let's just assemble
these building blocks. In my index route, I'm going to do this. name equals session.get,
quote, unquote, name. So you can treat session similar to
request.args, similar to request.form. But it's a more permanent thing. At least so long as it's
the same human logged in, I'm going to get my name or
Carter's name or Yulia's name depending on whose browser is visiting
my URL at this moment in time. All right, so let's cross
my fingers because I wrote a lot of this on the fly. Let me open my terminal window in
my login folder and do flask run. And, OK, I screwed up already. Session is not defined. Did I mean session in lowercase? No, not in this case. It turns out what I should have done is
one more line from flask_session import Session. Why? This is another flask library. It's technically a third-party
library that other smart people wrote for flask users to use. So I copied and pasted that
line from the documentation. So clearly forgot about it. Let me get rid of this
registrants dictionary which has nothing to do with this example. Let me now open my terminal
again and do flask run. OK, now we seem to be in good shape. No error message is apparent. Let me go back to my URL and reload. And notice I am not logged in. Now, this is not very user friendly
because the only way I know I can log in is by going to /login. So let's actually improve the UI. In index.html, if you are
not logged in, let's do this. a href equals /login. And let's give them a link to log in. And, otherwise, you know what? Let's do this. a href equals, quote, unquote, /logout
even though it doesn't exist yet if we want to facilitate the user logging out. But I think this will be a nicer
UI because if I reload now, I'm told that I'm not logged in. But there's my new login
link shown conditionally. Well, let's do this. If I click on this, it's super small. But, in the bottom left-hand
corner of my browser, I'm seeing the /login route. If I click on that there is that
login form, no password, super simple, just a name. I'll type in D-A-V-I-D. And
now, notice, if I Zoom in here, I'm indeed currently
at the /login route. But, when I log in, I'm going to be-- oh, damn it. I did make a mistake. 405 method not allowed. I think we fixed this before. I can go back into app.py. Which line number do I need to fix? Method was not supported
for which route? So, yeah, line 16. So I think I need methods
equals both of them. So GET so I can display the form. And POST so I can process the form. Let's try this again. I'm just going to go back. And I'm going to click-- type David and click Log In. And I'll zoom in on the URL. Log In, ah, you are logged in as David. Now I can log out. And, indeed, if I log out. This one's not going to work. I think I'm going to get a 404
not found, but that's fixable too. So let me go back into VS Code. Let me go down to the
bottom of the file. And let's add another route /logout. Just GET is fine because I'm
not posting anything to it. I'll define a function called logout
just to match the name of the route. And you wouldn't know this
without reading the documentation, but if you want to clear
the session and forget the user's name, forget the
items in their shopping cart, you can do session.clear. And that will just clear
the contents of the session wherever the server is storing them. And then I can just return a redirect. redirect to, for instance, slash. So let's see this in action. Let me go back to the
browser and hit back. I'm logged in as David. But now, when I click Log out,
I'm going to quickly go to-- and I'll show you in the inspector. Inspect, Network tab. Let's click on Log out. I indeed end up at logout first. But then I'm redirected to this long
URL, which is unique to my codespace. But the first logout URL redirects
me with a 302 until I see a 200. And I'm back at the home screen. So, even though that was a
bunch of steps for me to do, that is how every website implements
the notion of logins and also shopping carts. Now, you might add some fanciness
with usernames and passwords and the like, maybe two-factor
authentication and the like. But it all boils down to
storing stuff in the session and using those cookie headers in
order to keep track of who is who. Any questions on these
techniques thus far? No? All right, how about an actual
Amazon, if a simplistic one? Let me do this. Let me go back to VS Code here. Let me close these tabs, and
let me open up an example that I wrote in advance, this one
in my src9 directory's store folder, so the beginnings of an
electronic commerce store online. Let me just dive in blindly
and do flask run for this one. And let me go to my browser
tab and reload because I'm going to see my new app now. And it's super simple, also ugly. There's no CSS or fanciness there. But it's just HTML. And this is the earliest version,
if you will, of Amazon 1.0 where they just sold books, and
only these five books, for instance. So what's going on here? Well, here is how using
all of today's primitives, you can start to infer
how websites work. So let me View page source. And, even though the UI is not very
pretty, let's see what's inside here. There's an h1 tag for books,
just like the title of the page. There's a whole bunch of
h2s, each one of which represents apparently
the title of a book. And below every title is a unique form. Every form, though,
has an action of /cart. And every one submits
via post to that cart. But notice this trick. Just like the deregistration for
froshims, every one of these forms has a unique ID that's hidden,
but the value for this one is 1. The value for this one is 2. The value for this one is 3. So even though for froshims,
we used it to deregister people to opt out of the froshims, here,
you're using it to effectively add items to your cart. Why? Well, where is this data coming from? Let's poke around further. I'm going to open another
terminal window in VS Code. I'll make it bigger. I'm going to go into src9 and store. And if I type ls, you'll see
app.py, requirements.txt, templates, all of which I predicted would exist. There's a temporary folder
called flask_session. This is where, surprise,
surprise, your sessions are temporarily stored on the server. So even if the computer quits or
reboots, the files are still there. The shopping carts are still there,
but you shouldn't need to go in there. And definitely don't change things
in there because things will break. But notice store.db, which
came with my folder today. Let me run sqlite3 of store.db. .schema to see what's going on in there. It's a super simple
database table called books with an ID column and a title column. And that's it. Let's see what's inside. SELECT * FROM book; Not surprisingly,
there are the five books. So, again, you see how we're
stitching these technologies together using these basic building blocks. So let's look now-- let
me quit out of SQLite. Let me shrink my terminal
window and open up app.py. And there's some comments in here. But, for the most part,
it's the same as before. I'm importing some of the
session stuff, so I can keep track of whose shopping cart is whose. I'm opening, though, in this version,
the database called store.db. I'm doing that same stuff, copy-paste
with the session just to make sure that it works. And then, down here,
this is where things get really kind of interesting
and, again, representative of web apps everywhere. My /route, that is, my index,
has this line of code first, a book's variable that gets the
return value of the CS50 function-- CS50 execute functions. SELECT * FROM books return value. What does that return? Well, recall that, when using
the CS50 library and you're using the SQL function, this
execute function within SQL, you're getting back, from db.execute
typically, a list of dictionaries. And the keys of those
dictionaries represent the columns from the database table. So here is a Python list
per the square brackets. Every element in this list is a
dictionary as per the curly braces, not to be confused with
Jinja's curly braces today and that's in the HTML files. Here's one key. Here's another, value
and value, respectively. So, again, db.execute,
when using SELECT, returns just a list of dictionaries. It's as simple as that. So if I go back to VS Code, I have a
string of SQL inside of my argument to this Python function. That gives me a variable
called books, which is a list of all of the
books in the database. So I can certainly pass
that in as an argument to render template so that,
when books.html is rendered, it has access to all those books. So let me do that. Let me go into templates books.html. And, perhaps not surprisingly, here's
that same boilerplate as before. We extend the layout. Here's my body block. Here's that h1 tag that just says
Books at the top of the page. And here is a Jinja for
loop in the template that is going to output, for every book,
an h2, which is smaller but still bold for the title. And then inside of that-- or below that
is a form that's identical for every book except-- notice that I'm very cleverly
outputting a unique value for every one of those forms. Just relying on those primary
keys back and forth, back and forth to implement
this notion of adding. And so what is the /cart method? Let's follow these breadcrumbs. And I'm doing this deliberately live. If you were to receive
or inherit code like this from a colleague, a
friend, a class, you really just follow these breadcrumbs to wrap
your mind around what's going on. And, honestly, start
with the files that feel the simplest like I did, like
index.html, start with the entry point. So let's see the cart route. It's a little longer. But let's walk through it step by step. So the cart route supports
both GET and POST. It looks like, with these lines, which
I haven't had occasion to use yet, I'm just checking. If there is no cart in the session,
create a cart that's an empty list. And I'm doing this
logically in this program because I want to make sure that the
cart always exists even if it's empty. Even if it's empty initially,
that's what that line of code is essentially doing. So we can put things in it. So if we have submitted something to
this cart and thus the method is POST, let's go ahead and grab the ID
of the book from request.form. Let's go ahead and make sure
that that ID is actually valid, and it's actually a number, so
it doesn't evaluate to false. And if so, do this. Go into the sessions cart, which
is initially an empty list. And, just like we saw in week
six, append an item to the list. Append, append, append. So we just have a list of book IDs. And then, when you are done with
that, redirect to the cart route. Well, that's a little
weird and almost recursive because the cart route that we're
in is redirecting to itself. But redirects are always get
requests when done like this. So even though we ended
up here via a POST, this redirect is going to send me
back via a GET, to the same route. And that is why now, outside of the
conditional, these final two lines apply. Here is a books variable. I don't want to get all of the
books because I'm not showing you the catalog now of amazon.com. I'm showing you your shopping cart. And how do I do this? I'm SELECTing * FROM books WHERE the
id of the book is IN this list of ids. And you haven't seen
this yet most likely. But, in the CS50 library, if you
use parentheses and a question mark, so placeholder as always, you can then
plug a list into that question mark, and the library will
separate them all via commas. You might have for a past
problem set manually. We will generate the commas for you. So everything is nicely escaped. And then we're just rendering a template
cart.html, passing in those books. So what's cart.html? That's the last breadcrumb to follow. cart.html, and really nothing going
on that's that interesting here. There's an h1 tag at the top. There's an ordered list, which
is a numbered list just because. And then there's this Jinja loop that's
outputting a list item or li element for every book showing its title. So if I go back to the store
here and actually start adding things to the cart, there,
I've added that to the cart. All right, just one book. Let's jump to the last one, so the
Hitchhiker's Guide to the Galaxy. How about Mostly Harmless? Click that. Now there's two items
in the shopping cart. Let me go back. There's now three items in the
shopping cart and so forth. But if I were to make this URL public--
it's currently private by default. So not everyone on the internet
can visit it at the same time. If I were to make this
public and any one of you were to open it on your
phone or laptop, you would see an empty cart because you
would have a different handstamp, a different cookie. But the server would be keeping
track of all of our shopping carts in, if you will, that flask
session folder, just all sort of happens automatically. Phew, OK. So that then is how
amazon.com is implemented. Questions? Yeah. AUDIENCE: Or is the client-- so let's say if you open
up this application. How do the server know that
this is to be a new session now? [INAUDIBLE] and someone who
starts up a new session. How does the browser [INAUDIBLE]
when someone [INAUDIBLE] that is like a new session? DAVID J. MALAN: A really good question. How does the browser-- how does the server to give you a
brand-new session the first time you visit a website? When you visit something.com
for the first time, your browser will not
send a cookie header. There will be no cookie
colon session equals value. It's just going to be blank,
it's going to be my showing you my other hand that has no ink on it. Then the server will know, well,
if you didn't send me a cookie, I'm going to set one for you by stamping
your hand with the set cookie header. It's just going to generate typically
a really big random number that's different for you, for me, for you
to keep track of us individually. So that's all. It would just happen by default.
And Flask makes all of that happen because we have not only
imported these lines at the top. We have also used these
configuration lines too to ensure that the server does
exactly what I just described. If you had to do all of
that manually, honestly, it would be so annoying to make
web applications because you'd do copy-paste all of the time. This is still some copy-paste, but
it's way less than implementing all of this cookie stuff on your own. All right, how about a
final set of examples that allow us to escalate
quickly to a larger data set and make this more like an actual
amazon.com or maybe an actual imdb.com. And we'll do this by way of a
tour of some pre-written examples rather than do all of
these here from scratch. So I'm going to go into
my terminal window. I'm going to hit Control-c to kill
the previous version of the store. And I'm going to go into shows version
0 initially, which has our old friend shows.db from our SQL lecture, which
has all of the latest TV shows from IMDb using the same schema as then. And there's an app.py. There's a requirements.txt. And there's a templates
folder just as predicted because we're still using Flask. So let's go ahead and
take a look at what's going on inside of this file
app.py as our entry point. All right, so I see some
pretty familiar imports now. I see shows.db using the SQL library,
so nothing too interesting there. The index route is super simple. It's just rendering index.html. And then there's a search route. So this is kind of an amalgam
of google.com and imdb.com. I want to implement this
relatively simple search website for IMDb, just a search box. Well, we can kind of preemptively
infer how this is going to work. A shows variable is being set to
the return value of db.execute, where I'm executing SELECT * FROM
shows WHERE the title of the show equals this question mark. And what am I plugging in? Well, just like Google, I'm plugging
in the value of the q attribute from the URL apparently. Then I'm rendering a
template called search.html. And I'm passing in those shows
as a list of Python dictionaries. So that's it. It's only-- that's the entirety
of the back-end logic here. It's a search engine. So what might I want to do next? Well, my mind goes to index.html. Let's just see what the
template looks like. So I can wrap my mind around index.html. OK, it's pretty darn simple. It's just a form that
has an action of /search, which aligns with the route we just saw. Method is get. It's got an autocompleting
input called q, as expected, and a button called Search. So not really that stimulating there
versus past examples we've done. Let me go into search.html, which
is the other template in here. So let me open my terminal and
do code of templates search.html. Close the terminal. OK, this is kind of
like the bookstore too. It's just iterating over the shows,
outputting list item, list item, list item. But I'm using an unordered
list instead of ordered. So there's not that much to this
application to enabling search. But recall that, two weeks ago, when we
introduced HTML and CSS and JavaScript, we completely punted to
the actual google.com. Today we are, if you will,
google.com or imdb.com. So let's go into the terminal
window, do flask run. I'll go back into my browser and reload. So we no longer see the store. We now see IMDb. And it's a pretty simple search box. Let me search for the office
as in the past, click Search. And notice two things. At the top of the URL is ?q=the+office. The plus is a way of encoding spaces in
URLs so that it's just one long string, but that's conventional. And then there's a lot of offices. But why is this? Well, there's the
American one, the UK one. There's some prior ones that
weren't nearly as popular as either. So there's a bunch of offices in there. But we could probably-- we can tie our ideas together here. Let me open another terminal. Make it bigger. Go into src9 shows0. sqlite3 of shows.db .schema. Oh, yeah, there's a lot
of data in this database. Let's do .schema show specifically. OK, so we have the year of every show. So this just means I can play around now
with the intersection of SQL and Python as follows. Let me go back to how about search.html. And, instead of just showing
the title, why don't I do something like curly curly
brace show, quote, unquote, year. Curly curly brace because why? Well, every element in
this list is a dictionary. So I have access to all
of those SQL columns. So let me reload. And now you see, oh, that's
why there's so many offices. They're each from different years. So every piece of data you have access
in SQL you have access to in Python you now have access to in
HTML by just knowing how to stitch these ideas together. All right, so what's
not so good about this? Well, if I go back to the search box
and I search for just office, Enter, there's apparently no show called
literally office, at least lowercase o. Let me try a little more specific,
Office, as someone might type. OK, so there's one version of
Office, but not The Office from 2013. But what if I want to have
more of a wild card search? Well, we can borrow these ideas too. So let me go back into VS
Code here in my app.py. And I think here, instead of
using equal, what was the keyword? Yeah, so we can do like, for instance. But this we have to be
a little careful of. We don't want to resort
to a Python f-string where we plug in values with
percent signs and the like. So this is a little bit
tricky, but it's worth knowing that if you want to
do wildcard searches safely we still should distrust
the user's input. So what I'm going to do
is this even though it's going to look a little cryptic. I'm going to just do a question mark. But, instead of passing
in request.args.get of q, first, let's tuck this in a variable
so the code is a little more readable. q equals that even though that's
not changing anything fundamentally. Let's do this. Let's put my percent sign
here, concatenate q with that, and then put another percent sign
here so that this whole string, after joining and joining
three things together, gets plugged into the question
mark and therefore escaped. You should not use an
f-string for this thing. You should always use the question
mark placeholder as we keep preaching. All right, so now that I've done this,
I think my search functionality just got way better. Why? So if I go back to the form-- and I'll reload to clear everything. I'll zoom in a little bit. Let's type in just office
in lowercase with no the. And I think I should get now every
TV show that has office, O-F-F-I-C-E, in it somewhere even if it's officer. So that might not be quite what we want. But there's indeed a
much broader match here. So more like the imdb.com. But now it's a design decision. Do you want your-- do you
want to be really nitpicky and require users to type in The Office? Do you want it to be capitalized? This now becomes more of a user
interface or design decision, not so much code. All right, well, let's
make one tweak here that's representative all the
more of today's modern apps. It turns out that this
approach of generating new HTML every time a user
submits input or visits a new URL is increasingly dated whereby every
URL is unique, as opposed to apps being much more interactive. So it turns out, there's
this technique in general, in the world of the web,
where you use something called AJAX, which used to stand
for Asynchronous JavaScript And XML. Nowadays, it just refers
to using JavaScript to get more data from the server so
the user's URL doesn't even change, and the whole browser screen doesn't
flash as though the whole page is being reloaded. So this is going to look
a little more cryptic. But let me go ahead and
show you an alternative to this relatively easy approach. A lot of today might
be feeling like a lot. It's about to feel more
like a lot but not in a way that you need to replicate, just to
give you a taste of what more modern web apps are doing. I'm going to close these two tabs. I'm going to go ahead
and exit out of SQLite. I'm going to kill my
previous version of Flask. And I'm going to go into
shows version 2 now. And, in shows2, I'm
going to do flask run. So the app is running. I'm going to go back to my
URL here and just reload. And notice I've gotten rid of
the Search button altogether, minor aesthetic detail. But what I like about this now is
that if I search for O-F-F-I-C-E, you're seeing the
beginnings of autocomplete, which is kind of everywhere. But you can't implement autocomplete
if you have to reload the whole page, reload the whole page. Why? If nothing else, the
user's going to be-- see a big flash of white as
the whole page redraws itself, which is not what we're used to. If I start over, O-F-F, notice the URL
is not changing, nor is the whole page flickering. Just the URL is getting
shorter, shorter, shorter. And if I really go shorter, there it is. Officer, now I have only this
many bullets on the screen. There's no more below the break. So how can I do this? Well, let's try to
infer a little bit here and be demonstrative
of how you can infer how a third-party websites are working. If you want to-- if you
want to mimic their behavior or just learn better how they
work-- so let me do this. Let me open up developer tools. Let me open the Network tab. And let me search for O. And watch
what happens in my Network tab even though the URL of
the page is not changing. O. Apparently, an HTTP request was
sent from my browser to this URL, which is essentially
representing /search?q=O. Notice that the response was 200. And what is in that response? Well, let me click on that row. Let me click on response. And, very interestingly,
notice what came back. It's not a whole web page. It's just a bunch of li elements,
which you can kind of infer are probably the ones that are getting
snuck into the page dynamically. So if I go back to the
top, there's no ul here. It's just a bunch of lis. And watch what happens this time. Let me close that panel. Let me search for O-F
without even hitting Enter. Here we go, O-F. Now
there's a second request. And If I zoom in, there it is, q=OF. If I click on that and zoom out,
you'll see a whole bunch of lis. But let me claim there's fewer of them
now because fewer strings match O-F. And if I finally type in
office, let alone the office, notice now, at the very bottom
of this, every time you're doing an autocomplete, it's sending
an HTTP request, HTTP request, HTTP request. Back in my day, you'd
have to click Submit. The whole page would reload, and
you'd see the list again and again. This is more modern. And this is an example
indeed of what's called AJAX, Asynchronous JavaScript
that's getting you more data and slipping it into
your existing web page. So how does this work? Let me go to VS Code here. Let me open up a new terminal. Let me go into src9 shows2. And let me open up,
for instance, the index template, which is the entry point. Everything at the top is sort of boring. Here's the head of the page. Here's the input. I didn't even bother with the
whole form because I'm not even submitting a whole form. So I don't need an action or a
method or anything like that. I'm just using it as
a dumb input box only. But notice that it is indeed
an input of type search. Here, now, is an empty ul, initially. So this is why, when you visit the
page, you see a text box but no bullets because the list is empty. And, in fact, watch this. If I click on elements in the Developer
Tools, click on body, expand the body, there is the ul. If I zoom in, there's
nothing inside of it yet. That's why we see no bullets. But if I go back to the template,
here's some JavaScript code, which we haven't spent
much time on, but you can start to wrap your mind around
this line by line as follows. Give me a variable called input. Set it equal to the element from
the DOM, the tree in the computer's memory for the input element, so
that rectangle from our pictures from last week. Then listen to that input
for the input event. I showed briefly last week a list of
like dragging and clicking and mouse up and mouse down and key up and key down. And input just means generally
inputting into a text box. Here, I'm calling a function. It's an asynchronous function
in the sense that there-- it's going to get back to me eventually. If the server is slow, it
might take a moment or two. But, inside of this function, give
me a variable called response. Go ahead and fetch the URL whose
path or route is /search?q= and then concatenate onto that whatever the
user's input that is the value of that input. Then create a variable called shows,
go into that response from the server, and get its text value. So we're not going to
spend much time on this. But fetch is a function that
comes with browsers today in JavaScript that lets
you make an HTTP request. Fetch more content from the server. And you essentially pass it in the
URL that you want to fetch or get. This function here response.text
just grabs the text from that response, which means if I
go to the Network tab and I type in O as before and I click this,
response.text is all of this stuff that we manually looked at earlier. So you're just getting all of the text
that came back from the server that happened to be lis. Lastly, go into the document,
the DOM, select the ul element, go into its inner HTML, and change the
inner HTML to be that text, aka shows. And so what's happening here--
and watch this now when I-- let's reload the page. Let me show you the Elements tab. Let me highlight and zoom
in on the ul element. In the bottom of the screen,
nothing's there yet but watch. As soon as I type O, and I
get back all of those lis, and they get crammed into the inner HTML
of the ul, watch the ul as I type O, there's now more stuff there. And, indeed, if I expand it,
there are all of the lis. That is the inner HTML that just
got automatically populated. And if I type in more, officer,
notice that if I scroll down, there's only so many of them. And if I just type in
nonsense, notice it's back to 0 because there's no text
coming back from the server. This then is an example of
the beginning of an API. And I've used this term over time, but
an API is an Application Programming Interface. And it's a standardized way,
generally, of getting data from someone else's server or
service into your application. Now, in this contrived scenario,
I am both the web developer, and I'm the author of the API. But they're implementing-- they're being
implemented in the same application. But you could imagine, actually,
querying amazon.com for actual books and actual prices and
actual photographs thereof from their servers instead of your own. And so they might very
well send to your server those kinds of responses by just sending
you a whole bunch of text that, again, might just look like all of these lis. But the lis is a sloppy
way of sending information. Nowadays, it's not common to use
HTML, nor something called XML to send back your data. Rather, it's more common
to get back something called JSON, JavaScript Object Notation. And odds are, for your final project,
if you do anything with an API, you'll encounter this in the real world. And JSON looks very, very similar
to what a dictionary and a list looks like in Python. The syntax is almost
the same as you've seen. However, in the world of JSON,
JavaScript Object Notation, you have to use double
quotes around your strings. You cannot use single quotes. And, generally, it might look like this. So here, for instance, is a
response from a more modern version of a server that's not sending back
li tags and a messy bunch of HTML. It's sending back something
that's more machine readable. So this text, ugly as it is, is much
easier for a JSON parser, a function to read, because it's all standard. It's all square brackets, curly braces,
quotes, colons, and all of that. And, even though it looks
like a mess on the screen, it's very standardized,
unlike li tags which who knows what might come
back in those aesthetically? Since there's so many HTML
tags, not to mention CSS. So let's make a change here. Let me go back to VS Code here. Let me close this tab and quit out
of this version of my application. And let me show one final version of
shows by going into shows version 3. And, in this version, I'm
going to go ahead and do this. I'm going to open up app.py. And, in app.py, I'm going
to import one more function from the flask framework called
jsonify, which is not necessarily a technical term. It just means turn something into JSON. So what does that mean? Well, notice that, down here, I have
a search route that looks like this. But, before we look at that, which
is going to end with this spoiler, like jsonify, let me actually do this. Let me open up also
from shows version 2, the previous version of this,
which looked like this here. This was the app-- the search route from
the previous example. Here's how I got q. Here's how again I did the escaping
of the user's input with the wildcard. But notice that I also did this. If the user got back no results, then
I just gave it an empty list instead. But let me show you two from last
time. search.html looked like this. And shows2 in templates, shows.html-- whoops. search.html, what you'll see
here is the very simple template that generated all of that text,
all of those lis just again and again and again. So we're going to get
rid of that template in this third and final version here. So if I go into shows3, notice
I'm doing the same code as before. I'm building up a Python list of shows
that results from that SQL query. But, instead of passing
it into any template, I'm just jsonifying that text. What that means is that
what I'm essentially going to send from the
server to the browser is literally something that looks
like this here on the screen. So if I go back to VS Code here and
run flask run in this final version, and I go over to my other
tab here and reload, I have the same response as before. And it's actually
going to work the same. Office is going to still work the same. But if I undo that and go to inspect
and go to my Network tab here and now search for O,
same paradigm as before. There /search?q=o, let's click on that. But notice-- and let me make
this even bigger on the screen-- this, even though it looks more verbose
and it is, it's way more standardized. And this is the, quote, unquote, "right
way" to send data over the internet when you want two pieces of software to
generate and consume it respectively. Here, now, we have not only
just the titles of the shows, but I've even been generous and
sent the number of episodes, the unique ID, the title,
the year, I've essentially sent the entire SQL database in a
standard, portable, textual format that my code can now use. So, when you think about most any modern
application, we come back to Gmail. When you access something
like Gmail in your browser and you are waiting and waiting and
waiting in a new email comes in, what has happened? Tonight, for instance,
open up the Inspector. Watch the Network tab. And, odds are, every few
seconds, every few minutes, you'll see some kind of response coming
from the server, maybe JSON, maybe some other format,
containing your email, including at least its
subject line because that's what's adding more and
more HTML to the browser. Indeed, if you open up the
Elements tab and just watch it in the most watching-paint-dry
kind of situation, you'll see probably more and more
emails appear in the underlying DOM or document object model
inside of the browser. So I can't stress enough
that, even though we've spent just a few weeks on SQL
and the HTML, CSS, and JavaScript and now Flask together,
that is how the web works. That is how all of today's
modern apps work and, hopefully, you too with your final projects. That's it for today. We will see you one last time
next week for the end of CS50. [APPLAUSE] [MUSIC PLAYING]
