Where would I put project based views that I've created for my django project?
For example - things like JSONResponseMixin?
I'd like to put them into a folder like my_project/views/generic/ajax.py - but I'm not sure how I would then call this within apps in my project?
Something like from my_project.views.generic.ajax import JSONResponseMixin doesn't work because it says there is no app "views"...
In django it is probaby best to follow the django way so a project is divided into apps, apps contain there modules (models, views, urls ...), you can however create your own local/utility/contrib app, it can just be a folder with an init.py and your modules. If you want to partition it further into directories (each sub directory I believe would need it's own init.py), you would have to then include it (the apps root folder) in your INSTALLED_APPS tuple and from there should be able to (afaik) import the module as you would have done for anything else.
Edit: Just found this answer to a somewhat related question, probably worth a read
Related
The PyCharm Pro IDE has a convenient feature called a Django Model Dependency Diagram, which visualizes the relations between your Django models.
However, every so often, this diagram turns up blank, or does not work at all, without any error messages (except in the logs). There's a related issue here: https://youtrack.jetbrains.com/issue/PY-39831
What could possibly cause the Django Model Dependency Diagram to turn up empty?
There are some causes I know of, although some are difficult to reproduce:
no custom apps registered in INSTALLED_APPS in settings.py
path to settings.py not properly set in PyCharm's File > Settings > Languages & Frameworks > Django > Settings (this may happen e.g. after using Refactor > Rename on the folder containing settings.py)
in some cases, diagram creation works for independent models.py files, but fails if models are imported
I've just started working on a codebase that the team I've joined is updating from using Django 1.4 to Django 1.8. Along with that change, it's being restructured into separate apps, and the layout is being changed in various ways.
INSTALLED_APPS has some apps, let's call them foo and bar, but their models.py files have been put into db subdirectories, that is foo/db/models.py.
Those models can be accessed from code (for example views) with from foo.db.models import SomeModel, and that seems to work.
However, from my reading of https://docs.djangoproject.com/en/1.8/ref/applications/#initialization-process, particularly stage 2, models defined in foo/db/models.py rather than foo/models.py won't be found during application loading, which will cause a variety of issues.
Is it possible to support this non-standard location of models.py with a custom AppConfig, or in some other way?
To clarify, I think trying to have models.py in a non-standard location is a bad idea; I'm after confirmation to help make my argument to the rest of the team.
The models submodule name is hardcoded, and it's the only module that is imported by Django during that step of the initialization process.
However, you can easily import your models inside your models.py file to ensure your models are imported at the correct time. If all your app's models are defined or imported in foo.db.models, you can simply use this:
# foo/models.py
from foo.db.models import *
I'm adding an application to a Django 1.7 project as described in https://docs.djangoproject.com/en/1.7/ref/applications/
What I'd like is just to add the application to INSTALLED_APPS but I don't know the best way to automatically include the applications urls. I'd rather not have to also add an include to the project's urls if possible. Can this be done?
There is no automatic inclusion of URLs, and I hope there will never be. Explicit is always better than implicit.
Honestly, it's just one line.
What really is the true meaning of django project and individual apps in it?
I mean - AFAIK you cannot create a project and live entirely in that project you created, you have to create an app in that project to be able to actually do something in django. Please correct me if I'm wrong.
Now what should really be the structure of a django project? I'm writing an e-shop. Let's say my project is named foo:
/foo
/foo
/settings.py
/templates
/urls.py
/wsgi.py
/shop
/__init__.py
/admin.py
/models.py
/tests.py
/views.py
and do everything entirely in /foo/shop/, but I edit urls.py inside /foo/foo/ etc.
I was following the Django Book, but I've begun to gain that strange feeling that /foo/foo/ is just for a main folder "stitching the thing together" but individual stuff should be done only in /foo/shop/, but not limited to. Preferably in /foo/web/, /foo/products/, /foo/forum/, /foo/controlpanel/, /foo/shop/, /foo/helpdesk/, /foo/backoffice/ etc.
Is that correct? Should I put everything products-related in /foo/products/, that including storage management, shipping, dealers, prices etc., then put management of those products (from the employee side) to /foo/backoffice/, which will serve as some sort of "django.contrib.admin" for this? Is that correct? Then if I want to host multiple instances of this (with completely separate databases and stuff) for multiple customers, should i only create a barebone project, that will put these things together, to configure the settings and then just move individual components in some sort of central repository and call them back in the project via INSTALLED_APPS? Because that would be cool as hell! I mean - making all the changes globally, not touching users data and configuration, unless necessary (adding columns in models and such). Is this how django is really supposed to be used? Or am I completely off the track and do things ENTIRELY wrong and this paragraph just doesn't make any django-sense?
I'm relatively new to this. I've been using PHP before and even though Django was a pain-in-the-ass to get basic grip of, I don't regret that and plan to deprecate and make offline any PHP project I created to date and replace them all with django. Well - where it makes sense and is not a single-purpose site. Not only because Django is awesome and versatile, but i cas I can scale it easily as well…
So… How should I really design Django projects, apps, and how to use them in production, providing them to multiple customers?
Thank you!
I mean - AFAIK you cannot create a project and live entirely in that project you created, you have to create an app in that project to be able to actually do something in django. Please correct me if I'm wrong.
You can do plenty of things on just a project, but you need an app for models to be auto discovered.
For example, I have a project with just this in urls.py:
class Homepage(generic.TemplateView):
template_name = 'homepage.html'
def get_context_data(self):
context = cache.get('homepage')
if not context:
management.call_command('reset_cache')
context = cache.get('homepage')
return context
urlpatterns = patterns("",
url(r"^$", Homepage.as_view(), name="home"),
)
You guessed it, it's a really basic website.
and do everything entirely in /foo/shop/, but I edit urls.py inside /foo/foo/ etc.
I was following the Django Book, but I've begun to gain that strange
feeling that /foo/foo/ is just for a main folder "stitching the thing
together" but individual stuff should be done only in /foo/shop/, but
not limited to. Preferably in /foo/web/, /foo/products/, /foo/forum/,
/foo/controlpanel/, /foo/shop/, /foo/helpdesk/, /foo/backoffice/ etc.
Well, you should define /foo/shop/urls.py, and import it from /foo/foo/urls.py ie.:
urlpatterns = patterns("",
url(r"^shop/", include("shop.urls")),
)
The point is to make your apps more convenient to reuse in other django projects.
Is that correct? Should I put everything products-related in
/foo/products/, that including storage management, shipping, dealers,
prices etc., then put management of those products (from the employee
side) to /foo/backoffice/, which will serve as some sort of
"django.contrib.admin" for this? Is that correct?
You should take a look at open source projects and see how they divided that.
According to the directory tree that you represented, you seem to have understood the point, but your statement seems fuzzy so I'll attempt to clarify it.
Apps are generally oriented around models. So if I make a product app it will probably contain:
Product model,
Product list, edit, create, delete and detail view
urls for the views,
Product admin,
tests for Product and views,
other things which are used by other django apps like product/admin.py would be used by django.contrib.admin, but also external apps like django-autocomplete-light would use product/autcomplete_light_registry.py and django-rules-light would use product/rules_light_registry
Then if I want to host multiple instances of this (with completely
separate databases and stuff) for multiple customers, should i only
create a barebone project, that will put these things together, to
configure the settings and then just move individual components in
some sort of central repository and call them back in the project via
INSTALLED_APPS?
There are many ways to do SaaS with django. But I agree that the easiest and most convenient is to maintain generic apps and build a project per customer that reuses (and eventually override parts of) these apps.
The Django documentation states the following clearly:
Not every template in contrib\admin\templates\admin may be overridden per app or per model.
It then lists the ones that can, and base.html, base_site.html and index.html – the ones I'm interested in – are not among those listed. They can be overridden per-project, but not per-app.
My question is: is there a way around this that doesn't involve editing the code inside django.contrib.admin? I'm willing to consider some monkeypatching solutions :-). I really want my app to have custom versions of those three files inside its templates directory, and have each project that uses the app to use those.
The reason I'm interested is that I'm creating a large, reusable app with a heavily customized admin interface, and per-project overrides of the "core" templates aren't the best solution, since I'd have to copy the custom templates to the template directory of each project that the app gets used in. Releasing new versions of the app with new modifications to those core templates would mean re-copying everything to the affected projects. Ugh.
I understand the reasoning behind the decision to only make a select few templates overridable per-app; after all, if overriding them all was possible, which app's overridden admin would take precedence?
But in my case, the app will be the "centerpiece" of several client projects, with other apps in those projects merely being in a supporting role.
CSS-based customization of the existing templates only gets you so far, and I'm hesitant to rely on JavaScript DOM manipulation solutions unless absolutely necessary.
One solution that comes to mind is to place the custom base.html etc. templates inside appname/templates/admin/ and then symlink them to the project's templates folder. That way any updates to the app will automatically take effect on the project level.
Symlinking is probably my method of choice if nothing better is suggested, but I'd like to hear if anyone has a nicer solution.
As I see your goal is to override templates for entire project, not for app or for model, but you don't want to put templates in project's template folder.
So you should just create 'base.html', etc. in 'your_app/templates/admin' folder.
Next you have to tell django that templates should be loaded not only from project's template folder, but also from your app's folder.
This can be done using TEMPLATES_DIR variable in settings.py file, smth. like that:
TEMPLATE_DIRS = (
os.path.join(PROJECT_PATH, 'templates'),
os.path.join(PROJECT_PATH, 'my_app','templates'),
)