Welcome everyone to this lecture series on template directories now in the previous section at the very
end, we explore a basic way to connect a view to an existing template file that is an optimal file.
Usually, however, we would like to separate out template folders or directories based on their application
that they're relevant to, rather than have a single template folder for the entire project.
So separating out the template directories by app is more ideal because in the future, you may actually
want to reuse each and go up in a larger project.
For example, maybe you're working on a Django project right now for a social network, and it has a
photo Django app within it.
But then later on, you're working on a new Django project for a marketplace application, and you actually
want to have photos in that marketplace.
Having everything in its own app directory would make it a lot easier to reuse your photos, app and
a new project because all the templates were already included in that directory.
So that's why we don't typically have just a single templates folder for our entire Django project.
Instead, we separate it out per Django app.
Now, in order for the Django project to be aware of the app's template directory existence, we do
need to register that custom Django app in the settings that pie file under the installed app's variable.
And we're right now going to go through a series of steps, and the most important one for registering
these templates is this one going to installed apps and then fixing that within settings that pay for
the actual project.
So what I'm going to do right now is before we actually jump to our code editor is simply describe the
process to create a template directory for custom jungle app before you walk through it.
And as an important note, I'm actually going to add a bunch of steps that don't really do anything
for us right now for templates, but they are important later on for models.
So we're going to run them anyways, since this is going to be your typical workflow.
We don't technically know about models yet, but in the next section we will cover them.
And I don't want you to see this workflow for the very first time when you learn about models and said,
we're going to go through the steps right now, even though we're just dealing with templates.
So let's talk about these steps.
Step one you're pretty much already familiar with, which is the very basics of setting up a new Django
app.
You create the app directory with the Manage Sky Start app command, where you would just say managed
up high start app and then my app, first app or whatever the name of your application happens to be
within the project.
Then inside that app, you open up your URLs that I create views, not pie.
And then you go ahead and connect the views to specific URLs and you again have to remember to map the
actual app, your URLs to the project.
Your URLs recall we did that when we mapped things using the include function inside of the project
URLs file.
OK, so let's step one.
We've technically I've already done this all before.
Step two is running the migrant command.
And what this does is when you start dealing with models, you have to look at the Django project,
know which apps are going to be installed and updated within settings that pie.
So we end up running the Migrant Command Python managed up pie migrate.
And what this command looks like, it goes.
And inside settings, that pie takes a look and installed apps and creates any necessary database tables.
Keep in mind, this isn't technically necessary for us at this very moment, but it is a very typical
step as you begin to create models in your workflow.
So we'll go ahead and run it right now.
So again, that's Python.
Manage the pie.
Migrate.
Then step three, which is highly relevant to us right now, is actually go inside of Django app.
You check the apps that PY file that's created automatically for you and then you register the app config
class to the installed apps inside of settings that pie.
So step two really has to do if database tables and models.
Step three is actually doing that, linking to let your project be aware of the app directories, which
will eventually let it be aware of the template directory inside the app.
Now we have actually open apps that yet, so you may be a little confused by what I mean by app config
class, but once you open up apps that pie, you'll see something that looks like app config.
Essentially just take a line of code there and then stick it into the list of installed underscore apps
again.
Step three Most critical one.
But it makes a lot more sense when we actually see it inside the code editor.
So remember this step, but don't worry about it too much right now in detail because we will cut through
this.
Now, step four is to register the app and any database changes with jingo by running the following
command Python managed API make migrations and then the name of your app, such as My App.
Again, not super relevant for us until we've actually created models, but it's typically the next
line in workflow, so we'll go ahead and run it.
Then step five, we go ahead and run Python, managed a pie migrate again.
And that's going to create the model tables in our database.
Again, not really necessary for us, but it will be wants to create models.
Then finally, in step six or we end up doing which is highly relevant to us is create the actual templates
directory inside of our app directory with this structure.
So let's imagine we've created a new project called My Site, and then we created a new application
called My App, which lives inside our jingo project, my site within my app.
I'm going to create a folder called Templates previously created this templates directory at a project
level underneath my site.
Now I'm putting it inside my app, and then you'll notice I do something kind of funny here.
I create another subdirectory sharing the my app name, and then I start having my template files like
example the HTML or home.
That Page HTML index creates HTML page of each HTML, etc. This is where all those HTML files would
end up living.
So you're probably wondering what's the deal with having to use my app again when clearly templates
is already underneath my app?
Well, often you're going to have multiple template files with the same name.
So it's really common to have multiple files called indexed by each HTML one for each app index view
page.
So often, each application has its own little home page, which you'll often end up calling indexed
to each HTML.
Now, unfortunately, because of the way Django searches for matching template names, we want to make
sure we're actually getting the relevant template for an app.
So that's why we end up creating the app subdirectory underneath the template folder.
So that's why we do this to make sure that if anywhere else in my project or any other application,
I have an example that HTML, I don't accidentally get it confused by having it specifically underneath
the sub directory underneath templates underneath the app, so you can actually read the documentation
on this.
Again, there's a little note here you could technically get away with just saying my app forward slash
templates rather than creating a secondary my app subdirectory.
But again, Django will choose the very first template it finds whose name matches.
And if you have multiple applications with multiple templates that have the same name, you're going
to want to be able to further distinguish them, which is why we use that subdirectory.
That happens to share the same app name.
OK, so I know these steps may seem a little complicated right now, especially since none of them really
apply to us, except for the fact of setting up installed apps and then setting up our directory.
But we are going to go through them at the command line to get used to this workflow of running migrations
and making them.
So let's go ahead and go to the code editor, set up a new project, a new application and then set
up our templates to head over there now.
OK, so here I am at Visual Studio Code.
We are going to start from the very beginning, we always do this, but it is good practice to just
get the muscle memory, so to speak, of creating a project and a new application.
Here I am underneath an empty folder called Jingle Lectures.
I'm going to call Django Bash Batman and let's start a new project.
We do that by saying Start Project, and let's just call it my underscore site.
Again, you can call it whatever you want, but that initial command should set you up to have my site
and then the critical manage that pie file, which we can use to create an application.
So we're going to seed into my site and now we're going to create an application.
We run this by saying Python managed our pie and then start app.
Easy to remember because it's kind of similar to start project.
And then what we end up doing is typing out the name of your application.
I'm going to call it my underscore app.
You do need to remember this name later on, so keep that in mind.
OK, so now you should have my app.
And what we're going to do right now is create a simple view that connects to a template which technically
doesn't exist yet and then will map the URLs.
So underneath my app, go ahead and right click create a new file called URLs Dot Pie Hit Enter.
And let's also open up views pie.
So by default, you have render already imported for you.
So jingo essentially always expect you to be rendering a template usually.
So we're going to create a function and we're going to call it example underscore view it takes in a
request.
And then from there, we're going to return a render which takes in the request and then we connect
it to a template and this template is going to be located underneath.
My app forward slash, and then it's going to be example the HTML.
Something to keep in mind is this directory.
My app is not actually referring to the current my app directory that exists instead.
Eventually, we're we're going to do is have something that's in there.
My app templates, my app, for example, that each HTML.
So this my app example, HTML is going to be referring to this portion of that directory path.
What's going to happen is later on, we need to tell the Django Project Settings files.
Hey, by the way, we have this templates directory underneath my app, which is essentially what the
rest of the lecture is going to do.
But before we do that, we should connect this to a URL path.
So come back here to your URLs and let's go ahead and create that.
So URLs, we simply say.
From Jingo Dot Earle's import path.
From Dot's import views.
And then we create our URL patterns list.
And inside this list, we are going to call Path.
Empty string.
And connected to the views that's of views, Dot and I called it example view.
OK, so that's it for what's underneath our application.
We do need to connect this set of early patterns to our project level URLs.
So let's go ahead and open that up.
So we come to my site.
You URLs that pie on a project level again, the way you know it's at a project level is it includes
all these directions and we essentially need to follow this bottom one.
So we're going to add a new pattern here.
We're going to say path and let's have this be the path my app forward slash.
And then this is then going to include, let's make sure we have a comma there.
Comma include.
And it's going to be located underneath my app Dot.
You are else a really common mistake.
Here is two parts one you forget to actually import include.
So let's remember to import that.
And then to a really common mistake is to forget the comma that makes this a list.
So often I'll see students put this here as the first item, but then they forget that comma.
So then you get some error and this one's a little harder to debug because it starts thinking this is
some sort of weird long item that you're trying to define, and all you needed to do was put in that
comma.
So by far, it's probably the most popular error I see students make is they forget these commas inside
of the list that Django requires.
So go ahead and save that.
And we should be good to go as far as actually connecting that view on a project level.
Well, we still haven't done yet is we still technically don't have this if we go back to use this template
and this directory doesn't exist yet.
So let's begin our migrations that right now, some of them won't really apply to us, but they are
important as part of the general process, especially when we begin to introduce models.
So back here at the command line, I'm going to use the managed pie file and I'm going to say Python.
Managed by Migrate Hit Enter, and you should see a bunch of saying saying, apply, OK, etc. If you
get an error at the state, it's pretty much 100 percent a typo somewhere on your part.
Either you forgot a comma, you misspelled something, forgot an import, etc. So if you get an error,
just go back through the files.
Go back to this video slowly, and it's super easy to create a simple typo here that kind of messes
everything up.
So just keep that in mind.
However, if you get all these OK messages, you are good to go.
So we made our first migration.
We need to do now is actually tell the project.
By the way, we created this app and I want it to be installed.
How do we do that?
Well, you'll notice that when you created my app, there's this file called apps that pie that was
created automatically for you and the even creates this app configuration class.
And it's a really cool aspect is it converts your camel casing name to a or actually your snake case,
your name to a camel casing name.
So now we have this class that's automatically called my app config, and it drew that from our snake
casing of my app.
And what I need to do is go to my project's settings about Pi file and say, Oh, this is going to be
my installed app.
It does that through this app configuration class.
So we're going to do is go to Settings API and then go to where it has the list of installed apps.
And then what you're going to say is, by the way, I created this new app and here's its configuration
file.
So are going to pass in the new string.
The string starts off with my app, because that's the directory, this is under dot apps because the
file name itself is apps, not Pie Dot and then whatever this configuration file happens to be called.
So if you go to apps that pie, in our case, that would be my app config.
So I'm going to copy that.
Let's go to settings about pie.
And you can paste it in my app config.
Don't forget your comma here again.
Super common mistake that as you add in these apps, you forget that comma and then you get this kind
of weird error that's hard to debug.
Go ahead and save that change.
And this is kind of critical to let your project overall know.
You can start looking at this app directory to begin to connecting to templates and views and so on.
So now we're going to do is once you've confirmed that our configuration is inside our installed apps.
We're going to come down to our command line, make clear this and then we're going to say Python.
Manage that pie.
Make migrations and then the name of your application, which was my underscore app hit enter.
And if you don't have any models for now, you'll see something that says, Hey, I don't detect any
changes in app.
My app that should be the message you get later on.
We're going to get more detailed information when we actually have changes to a model and database.
Once you actually were to change things in a model and database and you wanted to post those changes,
the other command you would do is you would say python, managed pie and migrate.
We're going to go ahead and do that right now just to get the flow going.
But again, you should see, by the way, there was no real migrations to apply.
All right.
So we should be good to go.
And now the project is aware of the fact that if you scroll down here underneath settings that pie,
what's critical is I no longer need to worry about this directories structure.
Instead, I now have app directories equal to True, which tells Django on a project or app settings
level.
By the way, there's going to be a templates folder inside the application.
Feel free to check that.
So you have to make sure this is true.
It should be true by default, but just make sure underneath templates you have app directories is true.
OK, so that allows us to then do the following underneath my app.
I'm going to right click Create a new folder.
Call it templates.
It has to be called templates, so keep that in mind.
Then underneath templates, I'm going to create a new folder and I'm going to call it.
My app.
And again, this should start matching what we said here.
My app templates my app.
And then here I'm going to create a new file and let's call it example the HTML.
OK, we are good to go.
Now, what do we actually want to show inside?
Example that each time it's really up to you, but I'm not going to type in doc and this should autocomplete
which enter here and inside the body.
Let's make an one heading or header that says something like example each HTML templates connected.
Go ahead and save that change.
And now let's run the site.
Remember, this is going to show up at the actual my app, so it's going to be homepage forward.
Slash my app.
So let's run this.
We're going to see Python.
Managed pie run server hit enter.
Looks like we're actually good, live and running.
We bring in the actual website going to go to one two seven zero zero one.
8000 ports, and they bring in that browser, if you just go to the homepage, you should get a four
or four.
But remember, we're defining this underneath my app.
So then if you go to forward slash.
My app hit Enter Perfect.
We were able to connect our example HTML template.
If you get stuck on this.
Go ahead and check out our files and you can see if you had any typos there, but hopefully you're able
to get used to those steps.
These are the kind of steps you're going to be running all the time.
So if you ever get stuck, I would say just keep rewatching the video until you kind of memorize the
actual workflow and the steps, especially because we'll be running these steps all the time with models.
But hopefully that wasn't too bad.
All right now, though, we understand how to connect an HTML template.
We have a lot more powerful tools at our disposal to connect Django Python logic to HTML, CSS, static
files and so on.
OK.
Thanks.
And I'll see you at the next lecture.