Django's Double Folder Structure

Hi, I have a question. Instead of making templates folder in each app, why can’t me make a single template folder in main project directory, with separate directories for each app? This way, we can even have common templates under main directory.

Any comments?

Also, it was mentioned in slide that structure of ‘templates’ was within main project. But, PyCharm has ‘templates’ created under projects app. PyCharm - screenshot

Slide - screenshot

@abykal It’s a matter of preference. However, one advantage to keeping the templates in the app subfolder is portability. That way, you can reuse the same app, including its templates, in a different Django project.

Still a bit confused about directory structure (similar question to reblark). The portfolio directory in the main directory for djangos functionality, all config files are contained there. The projects (app # 1) folder is a specific web application with its unique, models, url routes, views, templates (html files to be rendered). Every other web application (app #2, app #3, app #4 etc....) will sit at the same level as the projects and portfolio, with their own unique models, url routes, views, templates (html files to be rendered). Why would we include multiple apps in the same overall folder (parent folder to portfolios, projects (app#1), app #2, app #3, app #4 etc.... Im assuming this has something to do with reusability, but from a security and deployment perspective wouldn’t this be counter productive when scaled?

Why would the templates folder of many apps be merged? Why would we merge multiple apps?

Hi @sndselecta! I think you understood the folder structure correctly:

portfolio/ # the django project folder
│
├── portfolio/  # the management app
│   # --snip--
│   └── settings.py
│
├── projects/  # a "normal" Django app
│   ├── __init__.py
│   # --snip--
│   └── templates/
│       └── projects/
│           └── # this app's .html files
│
├── another_app/  # another "normal" Django app
│   ├── __init__.py
│   # --snip--
│   └── templates/
│       └── another_app/
│           └── # this app's .html files
│
└── manage.py

About your other questions, let’s see:

Why would the templates folder of many apps be merged?

Because it allows Django to serve all the template content from a single source folder. This makes it easier to handle when it’s running.

In the end you’re serving one Django project - the project is your web app. I know it gets confusing with so many things being called an “app”!

You’re collecting all the templates from all your Django apps in order to serve them from one place for your whole Django project, which is the web app that you’re building and deploying.

Why would we merge multiple apps?

You’re never merging the Django apps. You keep the code for each of them separate because they represent different functional parts of your web application. And because it makes that functionality portable to other web applications.

What Django does, as mentioned above, is that it collects some of the content of each of your Django apps and serves them from a single location in your Django project.

This happens automatically when you use the built-in development server runserver.

Hope that helps to clarify things!

So ‘another_app’ is the same web application but another feature or just another view? If another feature can you give an example of what it could be? Also you are saying that everything in the parent portfolio folder is one web application. I think a better way to explain this would be to use more meaningful folder names, like:

parent --> portfolio/ (instead use) Web_application_1
parent.child --> portfolio/ (instead use) Web_application_1_management
parent.child--> projects/ (instead use) Web_application_1_func_main
parent.child --> another_app/ (instead use) Web_application_1_func_feature_1

The long names can be refactored to smaller, once the user has grasped the fundamentals of the folder hierarchy. Can u give an example of what you mean by “because it makes that functionality portable to other web applications”, i think in video it was referred to as pluggable. I understand why the templates being refactored into one main file as Ive done ruby on rails, which does the same for all html, css and js, so I understand that part. Thank you for the explanation so far.

Hi again @sndselecta.

Great, glad you found a way to reframe it so it makes sense to you 👍 I personally don’t find the long names easier to grasp, but learning and understanding is a personal process and different for different people. Thanks for posting your thoughts here, it’ll probably help some other learners as well!

As for what is a feature that deserves its own Django app, that’s a point of discussion and there’s no hard rule to it. You can find some good suggestions when you google for it, but as a rule-of-thumb you can create a new app when it’s a relatively separate topic from the rest of the Django project, e.g.:

• projects
• blog
• conferences
• etc.

These are all different aspects of a web application that would each benefit if you built their code in their own separate Django apps.

Pluggable Apps

Inside of each Django app, you define the models, views, routing, and templates. If you set it up in the way as discussed in this course, then you can literally copy one of your app folders (e.g. projects in my example), and paste it into another Django project (= another web application) that you built.

As a specific example: Let’s say you create WordPress themes for a living. You might want to display your projects not only in a portfolio web application, but also in an online store where you sell your themes.

You could create a new Django project that will be your e-commerce store and live on a different server and a different URL. It’ll be a completely separate web application than your portfolio site. However, because you built your projects Django app in a pluggable manner, you can copy-paste the app folder into your new Django project. Then you only need to:

• add the app’s name in settings.py
• route to your app’s urls.py file from the management app’s urls.py file
• make and apply the migrations

After that you’re good to go and you have all the functionality to display your projects in your new store web application, too.

Singular Template Folder

Just to clarify this, the templates don’t get refactored into a one main file, that might be a misunderstanding.

Django collects all the template files from all your Django apps and puts them into one shared templates folder. The files still remain individual files.

I see about the templates refactored into one file vs refactored into one folder. And just to confuse everyone further when you say pluggable you mean you essentially create an interchangeable web application which we can be used as an interchangeable template between different web applications so that you don’t have to rebuild that specific web application from scratch just modify a few settings and its good to go fully functionally into a completely separate web application. So each app folder (portfolio and projects) listed below is a completely different web application but the management app, is the settings for all the apps? If I copy projects to another web application folder then i would have to do the following for corresponding management folder (equivalent of portfolio/portfolio`

• add the app’s name in settings.py
• route to your app’s urls.py file from the management app’s urls.py file
• make and apply the migrations

portfolio/ # the django project folder
│
├── portfolio/  # the management app
│   # --snip--
│   └── settings.py
│
├── projects/  # a "normal" Django app
│   ├── __init__.py
│   # --snip--
│   └── templates/
│       └── projects/
│           └── # this app's .html files
│
├── another_app/  # another "normal" Django app
│   ├── __init__.py
│   # --snip--
│   └── templates/
│       └── another_app/
│           └── # this app's .html files
│
└── manage.py

Hm, I’m not sure, we might be talking past each other here? But it might just be a question of using the right terms, so let me try to clarify them here:

• Django project: This is a web application (= a website that has a dynamic component to it, meaning that content gets created at the request of the user). It contains one or more functional parts that are called Django apps.
• Django app: A distinct functional part of a Django project. There can be one or more of them for each project.
  • Management app: The first Django app that gets created when you set up the project is a bit different than subsequent apps. I call this one the “management app” because it contains e.g. the settings.py file that keeps the settings for your whole Django project.
  • “Normal” Django app: All other Django apps that you create explicitly with python manage.py startapp <appname> have the same structure. These apps contain a specific functional part of your project. These apps are portable (or “pluggable”), which means you can copy the folder and paste it in a new and different Django project that you created elsewhere. Then you need to do the steps described above to connect it within your new Django project.

Does that make sense and correspond with your understanding @sndselecta?