The basic Django app contains models and views, however, this structure seems not enough for a complex web app. How can a designer accomplish a certain level of modulation with Django?
A complex web app can consist of many different Django apps. A Django app is basically a module centered around a set of URLs and/or models.
Besides that, it's all just Python. You can split off business logic code to any Python modules you want, put views in any modules you want, and turn models.py into a models/ package with submodules (as long as the package's __init__.py imports * from all the submodules, I think).
A Django project will often consist of many Django apps
When you start to build a "web app" with Django you are creating a project... inside this you will structure your code into one or more Django apps specific to your project. You will likely make use of a number of 3rd party reusable Django apps as well.
See the tutorial:
https://docs.djangoproject.com/en/dev/intro/tutorial01/#creating-a-project
Related
I have a dummy project, I have been told to create the admin panel of this project.
I don't understand what the admin panel is and what an app is in a django project.
I saw a project in which there were 3 or 4 apps and the admin panel, how are these correlated?
The django admin app is a pluggable application built into django that allows you to easily generate an interface where users with staff accounts can create, edit, delete, and view content.
The django admin itself is an app. The django documentation defines an application as:
The term application describes a Python package that provides some set of features. Applications may be reused in various projects.
Applications include some combination of models, views, templates, template tags, static files, URLs, middleware, etc. They’re generally wired into projects with the INSTALLED_APPS setting and optionally with other mechanisms such as URLconfs, the MIDDLEWARE setting, or template inheritance.
It is important to understand that a Django application is a set of code that interacts with various parts of the framework.
I am new to learning Django and I know how important setting up an application directory structure can be for future additions.
At the moment, I am creating an API using the Django REST Framework and have a few questions on how to structure a Django project for future success.
I want the API to feed out possibly in the future to other outside sources that may need to grab data. I also will be building a front-end CRUD like system to display and update data.
How would you suggest structuring the directories in the future possibility of adding more front-end like systems that are all powered by the Data API? Doing some research already, it seems like these are possibilities I have seen.
project
manage.py
project
settings.py
urls.py
api
models.py
serializers.py
views.py
crudapp
files here...
project
manage.py
project
settings.py
urls.py
api
models.py
serializers.py
views.py
crudapp
files here...
project
manage.py
project
settings.py
urls.py
crudapp
api
models.py
serializers.py
views.py
files here...
futureapp
api
models.py
serializers.py
views.py
files here...
I am really trying to understand how Django and Python should have these modules setup. If I have separate modules/apps setup, they can all access the models in the API app for any sort of app I build in the future?
Any clarification or experience on this would be greatly appreciated. The main goal is to have an API for the data in the database, and to then be able to build a front-end CRUD to update and pull that data, with the possibility that more front-end type apps could be built in the future as the data set grows.
For example, I am building a corporate data CRUD system to store important corporate information that will be accessible by a front-end and also an API that can feed to other non DJANGO websites. In the future, I may be adding an entirely different front-end/back-end CMS type system for a single page application. However, some of the data in the database from the corporate data set may be used to populate the website data.
i would take structure like this:
project
manage.py
apps
crudapp
futureapp1
futureapp2
so you can add as many apps as you wish and main project folder doesnot grow
and one more advantage is, your imports will be more beautiful and less name clashing in APPS:
from project.apps.crudapp.models import OneModel
# settings
INSTALLED_APPS = (
'project.apps.crudapp',
)
I want some clarity. I want to learn more about django and use it as replacement for php/laravel. But the default structure and convention of django confuses me a bit.
My PHP/Laravel project has 3 parts:
- Administration
- Core (Web app for regular users)
- API Service (REST-API for mobile apps)
However all of controllers, models and views are contained in a single Laravel application. I separated Auth, Admin, Api controllers into their own folders/namespaces.
One thing that confuses me is the default Django structure 1 view 1 model file. How should i go about reworking this application in Django should each of my controllers be a separate app in my django project or should I have same approach as in Laravel. 3 Django apps in one project one for admin one for core and one for api ? Where should I keep my models than since in Laravel all models are used by all 3 parts ?
My current structure:
./
./controllers/
./auth/
LoginController.php
RegistrationController.php
...
./admin/
ReportsController.php
UserController.php (Admins overview of all users)
...
./api/
HealthController.php (API CRUD for Health resource)
ExerciseController.php
HomeController.php
UserController.php (Regular users profile page CRUD)
...
./models/
User.php
Health.php
Exercise.php
...
One thing to remember about Django is that an app in Laravel doens't necessary translate to an app in Django. In Django, there are projects, and each project can have any number of apps. For example, I have a "Backup Admin" project where I manage a lot of the day-to-day issues of managing a tape backup environment. I have an app for media (that has 3 models, one for regular media, one for cleaning media, and one for media that we want to exclude from tape ejections). I have an app that represents the backup images, and another for backup jobs (to check status codes). Each sub-piece of my project goes into another app.
If I wanted to do another Django project that had nothing to do with backups, I'd make that a completely separate project, which would have a separate directory structure from my backup project. It'd have it's own urls.py, settings.py, etc.
Regarding the models piece, I put all of one app's models in the same file. For example, in my media app, I have models.py, which contains all three models that I mentioned above. This is completely optional, but I do it just so while importing these models into other parts of the project, I don't have to remember what the file names are, instead I can just do this:
from media.models import CleaningMedia,Media,EjectExclusions
Otherwise I'd have to have 3 different import statements if they were in different files. It's completely possible, but based on your preferences.
Regarding the controller, Django lets you do it either way. You have a project-wide urls.py file that you can use to control all of the traffic, or you can have separate urls.py files in each app to control that app's traffic. I prefer a single file, but that's just me. Personally if you have a lot of controller entries, you should probably split them up into app-specific urls.py files, just to keep it clean, but again, either method would work. I think of maintainability (especially with respect to teammates having to support it) when I make these types of decisions.
The admin interface is built-in, so there's not really an app for that, but you can decide which models and which apps have entries on the admin interface quite easily. Each app has an admin.py file that controls this.
A side note, for a RESTful API, you also might want to consider Django Rest Framework. It's a great piece of software, and the documentation (and tutorials) are very helpful.
Edit:
The 1 view/1 model thing again is just preference. You can have as many files as you want. The only trade off is when you import them into other files, you have to specify the file you're importing it from. That's really all there is to it. I know people who have a views/ directory, and inside there, have separate files for each view, keeping each class/function separate. Totally a matter of preference.
I like to keep my Django app organized and so I wonder where I should put the code of forms in? Should I write the code in the models file or should I create a new file (i.e. forms.py)?
Does Django have any guidelines for that I should use follow and where do most of the other developer put the forms in?
Forms are usually put inside the forms.py under a django app, just near the models.py. Though, if there are a lot of forms in the forms.py, you can make a package from it and split forms into logical parts.
Also see:
Django Applications best practices from LincolnLoop
An Updated General Django Project (>= 1.5) Structure or Folder layout
Good open source django project for learning
Open-Source Django projects
I want to add Django Sessions to my Django Admin, and I am following an SO post about this, but it is unclear where I store this code. Do I put it in an admin.py file? Under what directory?
In short, it doesn't matter. You can put the code into any of your apps' admin.py files. However, in situations like these I tend to use a generic app in my project, usually named something like utils, that exists for the sole purpose of housing code that doesn't belong to one specific app or could be used by multiple apps.
If you want to be more specific, you can create a sessions app in your project specifically devoted to this code and any other code related to session management for your project, or perhaps an existing app that is somewhat related. For example, I put customizations to the User admin in my accounts app that holds the UserProfile model.