SPEAKER: All right.

This is CS50, and this is week nine.

You'll recall that last time, we took a look back at such things as Scratch.

Because recall that when we introduced Scratch,

we introduced a whole number of programming

constructs-- loops and conditions and functions and variables and more.

And then just one week later did we transition from that world of Scratch

to C, where the syntax was much more cryptic looking, certainly

at first glance, and perhaps a little bit still.

But the ideas were ultimately the same.

And now in week nine as we transition from the world of C to Python,

you'll find that that same finding is the case, whereby

we are using the same ideas.

We're leveraging the same concepts.

But we have to translate it now to a slightly different domain

and a slightly different syntax.

But things really start to get interesting this week

and beyond, especially as we build on our ability

to write Python code, our ability to serve up web applications.

Because now we can begin to leverage so much more functionality

than comes with C, than comes with the CS50 library,

because there's such a large community of software developers

who have created some really amazing things that we can try out.

So let's look further today at Python, and let's look further

at the applications for a language like this.

You'll recall that perhaps the simplest program we could have written last time

was actually just one line-- print Hello World.

But you'll recall as you began to dive into some of this past week's

challenges, you might have needed or wanted

to actually start wrapping code like that in a method or function like main,

and then calling it by default with this magical incantation here.

But this was the building block toward which we were starting

to develop more interesting programs.

But now we're going to really context switch from a command line environment

over to a web-based environment.

And the world has been writing web-based applications for quite some time.

Even I 20 years ago recall made that Frosh IMs-- freshman intramural sports

website.

And even since then have the languages changed and the paradigms changed,

and we humans have learned a lot about programming for web-based applications.

And this, for instance, is one design pattern or one architecture

that has arisen, whereby MVC refers again

to this pattern, whereby you put your intelligence, your so-called business

logic in your controllers.

This is one or more files that has all the conditions,

a lot of the functionality calls, and actually does something

with your program.

Then you have the views, which are often templates or files that

render information that you might have dynamically generated

or input from users.

And then model.

And today, we start to dwell on the M in MVC, model, because last week,

we didn't really leverage much, if any, of a model.

But this week we're finally going to demand of ourselves the ability

to save data, retrieve data, search data, delete data, and more.

And we really haven't had this capability, other than very simple CSV

files, for instance back in the day of C,

and even last week when we dabbled with those in Python.

And you'll recall, last time we introduced this.

Flask is what's called a micro framework.

So a bunch of files, a bunch of code that a community of people

have written that just make it easier to make web-based applications.

It's absolutely not required.

In fact, one of the sample programs among last week's distribution code

if you like to go back and play was a program called serve.py

that doesn't use any of this.

It just uses built-in Python functionality.

But you'll find that it's pretty cryptic.

It's pretty heavyweight in order just to do something simple.

And so things like Flask have come around that just make it easy

and dare say more pleasurable to write web-based applications,

because people have realized in writing web app after web app after web app

that they're just repeating themselves, or borrowing code

they've written in the past.

And so in frameworks, you have solutions typically to very common problems.

So we'll use this set of solutions to the development

of a web-based application.

And for instance, the simplest Flask application

that's also available from last week's source code

might be something like this, whereby the top of your file,

you don't import like the CS50 library, you instead import someone else's

library, specifically from the Flask framework import-- what's

called the class, recall, called Flask-- capital F.

And then also a function or method called Render Template.

And we used both of those as follows.

Last week, we instantiated a Flask-based application

by essentially passing in this special reference

to the current file, the name of the current file,

and then allowing the framework to do its thing

and give us back this very special, very powerful object called app--

though we could have called it anything-- that gives us

access to some useful functionality.

For instance, the most useful functionality

initially was just this-- @app.

And this is just syntax for what's called a decorator, and more

and that some other time, or more on that in Flask's own documentation.

But essentially, this line here-- @app.route,

says that hey server, any time you see an HTTP request for slash, the default

web page typically of a website, go ahead and call the following function

that's immediately below it.

That function I've called Index, mostly by convention.

But I could've called it anything I want.

And all it did last week in this example was render a template.

In this case, index.html.

Now, that could be raw HTML recall.

But oftentimes, you use something called a templating language.

And indeed, we introduced a little bit of Ginga last time, which

is a Python-based templating language that we'll see just

makes it easier to generate HTML without having

to write HTML inside of our actual Python

code, which tends to be frowned upon.

So let's take a look back at one of those examples, which

I've renamed from Frosh IMs last week to Frosh IMs zero.

And recall that we had the following files.

We had a templates directory, inside of which

was failure, index, layout, and success.

Kind of a lot of complexity for a pretty simple program,

but we'll see what each of those does again.

And then application.

And this was the so-called controller code that actually did something

interesting last week.

Now, what was that?

Well, it's a pretty small program.

As before, I've imported from the Flask framework

a whole bunch of symbols here.

I'm instantiating my application here.

This is copy-paste from our simplest of examples,

whereby if the user just visits Slash, I want to show him or her index.html.

But then it got interesting.

This really was the first time we had the capability

in a web-based environment to respond dynamically to user's inputs

based on whatever they typed into a web form.

In fact, if you think back a few weeks in week six

when we first introduced the web and HTTP and TCP/IP

and making HTML-based web pages, you recall that all we did

was implement Google's front end, and an ugly one at that.

But just the HTML form, that if you click the Submit button,

it submits to Slash search on google.com,

because we pretty much deferred completely to them,

lacking at the time a backend and lacking at the time

even a language in which we could implement our own backend,

a web server that actually responds to those requests.

But in Frosh IMs Zero, we have the ability

to have our own route, in this case called

Slash Register that I've specified isn't even

going to respond to HTTP Get requests, but rather Post requests, which

typically mean a form submission is sending one or more fields

that you don't necessarily want to end up in the browser's URL or history.

I'm calling my function Register, and this would be a good convention.

Just make sure your function here lines up with what the route is there.

And then I'm checking a couple of conditions.

If that request's form-- that is, all of the parameters

that were submitted via HTTP Post-- has a name field--

so a text field, for instance, called Name--

and that equals nothing-- quote unquote, the so-called empty string--

or, that request's form's dorm key has a value of quote unquote, which

is to say that if the user, myself last week, did not give my name or my dorm,

then go ahead and return the template called Failure.html.

And we'll take a look back at that in a moment.

Otherwise, render template Success.html if all in fact goes well.

Now, if we take a look at Failure.html, it didn't do all that much.

It extended Layout.html.

It declared a title of Failure.

And then it declared a body of You must provide your name and dorm

as sort of an admonishment to the user.

If I look at Success, meanwhile, it's pretty similar,

but the text is different.

But this is the problem we address this week.

You are registered, well not really.

Because recall-- and you could have seen a moment ago-- we did nothing

with the user's name or dorm or any other information,

we just pretended to actually register them.

And then what did the form itself look like?

Well, this page here is mostly HTML.

But again, notice that even this page at the top

defines a body block and a title block, because it's extending Layout.html.

So this is the Ginga stuff that I referred

to earlier, the templating language.

And if we finally go into Layout.html, now you

see the basic framework for every page in this web-based application.

It's a pretty small application to be fair, but it does

have at least three distinct pages-- Index, Failure, Success-- all of which

are identical to the file, except that they each have a title and a custom

body dynamically embedded thanks to how we're using templates.

So this is a nice way of not having to copy and paste all of that code

into every file, thereby making it a pain to update anything,

to add CSS or JavaScript files, or generally any

of the overall structure of the page.

We can factor that all out to Layout.html.

Of course we just threw all this information away.

that name, that dorm, every student who's been registering by this app,

we're forgetting about.

And so at the tail end of last week, we introduced this solution recall,

whereby in Frosh IMs One now, I'll call it--

or rather today let's redress that by borrowing an idea from last week

that we didn't incorporate into Frosh IMs as follows.

In Application.py for this next version called Frosh IMs One,

what do I seem to be doing differently?

File's almost identical to before.

It's a little longer this route, because what I've grabbed

is some of the code from last time, whereby we wrote out to a CSV

file-- Comma Separated Value-- those student structures.

We did this way back when in C. We then ported the student struct to a student

class last week, and now I've borrowed that same code

for saving those students to disk, so to speak, by embedding it into this route.

So what's going on?

So if again the name or the dorm are blank,

I go ahead and just return the template called Failure.html and we bail out.

Otherwise, I declare a variable called File.

I open a la C's fopen function, registrants.csv,

which I'm just calling this just because it's

going to contain my registrants in a comma separated values file.

And then quote unquote a.

And you might not recall this or might not have seen this, but quote unquote a

is for appending.

If I instead and accidentally did w for writing,

you might think that's correct.

But every time you use quote unquote w, you're going to write out a new file.

Which is to say, if 100 students registered

for some intramural sport via this web app, and I was using quote unquote w,