In every youtube tutorial I'v seen people simply add "app_name" to INSTALLED_APPS list.
Yesterday I started Official Django Tutorial and they suggest "app_name.apps.App_nameConf" notations.
Im guessing official way is a better way and it's not hard to memorize additional syntax, I just wanna be sure. Because stuff works ether way.
Please give me a simple, easy to understand answer so even I could get it. Thanks!
You are right, following official way is a proper way, since the created video tutorials or third party blogs may refer to the older version of the django and such way is deprecated now.
Good luck in your beginnings!
In INSTALLED_APPS one can specify all apps used in this django project app.
However, you can create multiple apps in one project. By default this would result in separate directories name in root project directory.
As all apps are in root project directory - this allows to specify only (their) directory name in INSTALLED_APPS.
On the other hand, we can specify full path to project sub-app AppConfig, not relying on auto-discovering / that sub-app is located in root project directory etc.
Multiple apps in one project?
Yes, multiple apps of one project are usually tightly coupled to this specific project and cannot be used outside of it.
The main idea is separation of concerns - to split the logic into separate sections, each responsible for some part of project app.
When your app starts growing, more different logic is being added to it, models.py / views.py / forms.py etc starts growing, making it difficult to read and understand project structure as a whole.
Even in small project - separating into sub-apps may be very helpful in terms of organizing things.
There are different styles of how to organize your django app, like where should sub-apps directories be located (i.e. in root directory, or in sub-directory with project name), and apps and settings directories can be located not in root project directory. In such cases being able to specify path directly to AppConfig class is nice and also more explicit, which is better than implicit.
default_app_config is mostly used in reusable apps - apps intended to be distributed and used by other people - published to pypi. This allows just add their name in INSTALLED_APPS, not full path to their AppConfig.
You should not use it in your project unless you know that you need it.
The polls.apps.PollsConfig is the newer, more explicit way, and it better allows multiple configurations of the same app.
The reason why polls works is that polls/__init__.py likely has a
default_app_config = 'polls.apps.PollsConfig'
line.
You have to activate your model, and Django needs to know that you have your app installed.
So in settings.py you need to add 'polls.apps.PollsConfig' in INSTALLED_APPS topic because in your app.py file you have likely defined a class PollsConfig:
In settings.py
INSTALLED_APPS = [
'polls.apps.PollsConfig,
'django.contrib.admin',
'<other app...>',
]
In apps.py
class PollsConfig(AppConfig)
name = 'polls'
Related
I am trying to change the admin HTML templates but I don't really now how to find the already created Django templates in the first place.
Is there an easy way to find all the templates?
Right now I am making new html templates and extending them to Djangos templates.
If you just look for an easy way to change the admin template you can use the django-admin-interface. You can change colors and it looks a bit more attractive. This works in my case pretty good.
pip install django-admin-interface
Is there an easy way to find all the templates?
Yes, they're all in the django/contrib/admin/templates/admin. You should be able to find the top-level django directory in the site-packages directory where you installed your Python packages. For example, if you created a .venv directory, it could be in .venv/lib/python3.8/site-packages/.
Otherwise, you could find the templates in the Github repository here.
The Django guide recommends copying those templates over to your own templates directory.
I started developing an addon in on ember-cli 0.2.1 and when I generated my files using the generator, they placed the files in ~/app/ and not ~/addon.
What do I need to do put the files in the right place?
The project contains services, mixins and utils with tests covering them.
I think it is the default behavior for a good reason: the generators are meant to be used in context of an application. You should consider your addon/ folder being sort of a lib directory, where you can use any file/folder structure that fits the best to your addon. The app/ folder, however, is meant to contain the re-exported modules, so they'll become available on the host app's container automatically.
Browse around a few well-written addons to find out how most people do this, a good example is the ember-radio-button
Here are all the modules
Then the only necessary modules are re-exported.
Notice that an abstact class like radio-button-base is useless by itself, and, therefore, unnecessary to reside on the container, but an addon user would want to import and extend it for his own purposes, which he can do by writing import RadioButtonBase from 'ember-radio-button/components/radio-button-base';
I am trying to reuse an existing django app, django-reviews. I set it up based on the instructions and the code is now under dist-packages.
>>> import review
>>> review
<module 'review' from '/usr/local/lib/python2.7/dist-packages/review/__init__.pyc'>
The other apps that I am writing are under my project's root directory, which is under version control along with requirements.txt
Problem
Some of the conventions are different between the app's code and my code. For instance,
1) the templates in the app extend {% base.html %} and my base.html is actually named {% "__base.html" %"}.
2) The url structure for signing in for the app is accounts/sign_in, but my current sign_in url is at "/log_in"
Question
Changing the code under dist-packages doesn't seem like a good solution, as it will be outside of my version control and it isn't in my project's home directory either. Changing my code to match the app's logic will be a problem if there is any other conflicting app in the future.
Should I instead use the source code as a reference and create a new app called review in my project's home directory?
What is the recommended approach when dealing with such issues?
Modifying code in the dist-packages directory is never a good idea. I only do it to debug packages I use, but never for a permanent change.
If you do need to change the source code of a package, you best fork the repository and make your changes. You can add it to your project the way you want it (as Git submodules, or just import it in your existing repository).
However, the idea of a django reusable app is that it's reusable for many purposes and you don't have to fork it to make it usuable for you. Maybe this app isn't configurable enough for you. You can try to contribute to this project to make it more configurable, so it's more accessible to more people. That's of course a little bit more work, but can be fun!
i dont remember this from 1.3 and i cant find it in the docs.
startproject appears to create both a project and an app underneath it. they've both got the same name.
python ./bin/django-admin.py startproject webapp
creates
/webapp/manage.py
and
/webapp/webapp/settings.py and others
anyone know why or link me to the page of the docco that explains this new behaviour? just skim read through the release notes and can't find anything.
I assume you are trying out 1.4b1.
This is infact the new project layout. It is mentioned in the release notes and they can explain it better than I can :).
https://docs.djangoproject.com/en/dev/releases/1.4-beta-1/#updated-default-project-layout-and-manage-py
It's not actually an app but more about tidying of default files. As such it is not in INSTALLED_APPS and will not be processed in the same way as an app. This is a trap I fell into when my custom templatetags weren't being picked up.
It's not creating an app. The directory inside is your project. The outside container is just a wrapper. manage.py has been move outside the scope of the project. See: https://docs.djangoproject.com/en/dev/releases/1.4/#updated-default-project-layout-and-manage-py
I have requirement like this:
On one server(linux) I need to run 2 instances of the same Django project (the same name, different versions). I've noticed that there is some conflict with settings module (both projects use the same file, which of course is wrong).
Do you have some pointers how to solve this problem?
Use one of the well-known techniques for selecting your settings module in your .wsgi file.