So, welcome back.
Now what I want to do is I want to dig into a little bit
about how you as a developer of a Django application
interact with Django itself with objects.
So, just to recall,
if you're looking for the downloads, dj4e.com is the place to go.
We are working through the Django tutorial
and I'm pretty much no further than part 2 in this particular one
because it really not worried about building the Django app,
I'm really interested in how objects work.
So, one of the things that you can do because Django is really cool open-source,
is we're actually going to look at the source code to Django.
Django is open-source and has 26,000 different separate modifications,
almost 1,700 contributors, and it's a lot of source code.
It's probably a million lines of code.
And so this is real enterprise software,
it's very exciting stuff and open source
is really cool because we can look inside Django.
Django is not a magical thing that we can't see
and we can learn from it and understand it.
So, what I'm going to try to do,
is I'm going to take you inside Django
and our application that we write is going to be really simple.
It's just pulls application that just prints out,
"Hello World" because this isn't a Django class,
this is really how object-oriented works inside Django.
So, what we're doing here is if you
read the Django documentation and you read the Django tutorial,
what you find is that,
oh okay there's this big thing called Django and you got to write these files,
this file URLs that routes things and models that creates
database tables and allows you to read and write data from those database tables,
and the views that shows what the user interface of this is.
And so, you're supposed to create these files.
So, I'm going to focus mostly on the models file and talk
a little bit about what's going on inside of Django and how Django
in effect creates classes and then you create classes that derive from
the Django classes and then you can create
objects that are based on your classes and then use those objects.
We're going to dig in to the source code to Django.
So, this particular one,
let's take a look at this base.py,
let me show you the models file that's our code.
So, here's our models file and if you read the documentation and in Django it says,
well if you want to create a database table,
it's called a model and the model view controller.
We're going to make a database table, has question_text,
publication date, and then have some methods inside of it,
like how to print this particular object out as a string
and then this was published recently
is something that they're going to use in there.
Then we're going to another table called choice
and it's going to have a question column and a text column.
We can see this, there's this thing called migrations that reads this and creates tables.
And so, in here,
we have polls2_choice_question,
polls2_choice which has those columns and it's created this database table for us.
This thing not only allows us during runtime to read and write from the database,
but it also at setup time it creates things for us.
And so these two database tables that I've got sitting in my database here were created
from this object because it runs one process to read
through your objects then create database tables.
It's another process while it's doing request-response cycles,
then it actually reads and writes the data in the database.
So that's one nice thing and so models.Model is a class.
If you just look at this, we're creating a new class,
that's Question, it's our class
and we're extending the models.Model class
and we're doing this to inherit lots and lots and lots of functionality.
And then, the definition of this is just variables models.Charfield,
that's a variable or constant constant with
some stuff and these are objects and all this stuff is sitting there for us.
It's almost like a dialect of Python
that is specifically to define these database models.
So, if you know that this is a class and that it's extending another class,
let's go find the source code to that class.
So, now what we're going to do is we're going to go into the Python GitHub repository
and here on line 383 in the base.py,
this big long thing if you're looking for it and its linked
here from this slide right here and now this is Django code.
This is the code that was written by the Django project.
And so, they made this model and if you look at this,
you've made simple classes.
This is not that different than the classes you made.
So, you have _init_ method and the first parameter is self.
Now that should look familiar to you and then you have a couple of arguments,
and then we got a whole bunch of code.
And so, if we start looking down here,
this is just the constructor.
So, part of the goal of object-oriented programming is you get to write
a little bit of code that leverages
hundreds and hundreds of lines of code that somebody else,
some other really sharp people,
let's see if we can find the contributors.
So, this is a list of all the people that built this.
These people know a lot,
there's a whole bunch of people and we can
see their work and what they're doing and how long they've been
working and they're doing things like reading all these documents,
like the hypertext transfer protocol
and this and that and knowing how to talk to databases,
and how to talk to SQLite database and how to
talk to MySQL database and Postgres database and Oracle database.
You literally don't need to know anything.
And so what they're doing, is they're building
a really large object or
class that then you can extend and you don't have to write all this code.
This is very general-purpose code.
Part of the goal of writing an object is to hide this from you.
Now, we can look at it,
you shouldn't have to look at it.
You should be able to look at
the documentation i.e the documentation on these little tutorials.
I'm just trying to give you the sense that,
here we go and so this is still the constructor.
This is the initialization that constructor,
so now we now have a method and so these are
other methods and these are things that you'll recognize,
the double underscore string underscore that's what happens when we
convert a model object to a string underscore underscore.
So, this is no different than if you convert a dictionary to a string.
There's a little method inside of
Python that's double underscore string double underscore.
eq, that's comparing equality.
Hashing has to do with how dictionaries work, getstate,
setstate and all these things are just the things that if I am the Django developer,
I have to do this because that lets me mount my class into Django the
right way and these are methods that would be documented like serializable value-
Save, and there's another like whole bunch of stuff.
See, how much work it save base.
If you're probably looking at the Django documentation to see all this stuff.
Save parents, were still in the model object.
Right? Next to prepare database save, clean, validate,
unique, and so this is just code that was written by these people.
Where are they? All right.
All these people wrote all this code,
and read all the documentation and tested the heck out of it.
You just write this code right here.
You extend, and you inherit all that stuff.
That does things like creates other tables which I showed you.
It actually hooks into an administrator interface.
Let me see if I can show you that.
This is an administration interface.
So, this user interface is part of your Django application that came from Django,
that's the admin tool,
the admin panel within Django,
and your model is now in there.
All right?
So, you got some question text and date published et cetera.
So, all you did was created one little file.
Right? Django is this magical thing,
administrator interface, database creation,
table creation, et cetera.
You created this little file, and away you go.
Okay? So, then I'll show you one more thing.
Just the pattern you'll see it's kind of the same.
Is in this views.py file.
So, this is returning a response when you go here into the polls to application.
Right? It returns this response.
But if you were to look at this in the developer console under network,
you would see that there is a whole bunch of stuff that you going to do to do HTTP.
We sort of saw that in the first video.
Like the response headers,
all these things what the content is,
what the type is, the date
these things and there's many other things that might be necessary.
So, you could learn how to write all these things,
or you could basically say, you know what?
I'm just going to inherit the obvious things,
and I'm going to read the documentation on HttpResponse.
So, this is an object,
this is the constructor to that object,
and we're going to send in a string to the constructor.
So, with HttpResponse we could create it,
we could set headers,
we can do all kinds of things in it.
Not just the text, but all kinds of other things that have to do with the HTTP protocol.
So, somewhere inside of Django,
they have defined this object that's the HttpResponse.
So, I can show us that one as well.
Take a look at the HttpResponse.
We're using it in a very simple way.
But, if you look inside Django,
you see there's a lot to it.
So, here we go is content,
is a set of bytes in this case,
and that's the constructor,
then there's serialization et cetera.
So, all those things are part of that object and HttpResponseBase,
and we'd go find that one which I think is just up here.
So, even within this file they're using one class HttpResponseBase,
content-type, that's the thing about its text/HTML_status,
that was the 200 okay et cetera charset UTF8.
So, we're setting that thing up that's a constructor here.
If you were looking at the documentation, you will see that,
the charset, setting a cookie,
cookie has to do with the little bit of
data that goes back and forth between the server and the browser.
You don't have to know how to do that.
You can go read that. You go into RFC 2616.
If I got that,
look at 2616, and then we could search for cookie.
How come I don't see that.
RFC HTTP cookies, which one is it?
Maybe it's got its own document.
Yeah, there we go. Rfc 6265.
So, if you want to set a cookie which is how we log in and out of applications.
You've to go read this one. How many pages is this?
It's only 37 pages.
But it turns out, that thankfully somebody in the Django project, where are we?
As a little command,
has a method called set-cookie for us,
and for you to go look at the documentation.
If this HttpResponse want to Set-Cookie back in the browser,
instead of reading all this stuff,
some kind person who helped write Django wrote all this down,
and gave you a method called set-cookie.
So, I'll stop there,
I'm not really trying to get you to sort of be a wizard in any of this stuff,
I'm trying to give you a little tiny places where you can jump in and learn more.
The basic idea is there's lots of complexity to this, lots of documentation,
lots of rules about how to comply to this stub,
and Django has made it,
so that's all hidden behind this abstraction boundary.
You have objects, you make those objects.
So, we played with the models object,
and then we played with the HttpResponse object,
and we can use as much or as little,
we didn't have to use the cookie and the response object.
We can use as much or as little of that stuff as we want.
That's the beauty, is that all that complicated detail is hidden inside
Django with the convenience of we can use as little or as much of it as we want.
So, I hope you didn't try to like write Django because of this.
I just wanted to make a little connection with how you work with large frameworks,
or large libraries, and how object-oriented programming,
and the patterns of abstraction, and hiding,
and inheritance can be put to good use both by building libraries,
and then by using those libraries.
I hope you found it useful. Cheers.