DAVID MALAN: All right.

This CS50 and this is lecture 7 wherein we pick up

where we left off last time in talking more about Python,

but this time using Python for even more powerful purposes,

an alliteration I didn't intend until I just said it there.

But the goal here with Python now is to actually use

this language to generate another language, in particular HTML.

And what we'll do is start to provide all the more of a mental model

for what you would call separation of concerns, whereby

when you design more complicated web based, or rather when you design

more complicated software, you tend to try to adopt certain design patterns so

that you're not just writing everything in one big file that

gets a little confusing, unwieldy to maintain and to add to over time.

But you start to separate your concerns, and your functionality,

and your features, and your collaborators' work

into different files and different methodologies.

So we'll try to give you some of these industry standard approaches today

and why they actually solved problems.

But, of course, how did we get here?

A few weeks ago, we talked about this thing,

this virtual envelope that just represents

packets of information, zeros and ones, going across the internet from point A

to point B. And among the messages in these envelopes

might be for web requests.

And we talked about HTTP, a protocol, hypertext transfer protocol,

that just sends message like this inside of the envelope.

And this is requesting, of course, the default page

of a website as implied by the slash.

And in many cases, but not always, this implies

a default file name of index.html.

But that's a human convention, not a requirement.

Hopefully, the server responds with a numeric code equal to what integer?

200, hopefully, a number that we never actually

really see unless you get more comfortable

and start poking around Chrome's inspector

and you look at your network traffic.

Right.

So here is an actual successful response,

which means everything is indeed OK.

And if the browser looks a little farther down in the virtual envelope,

if you will, it will see another language called HTML, HyperText Markup

Language, which is the stuff we wrote a couple of weeks ago

and you'll continue writing this week as you now dynamically generate websites.

But what we'll introduce today is what's also known as a framework,

or, more precisely, a microframework, because we'll see in just a few minutes

time that it can actually be really annoying and really tedious

to generate websites automatically using Python

if you have to write Python code alone.

And so humans, over the past several years,

have noticed, wow, every time I make a web application using Python,

I find myself typing the same lines of code

again and again just to get started, or when I'm collaborating with someone

else, I find that, ooh, it's a little hard to collaborate

if we're all working in the same file.

So humans have invented what are called frameworks.

And this is an example of code written in Python

but using a framework called Flask.

So whereas Bootstrap, which you've played with a little bit,

is a framework for CSS and JavaScript, they have some dynamic features

as well, Flask is a framework for Python that

just gives you some library code that you can use freely

in your own applications.

And it just makes it, ultimately, a little easier to get your work done

and build the thing you want to build as opposed

to having to reinvent the wheel again and again like people before you.

And so here is a methodology to which I alluded earlier just to have

a mental model for the coming weeks.

So up until now, pretty much every program

we've written in C and most recently in Python

you could call like controller code or controller logic or business logic.

Right.

It's all about getting something done logically,

usually in one file, maybe two files if you have another helpers.ce or header

file or whatnot.

But we've been writing logic.

But today and two weeks ago when we will focus

on web programming in HTML and CSS, there's the second part of our world.

There's like the logic that gets the interesting work done with loops,

and conditions, and all that.

But there's also now going to be the aesthetics,

the stuff that the user actually sees and the way you present your data.

So we're going to just introduce two letters of an acronym

today moving forward.

Anytime you start writing logical code in Python,

it's going to be called your controller.

It's sort of like the machine that operates your entire web application,

but anytime you do something more aesthetic,

we're going to call that your view code, so C and V being the letters here.

And this just refers to a separation of concerns.

Your logic goes in this file.

And your aesthetics and formatting go in this other file.

Next week, we'll introduce databases in SQL, structured query language.

And we'll introduce an M here, because the acronym that's

in vogue for quite some time now is MVC, though there

are alternatives to this mental model.

And that just means there are three different types

of things you should be thinking about when building an application.

But today we're going to focus on these two, controller and view.

And up until now, we've pretty much been doing entirely controller stuff

when writing code.

So the motivation, ultimately, will be to get to the point of building,

essentially, this, the freshman intramural sports website,

which I was the first one to make back in 1996 as a sophomore,

maybe 1997 as a junior, after having only taken CS50 and a follow

on class CS51.

And even though this is horrifying to see nowadays, underneath the hood

was a whole bunch of controller logic and a whole bunch of model code,

even though I don't think MVC existed as an acronym

back then till humans figured out the pattern.

But what it did have via the menu up here was a whole lot of functionality.

So no longer did you have to walk across campus filling out a form

and drop off a sheet of paper in an RA or a proctor's dorm room.

You can instead just go on the web, which all of us surely take for granted

today, fill out a web-based form.

And then at the time, the proctor in charge of froshims

would get an email confirming who had actually registered for a sport.

And eventually we added CSV files, comma separated values

files like spreadsheets, in which the data was saved.

Then we had this really cool tournament bracket

thing, which was all very dynamic and impressive I'm sure at the time.

But we'll focus on really just the fundamentals today.

So how do we get there?

Well, let me go ahead and open up CS50 IDE

and propose that if we want to make a website, a web

application really, and by application I mean something that does have logic.

By website, it's generally something that's static.

So that's what a web app is.

It's something that changes based on who's using it, when you're using it,

and what you're doing with it.

Let me go ahead, and in the most annoying tedious way possible,

implement a web application using Python.

So I'm going to go ahead and open a file called serve.pie to serve up a website.

And I'm going to go ahead and import some library code.

So from HTTP server, import something called base HTTP request handler

and also something called HTTP server.

And then I'm going to go ahead and use this keyword class, which

is HTTP server, server request, request handler, base HTTP request handler--

handler.

Then I'm going to go ahead and in here implement

a function called def do_GET, which implies--

this is a function in Python that should be called anytime a user

visits my web server via GET, the type of verb

that we've talked about in the context of the web.

So suppose that my only goal here is to make

a web-based application that for the moment just says hello world.

We know how to do this with HTML, but with HTML that's just a file.

Let's write a program that not just prints hello world,

but generates a web page containing hello world.

So the way I might do this is this.

I can literally say self, because self refers to the web server in this case.

And I can go ahead and send a response code of 200,

just kind of presumptuously assuming everything's

going to be OK in a moment.

Then I'm going to go ahead and send a header, which

recall, we've discussed briefly in the past,

whereby this header is going to be content type and its value

is going to be text HTML, which is a clue to browser

that it's receiving not a GIF, or JPEG, or something else,

but an actual HTML page.

And then I'm going to go ahead and say that's it for the headers.

I'm going to call function called end headers.

And then lastly, I'm going to use Python code

to dynamically generate my website.

Now, what does the website have to have?

Just hello world at the end of the day, but there's a whole bunch of html

we need to do in order to get to that point.

So I'm going to use a function called wfile write in order

to write out the following.

Let me go ahead and write out doctype--

whoops, exclamation point doctype HTML.

Then let me go ahead and do the same thing, wfile.write, let me go ahead

and copy paste this moving forward, which, of course, is always

a bad instinct.

Then let me go ahead and output HTML lang equals en for English.

And notice I'm using single quotes inside my double quotes

so that Python doesn't get confused.

Then let me go ahead and output head tag here.

Then what comes after the head tag typically?

Yeah, so usually title lately.

So title will be like hello title, close the title tag.

And now we're going to go ahead and what comes after title?

Close head, I think, if I'm doing this right.

And then after this we probably have a body.

And then oh my God, this is the worst way to build a website.

But let's go ahead and now say something simple like hello world.

And now let's go in here and say something like body.

And then finally, let's go ahead and end the page and say slash HTML.

Done.

OK, and now I actually need to configure the server to listen on a port.

So let me go ahead and define a TCP port of 8080, which we've been using.

Let me go ahead and define the server's address as being,

oh 0.0.0.0, which is what the IDE uses by default, like a lot of servers.

And then let me create the web server, HTTP server.

server_address HTTP server request handler, httpd.serve_forever.

OK, that is how you make a web-based application that

dynamically generates HTML.

In retrospect, I really regret typing all of that out because the whole point

now is to throw this code away.

Like, this is why frameworks exist.

If my goal quite simply at hand is to write Python code that dynamically

generates HTML, then calling lots of functions like write,

which is essentially the equivalent of print in this context, is just tedious.

I got bored writing it, I accomplished so terribly

little at the end of the day.

And so frameworks exist to make our lives easier.

But what's going on underneath the hood is exactly this.

When we start using this framework called Flask,

it's just going to make all of this automated for us.

It's going to make it easier to specify the IP address that you

want to run your web server on, it's going

to make it easier to specify the port number that you want your server

to be listening on, and it's going to make it easier

to respond to get requests because Flask will

take care of the implementation of some function like this one called do get.

So all of this is there underneath the hood,

but the flask framework gives us essentially an abstraction

on top of that.

So what do I actually mean by that?