Where to place plain python objects in a Django project?
I usually have plain python objects in my Django project that have specific responsabilities like observers, strategy objects, factories, etc. Where should I place those for a more organized file structure? There is a pattern in the industry for that?
django folder-structure
asked Jan 2 at 14:45
Julio MarinsJulio Marins
4,76542843
add a comment |
I usually have plain python objects in my Django project that have specific responsabilities like observers, strategy objects, factories, etc. Where should I place those for a more organized file structure? There is a pattern in the industry for that?
django folder-structure
asked Jan 2 at 14:45
Julio MarinsJulio Marins
4,76542843
add a comment |
I usually have plain python objects in my Django project that have specific responsabilities like observers, strategy objects, factories, etc. Where should I place those for a more organized file structure? There is a pattern in the industry for that?
django folder-structure
asked Jan 2 at 14:45
Julio MarinsJulio Marins
4,76542843
I usually have plain python objects in my Django project that have specific responsabilities like observers, strategy objects, factories, etc. Where should I place those for a more organized file structure? There is a pattern in the industry for that?
django folder-structure
django folder-structure
asked Jan 2 at 14:45
Julio MarinsJulio Marins
4,76542843
asked Jan 2 at 14:45
Julio MarinsJulio Marins
4,76542843
asked Jan 2 at 14:45
Julio MarinsJulio Marins
4,76542843
asked Jan 2 at 14:45
Julio MarinsJulio Marins
4,76542843
asked Jan 2 at 14:45
Julio MarinsJulio Marins
4,76542843
4,76542843
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
There's nothing like an "industry standard" here. Django does have some expectations about django-specific stuff (models, custom template tags and filters, management commands etc) and a couple conventions (the views and urls modules for example - you can technically name them however you want, but everyone expects them to be named "views" and "urls"), but everything else is just plain python code and can be organized however it makes sense to you. The only recommandations here are the obvious ones - high cohesion, low coupling, etc...
answered Jan 2 at 15:59
bruno desthuilliersbruno desthuilliers
51.4k54364
add a comment |
I can't comment on how widely this is adopted or if it is the right way, personally I follow the project structure outlined in the Two Scoops of Django book. A similar setup is outlined here https://django-project-skeleton.readthedocs.io/en/latest/structure.html as such:
[projectname]/ <- project root
├── [projectname]/ <- Django root
│ ├── __init__.py
│ ├── settings/
│ │ ├── common.py
│ │ ├── development.py
│ │ ├── i18n.py
│ │ ├── __init__.py
│ │ └── production.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ └── __init__.py
├── configs/
│ ├── apache2_vhost.sample
│ └── README
├── doc/
│ ├── Makefile
│ └── source/
│ └── *snap*
├── manage.py
├── README.rst
├── run/
│ ├── media/
│ │ └── README
│ ├── README
│ └── static/
│ └── README
├── static/
│ └── README
└── templates/
├── base.html
├── core
│ └── login.html
└── README
If I want to create objects and functions accessible to all apps I create a utils module at the app level. If I am creating utility functions and objects specific to an app I place the utils module in the app directory. Just personal preference really.
Hope it helps.
answered Jan 2 at 15:34
alfandangoalfandango
4616
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54008338%2fwhere-to-place-plain-python-objects-in-a-django-project%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
There's nothing like an "industry standard" here. Django does have some expectations about django-specific stuff (models, custom template tags and filters, management commands etc) and a couple conventions (the views and urls modules for example - you can technically name them however you want, but everyone expects them to be named "views" and "urls"), but everything else is just plain python code and can be organized however it makes sense to you. The only recommandations here are the obvious ones - high cohesion, low coupling, etc...
answered Jan 2 at 15:59
bruno desthuilliersbruno desthuilliers
51.4k54364
add a comment |
There's nothing like an "industry standard" here. Django does have some expectations about django-specific stuff (models, custom template tags and filters, management commands etc) and a couple conventions (the views and urls modules for example - you can technically name them however you want, but everyone expects them to be named "views" and "urls"), but everything else is just plain python code and can be organized however it makes sense to you. The only recommandations here are the obvious ones - high cohesion, low coupling, etc...
answered Jan 2 at 15:59
bruno desthuilliersbruno desthuilliers
51.4k54364
add a comment |
There's nothing like an "industry standard" here. Django does have some expectations about django-specific stuff (models, custom template tags and filters, management commands etc) and a couple conventions (the views and urls modules for example - you can technically name them however you want, but everyone expects them to be named "views" and "urls"), but everything else is just plain python code and can be organized however it makes sense to you. The only recommandations here are the obvious ones - high cohesion, low coupling, etc...
answered Jan 2 at 15:59
bruno desthuilliersbruno desthuilliers
51.4k54364
There's nothing like an "industry standard" here. Django does have some expectations about django-specific stuff (models, custom template tags and filters, management commands etc) and a couple conventions (the views and urls modules for example - you can technically name them however you want, but everyone expects them to be named "views" and "urls"), but everything else is just plain python code and can be organized however it makes sense to you. The only recommandations here are the obvious ones - high cohesion, low coupling, etc...
answered Jan 2 at 15:59
bruno desthuilliersbruno desthuilliers
51.4k54364
answered Jan 2 at 15:59
bruno desthuilliersbruno desthuilliers
51.4k54364
answered Jan 2 at 15:59
bruno desthuilliersbruno desthuilliers
51.4k54364
answered Jan 2 at 15:59
bruno desthuilliersbruno desthuilliers
51.4k54364
51.4k54364
add a comment |
add a comment |
I can't comment on how widely this is adopted or if it is the right way, personally I follow the project structure outlined in the Two Scoops of Django book. A similar setup is outlined here https://django-project-skeleton.readthedocs.io/en/latest/structure.html as such:
[projectname]/ <- project root
├── [projectname]/ <- Django root
│ ├── __init__.py
│ ├── settings/
│ │ ├── common.py
│ │ ├── development.py
│ │ ├── i18n.py
│ │ ├── __init__.py
│ │ └── production.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ └── __init__.py
├── configs/
│ ├── apache2_vhost.sample
│ └── README
├── doc/
│ ├── Makefile
│ └── source/
│ └── *snap*
├── manage.py
├── README.rst
├── run/
│ ├── media/
│ │ └── README
│ ├── README
│ └── static/
│ └── README
├── static/
│ └── README
└── templates/
├── base.html
├── core
│ └── login.html
└── README
If I want to create objects and functions accessible to all apps I create a utils module at the app level. If I am creating utility functions and objects specific to an app I place the utils module in the app directory. Just personal preference really.
Hope it helps.
answered Jan 2 at 15:34
alfandangoalfandango
4616
add a comment |
I can't comment on how widely this is adopted or if it is the right way, personally I follow the project structure outlined in the Two Scoops of Django book. A similar setup is outlined here https://django-project-skeleton.readthedocs.io/en/latest/structure.html as such:
[projectname]/ <- project root
├── [projectname]/ <- Django root
│ ├── __init__.py
│ ├── settings/
│ │ ├── common.py
│ │ ├── development.py
│ │ ├── i18n.py
│ │ ├── __init__.py
│ │ └── production.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ └── __init__.py
├── configs/
│ ├── apache2_vhost.sample
│ └── README
├── doc/
│ ├── Makefile
│ └── source/
│ └── *snap*
├── manage.py
├── README.rst
├── run/
│ ├── media/
│ │ └── README
│ ├── README
│ └── static/
│ └── README
├── static/
│ └── README
└── templates/
├── base.html
├── core
│ └── login.html
└── README
If I want to create objects and functions accessible to all apps I create a utils module at the app level. If I am creating utility functions and objects specific to an app I place the utils module in the app directory. Just personal preference really.
Hope it helps.
answered Jan 2 at 15:34
alfandangoalfandango
4616
add a comment |
I can't comment on how widely this is adopted or if it is the right way, personally I follow the project structure outlined in the Two Scoops of Django book. A similar setup is outlined here https://django-project-skeleton.readthedocs.io/en/latest/structure.html as such:
[projectname]/ <- project root
├── [projectname]/ <- Django root
│ ├── __init__.py
│ ├── settings/
│ │ ├── common.py
│ │ ├── development.py
│ │ ├── i18n.py
│ │ ├── __init__.py
│ │ └── production.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ └── __init__.py
├── configs/
│ ├── apache2_vhost.sample
│ └── README
├── doc/
│ ├── Makefile
│ └── source/
│ └── *snap*
├── manage.py
├── README.rst
├── run/
│ ├── media/
│ │ └── README
│ ├── README
│ └── static/
│ └── README
├── static/
│ └── README
└── templates/
├── base.html
├── core
│ └── login.html
└── README
If I want to create objects and functions accessible to all apps I create a utils module at the app level. If I am creating utility functions and objects specific to an app I place the utils module in the app directory. Just personal preference really.
Hope it helps.
answered Jan 2 at 15:34
alfandangoalfandango
4616
I can't comment on how widely this is adopted or if it is the right way, personally I follow the project structure outlined in the Two Scoops of Django book. A similar setup is outlined here https://django-project-skeleton.readthedocs.io/en/latest/structure.html as such:
[projectname]/ <- project root
├── [projectname]/ <- Django root
│ ├── __init__.py
│ ├── settings/
│ │ ├── common.py
│ │ ├── development.py
│ │ ├── i18n.py
│ │ ├── __init__.py
│ │ └── production.py
│ ├── urls.py
│ └── wsgi.py
├── apps/
│ └── __init__.py
├── configs/
│ ├── apache2_vhost.sample
│ └── README
├── doc/
│ ├── Makefile
│ └── source/
│ └── *snap*
├── manage.py
├── README.rst
├── run/
│ ├── media/
│ │ └── README
│ ├── README
│ └── static/
│ └── README
├── static/
│ └── README
└── templates/
├── base.html
├── core
│ └── login.html
└── README
If I want to create objects and functions accessible to all apps I create a utils module at the app level. If I am creating utility functions and objects specific to an app I place the utils module in the app directory. Just personal preference really.
Hope it helps.
answered Jan 2 at 15:34
alfandangoalfandango
4616
answered Jan 2 at 15:34
alfandangoalfandango
4616
answered Jan 2 at 15:34
alfandangoalfandango
4616
answered Jan 2 at 15:34
alfandangoalfandango
4616
4616
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54008338%2fwhere-to-place-plain-python-objects-in-a-django-project%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
