Welcome back, everyone, to this lecture on Django applications or Django apps.
Jingo projects can have separated subcomponents called apps now, be careful not to get confused by
this nomenclature because we've already used the term web app or web application a lot and typically
a web app describes the full website or mobile application on the web.
And specifically speaking, a jingo app is a subcomponent of a single jingo project that web application.
So to try to clarify things instead of using the term web application from now on, when we're actually
describing the final resulting project, we're going to call that our website.
Since the way we present it here, it's pretty much always going to be a website in the browser so you
can think of the Django project as your overall website and then Django apps as subcomponents of that
website.
So again, it often becomes much easier to organize your coat through the use of these Django apps.
And it's Django app should cover a different key functionality for your website.
And you should also keep in mind that if you're just beginning as a solo developer with a very simple
website, sometimes it actually makes more sense to put every component of your website into a single
Django app, depending on how complex your final Django project is going to be.
The main use cases for separating your entire project into many Django apps is just going to be for
organization.
And also that way, other people looking at your code or yourself in the future can understand which
components are referring to which key functionalities.
So if we think about the jingo project structure, we have a single project and then within it, we
have different applications for different functionalities and you can have as many applications as you
want inside of a single project.
For example, let's say we're trying to create the next Big Social Network website, which is going
to be a single project then inside of the social network web site.
Maybe you have a couple of applications, like an application that's just focused on the messaging functionality.
User to user maybe have another application that's just focused on photos, maybe have another application
that's focused on video, etc. Hopefully, this gives you an idea of why it's easier to separate applications.
Imagine that social network website begins to grow, and we want to start working with other developers,
maybe a developer that is really good at VIDEO.
I don't want to put all this functionality into just some huge single folder, which has a single,
huge codebase instead.
I can separate out into jingo apps in order to keep these subcomponents organized by functionality.
Now, to create a new app, we end up using the managed pie file created by the project.
So we're to call Python Managed Pie star app and then your app name that first part that just calls
the manage that pie file to run a command line execution.
So we say python managed not pie.
Run that straight at your command line.
Be careful not to accidentally call Python by itself first.
Otherwise, that initiates the Python interpreter recall.
Here we're actually just running this as a python file with command line arguments.
And then the managed up.I file can accept many different type of command line arguments.
And the one we're working with here is the Start app, which is a specific command to run from the managed
pie file, something to keep in mind, as well as to make sure you're in the correct directory.
When you actually run this python, manage that py line.
And then after that, it's whatever you want to call your application, so again, your custom name
for your application, you should feel free to change it so it's relevant to the scope of an application.
Maybe you could call one messaging underscore app.
In other words, be video underscore app.
And then you would just run this line as many times as you need for different applications.
It often as a project grows, you start breaking up applications into sub applications, etc. So again,
this is really dependent on the scope of your project.
How many people are working with you on the project?
Typically, the smaller your project is and the more solo focus it is, you're going to have less applications,
the larger the project is and the more people you have working on it.
You're going to have more applications for organization purposes.
So we're going to do right now is we're going to create an example of an application and then we're
going to do a little bit of exploring to see how to connect it to our IRL view.
And I'll actually conclude this section and we're going to revisit all of this in the new section by
starting a new project from scratch.
So we're just going to very briefly cover views, URLs and Django applications.
We're going to have a much deeper dive in the next section where we specifically focus on views and
URLs and serving templates.
OK.
So let's go ahead and head out to Visual Studio code and show you an example of creating an application
and then actually rendering some sort of view through a URL on that application.
All right, so here I am at Visual Studio Code.
Well, we're going to do is create our first application.
We're going to write our first view, connect it through the URLs dot py file and then we'll actually
visit the homepage.
Again, we're gonna dive a lot deeper into things like views, URLs, templates and how that all works.
Right now, we just want to do the very basis of creating an application.
So the way we do that is first off, we have to make sure we're in the same directory as that man is
dot py file so you can do lists to list if you are on Mac OS or Linux, or if you're on Windows, you
type are run that and then just make sure that the output is going to match and say, OK, manage that
pie.
The reason this is so confusing sometimes is because recall we have these two folders.
My site and my site with the same name.
So often people are in the slower subdirectory of my site and they actually try to run managed up high,
which is actually inside this upper level folder.
OK, so I'm going to clear that out and let's run this.
I'm going to say Python manage dot pie.
And then what I'm going to do is, say, parsing the command line argument, start up.
And let's call this my underscore app.
Hit enter.
And again, no output in the actual terminal, but you will see that we now get a new application,
so we see we have my site.
These are project level PI files and then we're going to end up having a folder up here called my app.
And then we have in the admin apps, models, tests and views.
And if we wanted to, we could keep creating more and more applications.
So notice all your application folders are going to be underneath your very top level directory.
And then along with that, you're going to have this folder that has your project level settings.
All right.
Now, before we actually end up creating a new view for application, I want to take a little bit of
time to just go over in slide form what we're about to create as far as the files and directory structures.
Don't worry too much if the rest of this lecture goes over your head.
Pretty much all you have to learn from this lecture was that specific line of actually creating that
app through the Python managed up high star app.
And then your app name everything we're going to do right now for the rest of the lecture.
We're going to start from scratch and then show and talk about views and URLs and applications in the
next section of the course.
But just so you're not completely off.
Let me take a little bit of time to explain the three main things we're about to do inside of Visual
Studio code.
OK, so here I am back at the slides and we already learned that this critical line, which is pretty
much the one thing I want you to learn from this lecture, which is in order to create new application
you call Python, manage that PI start up and then your app name.
Now what are we going to do for the rest of the lecture?
We actually want to create a view inside an app and then connect it to the actual URL configuration
in order to view that view.
So how does this actually work inside our jingo project?
Well, recall have the My Site directory, and that includes specific files that are running on a project
level, so things like the settings on the project level or the administration on the project level.
And then finally, the you are LS on a project level and that's going to come in handy later on.
Now we also know I have the ability to create a bunch of applications app one, app two so on and so
on, all the way to number of apps like a message app, a video app, etc. Now, in our specific example,
we only have one application and for many simple Django projects, as you begin to learn Django, you're
just going to be single application Django projects, which is OK.
But something I want you to keep in mind is that this application is going to have its views that py
file.
And you can see that upon creating this application I've used up, my file was automatically created
for you.
Views, it turns out, is what's going to allow us to actually create something to be displayed inside
your browser.
You can think of a view as being analogous to a particular page on your website.
Now what I could do is directly connect.
This views that py file to the URLs on a project level.
But as we get more and more applications, this could start to get pretty confusing.
It depends on the scope of your project.
It is also totally reasonable just to do this direct connection if the project is small enough.
So you may see some projects just operate like this or the views are directly connected into URLs,
not pie.
However, for more complex projects, it probably makes more sense to create a URLs that py file inside
the application and then organize things there to connect to the views and then connect that URLs that
pie inside the application to the URLs that pie inside the site or project level directory.
So you often see something working like this or working like this when you have a larger project where
every single application not only gets its own set of views, but also gets its own set of routings
and URL configuration, which is later on connected on a project level.
And typically for larger projects, this is the easier way to organize things.
That isn't to say that this approach is completely 100 percent incorrect.
You will see this exists for smaller Django projects, but right now we're going to do is we're going
explore this particular organization structure, which is to create a view inside an application, rooted
it with its own URLs that pie file inside that application and then connect that to the project level
URLs.
Keep in mind the URLs that py file for the application is not automatically created for us, so we'll
have to construct that and create that ourselves.
OK?
Let's head back to Visual Studio code and complete these three main steps of creating the view cream
the URLs for the application and connecting that on a project level.
All right, so here we're back at Visual Studio code.
I'm going to open up my app, open up views, Dot Pi and let's create our first view.
There are many different types of views we can create, such as function based views or class based
views.
We will eventually move on to class based views, but for right now, just to learn the basics, we're
going to start off with kind of the simplest view possible, which is going to be a function.
We're going to call this function index.
It takes in a request to actually check out that view, and then we're going to return an HDP response
to actually return that response.
I do need to import this from Django.
So we say from Django, the 8TB import http response.
You can actually see we can actually return back things like a for a for a bad request, forbidden,
etc. So lots of things you can actually return here.
But we're just going to return a response which we can then pass in a string to and then that will display
on the actual page.
So we're going to return.
HTP response and then say.
Hello.
This is a view inside my app.
OK, so we save this and we have our very first view.
Again, we'll cover views and a lot more detail later on, but our returning is a simple HTP response.
Then we're going to do is inside my app directory.
I'm going to create a new file and this file will be URLs dot pie.
Make sure to create this inside my app, not inside my site, since that already exists.
So again, look at the pathway.
I'm out here.
My site, my app.
Your URLs, dot pi.
Then what we're going to do is the following I'll say from jingo dot URLs import path.
And because I'm in the same directory as my views inside my app, I can simply say from the import.
Views the other way you could do this to say from views import index, but typically you do it this
way so you don't need to call each individual of you by name.
Then we set up a Europe patterns list.
So I say you are.
All patterns is equal to a list and then you pass in the paths you want inside that list.
We really only have one view.
So I'm going to say path.
We pass in the string routing, which will be an empty string.
You'll see why later than we pass in the view we actually want to show that is that HDP response.
So we say views that index, remember our already imported views.
And then after that, you give it a string name, which will be more important later on.
But right now we'll just match it to the actual function name, which is typical.
OK, so we have your patterns and then we connected this path.
It's just going to be an empty string, which essentially means this is going to show up at forward
slash my apps when we later connect it to the project level URLs that PI file and you'll see how it
do that in just a second.
Remember to save these changes.
Then finally, we're going to open up your old stock pie and there my site says the project level.
You're all not pie.
You'll notice it actually has a bunch of directions on how to set up your views.
There is a function of use class based views and then including another URL configuration, which is
technically what we're doing in this last one.
So in the My App URLs pie, we set up a function based view connected to the URLs, which was actually
kind of the first instructions here, which is say, OK, import that particular view and then set up
the path.
You could technically do this a project based level and just set up views based on the project and not
even use Django apps.
Depending on how big your site is next, what we could do is separate out those URLs, as I mentioned
inside of my app, which then means we follow these directions.
We import the include function and then we just set up the path to include the URLs that phi pie file
for the application.
So we can come back up here and follow the directions and not import just path, but also import include.
And then I'll connect the application URLs up high file to my project URLs that profile.
This is quite simple to do.
We simply say path.
And then what?
Routing we want all those URLs to go to, which would probably go under my app.
And let's make sure it doesn't start with a backslash that's automatic, it should end with a forward
slash.
There we go.
And then we're going to pass in include.
And here we put in my app, the URLs, we just passed the Senate as a string Django Jingo smart enough
to connect, Oh, you have an application called My App Folder and then inside there you have a URL
stop py file.
So that's all done automatically by Django.
Again, don't worry too much if this line is going over your head, we're going to talk about it in
a lot more detail later on.
Lastly, don't forget this comma because this is a list you don't want actually get some sort of syntax
error with that URL patterns list.
Save that chains.
And we should be good to go as quick review.
We created a very simple, function based view inside of my app.
I created a new URLs that file also inside of my app.
Then I used my site level or project level URLs that profile and included and connected the other URL
configuration through these following lines of code.
Next, we're going to do is actually run the server, make sure you've saved all your changes and say
Python managed pie run server.
Hit enter.
And you should see maybe a warning about an applied migration.
Don't worry about that right now, since we're not working off any models.
Just go to one two seven zero zero eight thousand.
And I'm going to bring that right now.
And let me bring that in.
So you may get something that says if you just go to that homepage saying, Hey, page not found four
or four, I don't see anything.
And recall, that's because right now we only have views connecting to my app.
So actually, say the following forward slash my app for slash hit enter.
And now you actually see.
Hello.
This is a view inside my app.
So clearly still a lot more to learn because we don't want the Project Home page to just be, Hey,
this empty thing.
So we still have to connect other views for kind of a project level homepage.
But we do see how we connected a separate application on a project based level, so there's still a
lot more to come on views and URLs, projects versus applications, et cetera.
But you get the idea of how you would be able to break up your project into multiple applications,
and each application could include its own views and its own URL routing configuration filing.
OK, that's it for this lecture.
I'll see you at the next one.