Welcome back, everyone, to this lecture on how Django works.
We're going to be discussing the key ideas behind how the Django framework actually operates and works.
This is also going to lead to a nice roadmap of our learning journey for the rest of the course.
So the key features of jangle fall under what is usually called a model template view structure.
So you have your model, which connects to the actual database, your template which connects to the
user browser and then your view, which is kind of a connection between the model and the template.
And in general terms, there's going to be a couple of features that allows us to follow this MTV structure
and that is an object relational mapper or 000rpm.
The Python models themselves written with Django, the URLs and views, and then the templates.
So let's see how this actually plays out.
If we're trying to connect information from a database somewhere, such as a database hosted on Leno
to a user browser.
So what we have here is the connection we're trying to do, get information from the database all the
way to the user browser and then clearly there's going to be some interactivity.
And you can think that every web application at its core is doing something similar to this.
It's transferring information from a database to a user.
And then the user can update or transfer information back to the database, and information can be videos,
pictures, text activities, cetera.
OK, so let's start backwards from the user browser, and we're going to be exploring this in terms
of actual Django framework specifics.
So your user browser is going to end up receiving what's known as a template, and the template itself
is going to be an HTML file, so the template is HTML.
But keep in mind, a dot HTML file can then link to things like a CSV file or a JavaScript file, so
you can understand the template as what your browser is directly reading for information of what to
display to the user.
Now, how do we actually end up connecting the template to the database?
Each HTML, CSS and JavaScript aren't really going to be stored as far as things that can be manipulated
by the user.
Instead, we're going to use ginger templating and note might use their of two curly sets of brackets
because that's the sort of syntax you're going to be seeing when we actually discover how to work with
ginger templating.
But ginger itself allows us to insert information directly from a python file into that template.
So this later connects to the actual Python file that's using the Django Library or Django framework.
So we end up doing is we create a view component, and this is typically going to be something called
viewport pie is the python file, and this python file is essentially a list of functions and the use
of decorators.
It's going to allow us to inject information into that template directly from Python, which this allows
us to use all different types of Python libraries to do any sort of analysis or manipulation with the
data of a Python library, and then inject that information directly into the template in a form that
the user browser can then understand.
The other thing to note is that this view works in concert with some URL routing.
Typically, this is going to be another Python file, often called URLs that pie.
And this just tells which view goes to which URL route.
So one view may be associated to my website dot com forward slash stuff, and maybe another view goes
to another subdomain like my website dot com for slash users.
So you can see here it's going to be interactivity between the views and which route they should take,
which connects them to a specific template which is then shown to the user browser.
And keep in mind, right now I'm showing everything kind of going towards the user browser, but a lot
of this will have back and forth interconnectivity.
So where does the actual information connect to the database?
Well, the view information itself is often linked to a model, and models are going to be a subset
of the jingo framework that is actually a python representation of a database and database tables.
So models, it's going to be yet another Python file again, often called models, not pie.
And this is using Django models, which are essentially python classes where you have these different
attributes inside the class that end up representing different columns within a table within a database.
So that's actually going to end up linking directly to your database.
And what's really nice about Django is by just working with the models file often Django, you pretty
much don't have to worry about all the sequel and database management that's happening behind the scenes.
That's what makes Django so powerful is that even though this looks really complex, you just end up
dealing with a couple of Python files using Python code, and Django itself is doing all the heavy lifting
for you on the back end by actually setting stuff up with a sequel database, making sure you are all
routings, connecting to your views and so on.
So this is the main pathway that we would actually follow to get information from a database to the
user browser.
We have a database typically stored in something like sequel and then that is directly linked to a model's
file that's using the Django framework, and that itself is a Python file.
And then we can connect those models to different views, and those views through a URL routing configuration
are then allowing us to insert information into a template that the user can then see in their browser.
Now, if you're more familiar with terms like what's happening on the client side versus the server
side, you can think of the template as the client side because it's actually happening on the user's
computer.
They're actually seeing the HTML, the CSC, JavaScript and then what's inserted through ginger, which
eventually just becomes normal HTML on the user browser side and then everything else is happening on
the server side.
So everything that really has to do with import Django and do something is happening on the server side
of the URL, routing the views and the models and eventually further back the database, which is storing
all the information that's connected through the models.
So if we think about this back in terms of model template view structure, we have the Model S., which
is kind of this model's connection to a database.
You have the template side of things which is going to be your HTML template that is using gender templating
to actually then connect to the view section, which you can kind of think of as the view that's actually
working with the data connecting to your routing.
And it's the connection between the model on the very back and the things versus the template on the
front and the things for the actual client side.
This is where you get that model view template structure.
And again, I mentioned that this was all diagram showing a one way connection to the database of the
user browser.
But keep in mind that the models and database those are actually going to have interconnectivity.
So you can update models which and updates your sequel database.
And you should also keep in mind that you can have many more Python files for application logic so you
can have something like that pie, which maybe does some machine learning logic, and you just connect
that through import to your final viewport pie file.
So there's going to be lots of interconnectivity between models having logic applied to them in Python
and then sending that to The View.
Or maybe you just send the models directly to the View, or maybe you're using some other application
logic within your Python file, cetera.
Main idea here being is that this is where you can really expand the flexibility of Python by adding
in as many Python scripts as you want and performing many different types of manipulation, analysis,
comprehension of the data, et cetera, through Python applications.
And eventually, you send that information to the view that pie file, which itself is connected with
URL routing to eventually serve that information through Jinja templating, which can then be sent to
the user.
And obviously, this goes both ways.
The user can then update information, which is then sent to the View, which updates the model, which
updates the database.
So it's not just one way the user can update, as well as Django and Python reporting back to the user
what the current status of things in the database is.
All right.
So the jingo structure will also have many more features not actually shown in that simple MTV diagram,
such as authentication and administration access.
So something we didn't really talk about here is the fact that Django comes with tools to make sure
that user has to be authenticated in order to view certain parts of a website.
Or maybe there's also administration access that comes already built in of Django, which allows a super
user to just directly jump to the database and see individual entries inside that actual SQL database.
And you'll see how awesome this feature is when it's pretty much it's just created for you automatically
from the Django framework.
So what are the actual jingo drawbacks, of course, right now, everything's super great.
Well, keep in mind that jingo itself is heavily reliant on this idea of that model, which connects
to the database and the model is this Python or Django representation of a table in that database?
What is really nice about this is that it makes it very easy to work with querying the data, but it
does add the requirements of understanding models pretty well and then setting them up for views.
So this is sometimes the steeper part of the learning curve.
Is that Django, in order to do a lot of the heavy lifting for you by setting up your SQL database,
those require the user itself to have some knowledge of how these models work within Django.
Now, of course, the purpose of this course itself is to make that easy for you.
So I wouldn't worry too much about the learning curve as a drawback.
Just keep in mind that there is this heavy reliance on the model structure, but I think when you get
more and more familiar of Django, you'll actually like this idea of having everything going through
the model because it applies a very specific workflow to the website or web application itself.
So what we can do now is continue our understanding of jingo by beginning to learn about these key components
separately and then slowly adding on complexity to a fully functioning website.
OK.
Thanks, and I'll see you at the next lecture.