In my Django app, I have a lot of code so I have split up my source files and put them into sub-folders, as follows:
myproject/
myapp/
management/
__init__.py
models/
__init__.py
common.py
users.py
matches.py
questionnaires/
demographics/
templates/
__init__.py
models.py
views.py
...
views/
__init__.py
abstract.py
concrete.py
Now I'm confused what to put in INSTALLED_APPS. Is it all the folders containing models? Or all the folders containing source? If i include all child folders, do I also need to include the parent folder? Should this match what's in my my setup.py's packages argument?
Note: I know I could refactor this into multiple apps, but (1) I would like for all this functionality to have a common namespace since it's being redistributed and (2) I am regardless curious for the answer to my question.
Put the directory containing the models.py file, that is your "App". Django uses the models to bind to the database, everything after that is just filler.
The DJango startup is (very slimmed down) as such
manage.py
# The important part
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "path.to.your.settings")
This will define the important pieces, but lets look at the installed
settings.py
INSTALLED_APPS=(
'your.app.name'
)
Which basically states, you'll find my models.py there and some model definitions (they don't have to be defined, but models.py needs to exist)
your/app/name/models.py
class SomeModel(models.Model):
#... model definition ...
pass
Now back to your settings.py
Your source can live ANYWHERE because DJango looks in some very specific locations for certain things, but this is mostly configured in your settings.py
ROOT_URLCONF = 'path.to.urls' # this is the pythonic module path to your `urls.py` file
in your urls.py file you can define a url such as
url(r'^/some/url/def/$', 'some.other.module.handler'),
as long as handler from some.other.module returns a valid HttpResponse object and is on the PYTHONPATH it does not matter where the class lives.
Django has some specifics about management commands, they must live inside your app directory (the same as your model dir) so to define those (if your model.py file is inside a different location) you must put them in your data dir
For example I have a project with the following layout
/app
/data
/commands
some_command.py
models.py
/app
urls.py
settings.py
...other-source-files...
My settings.py simple says load the app data and point to app.url for the url configuration, from that point on it doesn't matter where your source lives (for the most part).
We did this so that our database tables would be named data_sometablename vs app_sometablename (i was not part of this choice, happened long before i joined)
Related
I am trying to use the "app-specific" approach to organizing various django apps. For example:
- app2
- __init__.py
- urls.py
- views.py
- templates/
- app2
- __init__.py
- urls.py
- views.py
- templates/
- manage.py
- settings.py
- urls.py
One issue I'm having with this though is where to put the base templates that everything inherits from? For example, at the top of all my templates I have {% includes "base.html" %}, but if I'm doing the above I don't see how I could do this in a logical fashion.
First thing first, You want "templates/appXXX/" for per-app templates (at least if you want to use "appXXX/template.html").
Second point: as you just found out, not all templates (and not all code FWIW) are strictly related to one given app. At one point you need to integrate your apps together to build a full website / webapp, and templates - specially the base template - are part of the project's "integration" layer. IOW: just create a templates directory in your project's root and put your base template there. That's what everyone expects anyway...
This kind of question is sometimes closed as primarily-opinion-base; I'll give my two cents anyways, because I think it is a valid question.
The structure I use is the following (successfully employed in some Django projects that have less than 10 apps inside each project):
In the first image you can see that for this project I started every app name with the prefix app_, but that is just an internal convention. Note: the folder .venv contains the Python virtual environment, and that folder is not version controlled (the other folders are part of the git repo).
In the second image you can see that I have a folder project_config that contains settings, base urls, middleware, routers and other stuff. Note: Django docs usually name this folder the same as the project (which would be tb_system_01 in this case), but I find the name project_config more meaningful for my use cases).
Then I usually use folders project_config/static and project_config/templates to store all the stuff that is common to the apps. Here also go my base templates, which would be my answer to the specific question you asked. The Django docs sometimes suggest using a top-level folder called templates, but for my use cases I found it more organized to have that folder inside of project_config/.
My team is starting a new Django project.
We want to start using git submodules in our new project. We've used submodules in previous projects and it worked great for us. The idea is to have apps, that we regularly use in projects, in a common folder as a git submodule.
Assume our git location is at git#mygit.git:repo-django
We have the apps (repo-django) in the root of the project like so:
/myproject
repo-django/
app1/
models.py
app2/
models.py
app3/
models.py
There is some debate in the team around how to structure the packages and I can't find any guides on what would be considered the best option in this regard.
Should "repo-django" be added as a class path so that imports of the modules can be relative to the root of repo-django or should repo-django form part of the class paths?
To use the models for example:
from repo-django.app1.models import MyModel
we can add the app to django like so:
INSTALLED_APPS += (
'repo-django.app1',
'repo-django.app2',
'repo-django.app3',
)
or if we add repo-django via:
sys.path.append("repo-django")
Then we can use the models like so
from app1.models import MyModel
...and add the apps to django like so:
INSTALLED_APPS += (
'app1',
'app2',
'app3',
)
The big debate is around namespaces. One camp argues that putting all the reusable apps in namespaces is a good thing while the other camp argues that the apps will be less portable and too dependant on the folder name.
What would be the best approach and where can I find more information on this?
This question makes in part reference to Django directory structure? .
How should I place the models.py in Django?
Project_name/
Application1/
models.py
Application2/
models.py
or
Project_name/
DB/
models.py
Which one should I use? why?
Daniel Roseman is correct, when running manage.py startapp appname, Django will automatically create a directory structure with a separate models.py per app like:
appname/
models.py
As well as being convention (if other Django developers come to look at your code, this is where they will expect to find your models) it also allows people to create reusable apps
e.g. by simply copying the appname directory I have all the URL patterns (if any), views, models, forms, tests and everything else, rather than having to pull out all the files from a large separate directory.
The first option is correct in Django each app has her own models.py or models directory.
How can I import all models in the settings.py in INSTALLED_APPS? When i`m trying to insert some model there is an error occurred: "no models named app1_model"
-ProjectName
--ProjectName
---models
----__init__.py
----admin.py
----app_1_model
----....
----app_n_model
---templates
---__init__.py
---settings.py
---urls.py
---wsgi.py
--manage.py
^ Structure of project ^
The INSTALLED_APPS is for apps not for models. Models are classes that live within your app, usually in /«app_name»/models.py.
I think you have misunderstood how a Django project is structured. Try working through a tutorial example.
a typical structure:
/«project»/«app_name»/models.py
and in settings:
INSTALLED_APPS = [ ... '«app_name»' ... ]
Your path will contain the base project directory, so you can import your app where you need it.
And to use them:
from «app_name».models import *
Although it is always best not to import *, instead, name the classes you wish to import.
To answer the question in the comment:
If you don't like the idea of storing all your models in one file (even though it is normal to do this), you can create a module called models. To do this, create a directory called /«project»/«app_name»/models, inside it put __init__.py (to declare it as a module) and then create your files inside there. You then need to import your file contents into the module in __init__.py. You should read about Python modules to understand this.
To answer the second comment question:
To view models in admin, you should create an admin file with model admin objects.
And finally:
Please read through the tutorials to ensure you have a thorough understanding of Django. Otherwise you're wasting your own time!
I've been developing in Pylons for a little while now and have recently learned they're merging with another framework to create Pyramid.
I've been looking over example code to see the differences and it's causing a bit of confusion...
For example, Controllers have been replaced by Views. Not a big problem... But what I find interesting is there's no directories for these. It's simply one file: views.py.
How does this new MVC structure work? Do I write all my actions into this one file? That could get rather annoying when I have similarly named actions (multiple indexes, for example) :/
Could you point me in the direction of some good tutorials/documentation on how to use this framework?
Since the various view-related configuration methods (config.add_view, config.add_handler) require you to pass a dotted name as the class or function to be used as a view or handler, you can arrange your code however you like.
For example, if your project package name were myproject and wanted to arrange all your views in a Python subpackage within the myproject package named "views" (see http://docs.python.org/tutorial/modules.html#packages) instead of a single views file, you might:
Create a views directory inside your mypackage package.
Move the existing views.py file to a file inside the new views directory named, say,
blog.py.
Create a file within the new views directory named __init__.py (it can be empty,
this just tells Python that the views directory is a package.
Then change the __init__.py of your myproject project (not the __init__.py you just created in the views directory, the one in its parent directory) from something like:
config.add_handler('myhandler', '/my/handler', handler='mypackage.views.MyHandler')
To:
config.add_handler('myhandler', '/my/handler', handler='mypackage.views.blog.MyHandler')
You can then continue to add files to the views directory, and refer to views or handler classes/functions within those files via the dotted name passed as handler= or view=.
Here is one answer that should be pretty straight forward. This question was asked when Pyramid 1.3 wasn't yet out. So forget about python handlers since the new decorator do a pretty good job now.
But just to start: Pyramid doesn't have any common structure. You could possibly write a whole app in one single file if you wanted. In other words, if you liked how pylons was structured, you can go with it. If you prefer to setup your own structure then go for it.
If your site doesn't need more than one file then...GO FOR IT!!! All you really need is that it works.
I personally have a structure like that
- root
- __init__.py # all setup goes there
- security.py # where functions related to ACL and group_finder
- models.py or models/ # where all my models go
- views.py or views/ # where all my views go
- templates
- modelname
- all template related to this resource type
- scripts # where I put my scripts like backup etc
- lib # all utilities goes there
- subscribers # where all events are defined
My view package might sometimes be splitted up in many files where I'd group views by ResourceType.
If you happen to use context to match views instead of routes. You can do some pretty nice things with view_defaults and view_config.
view_defaults sets some default for the class, and view_config sets some more configurations for the defs using defaults provided by view_defaults if present.