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.
Related
Is there a way to deploy Django Admin and your main application separately, though both of them sharing the same Models / Business logic services.
I come from Grails background where you can create a plugin which can hold your Entities and common business logic and that plugin can be utilized by other application deployed and scaled separately though using the same Database. You don't have to repackage your plugin again for every change rather its just sibling folder to your other projects.
Can I achieve something similar with Django?
Assuming a typical setup, in order to be useful Django Admin needs access to project's apps and their models.
So a setup that you've described would require at least:
simple URLconf with just Django Admin
models and their Admin bindings for all apps that need Admin
settings with database credentials
Even if your models and Admin bindings are not dependent on other parts of the codebase,
extracting the above components to a separate project and then keeping everything
in sync sounds pretty hard.
Summarizing: I would say it's hard but possible if it's something that you really need,
but Django Admin hasn't been designed with such use case in mind.
Django admin is actually separate from the main application by placing it on its own url. Even if they know the admin url, users cannot log in to the site's admin unless they have already been assigned Staff status via the admin. You can set the admin prefix to anything you want, so if you want to "hide" the admin login page, just make it something long and random (good for security too), and basically no one but those you tell will even know where the admin site can be found.
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.
Im really confused about what is all i need to consider for creating a django aplication with almost similar functionality to it's own admin.
The index page should deploy the list of models the user has access to modify or create...almost the same as when you put admin.site.register(MyModel) but with permission restriction. Im not sure how should i ckeck permissions, and show 1 ,2 or many "ModelAdmis" on my main page.
btw admin users are redirected to the admin index page, non-admins go to my page
Before you consider creating a django admin from scratch, you should read the answers to this question Django Admin app or roll my own?
I couldn't find any resource on how to create a django admin from scratch, but here's what you should do if this is your first time overriding a framework's functionality (in my humble opinion):
Understand and make sure you are comfortable with the django admin app
start from the docs https://docs.djangoproject.com/en/1.7/#the-admin
Head over to the django admin app source code so you can start reading the internals of the functionality you want to implement/override in your new admin app.
source code can be found here https://github.com/django/django/tree/master/django/contrib/admin
(this may involve reading other apps source code too)
After those two steps you should have an idea on how the admin app is implemented and it's dependencies, then you can start creating your custom admin app.
an example on how this may go can be found in this qestion:
How to override Django admin's views?
If you are building something new, try to separate the UI from the backend. You can build your UI using react, angular or whatever and interact with django using the API. To build the API you can use the Django Rest Framework.
Don't use the Django Admin as a public interface. Use that only for the admins!
If you start to use the Django Admin as interface for your public site, you'll fight with the package to tailor and secure the views to avoid destructive actions. What happen if you forget a readonly field? What if the user deleted something ON_CASCADE?
Building the UI you are totally free and you can customise easily everything without fighting the django admin package (it's awesome package but is not provided for public use)
Suppose you are building a Google website. (ok big dream)
Google has web search/youtube/email/news/etc ..
For this site, I'd like to structure my django directory like
Google/
search
youtube
email
news
and so on.
How do I structure such a site?
Create an app for each even though I'm not expecting to publish any of the category as an app?
Where would a common stuff (such as user model, utility modules, decorators..) would go, create a common_app?
Applications are reusable components for a django project that revolve around a central purpose. Applications don't need to map directly to your url structure of the website. While there is a standard structure for a django application to tie in with some of the management commands, such as tests.py, models.py, static files at /static/ you don't need to have any of it to be an application. For example, South is a popular django application used to provide database migrations. It adds a few management commands to manage.py.
When you are adding functionality and it doesn't map directly to the purpose of the application, just create a new one. So instead of thinking of it a a common_app, think about what the purpose of the application would be and how it might be utilized by your other applications.
In my projects, I tend to create a base application to handle the base template and static assets that are used in the base template. I'll create an accounts application to handle the user model and implement things like password reset. To deal with global notifications from any part of my site, I'll create an alerts application. The list can go on for a lot of the common functionality, but it's grouped in a way that revolves around a function and written as if it would be distributed.
So, in your specific case, you'll likely have at least an application for each of the domains such as search, youtube, email, and news, but also an application for each common component you might want to use across your core domains.
I will be brief: to work in the spirit and idea of a Django app, it is ok for an app to import models from inside another app ? Say, a User statistics app will import models from a User app something like: from users.models import users
The answer is yes. It's perfectly okay for one application inside your django project to import models from another application. The power of a django project lies in the apps and their interactions.
Also make sure that you have utility applications importing models from more generic applications and not the other way. So "userstatistics" app should import models from the "users" app but "users" app should not rely on the "userstatistics".
If your app is importing models from a 3rd party application (lets say django-piston), be sure to specify that in a requirements file.
If you're building an internal app that has no chance of ever being released to the public, sure, do whatever you want.
If you're building an internal app that has little chance of ever being released to the public, but will possibly be used by future/current developers, sure, but be sure to document what the app needs to work properly.
If you're building an app for public release, try to keep it self-dependent (and django-internals dependent, ie, use what django provides, when possible). If you really need a third-party app to work, or if a third party app would make your code more manageable, then sure, include dependencies, but be doubly sure to document all requirements and necessary setup.
In most cases, you can do almost whatever you want so long as you have sufficient documentation.
I do, however, have to question the sanity of making your own User model that has the same name as django's builtin auth.User.
You cand try better extending the Django User model with inheritance. You will use the django user with custom field added, so you will have the same user for all the apps.
You can directly import models in app2/models.py. Usually you might need a foreign key, which looks like
models.ForeignKey('app1.ModelClass1', on_delete=models.CASCADE, related_name='modelclass2')
Don't do this. They will have the same app name and the ORM will be confused. Use an abstract model instead, and have both derive from it.