We've been developing an application using django and django rest framework for a while now and we're reaching a point where our viewsets.py and serializers.py files are getting too large.
Our current structure is very similar to what many posts describe (eg. Large Django application layout) but they only seem to suggest creating new applications as the best route to maintaining manageable directories.
Our current set up is as follows:
project
app1
models.py
serializers.py
viewsets.py
...
app2
models.py
serializers.py
viewsets.py
...
For our use case, our models.py are small and discrete enough that I don't think we need to separate them out into separate applications, but I'm not sure what else we can do.
It's not really clear what you're asking here. Neither Django nor Django Rest Framework accord any special status to the file serializers.py; like views.py, it's just a place where you store things that are imported by other functions. So it's absolutely fine to split that file up in any way you like.
For instance, you could have a serializers package, ie a directory with many Python files in it (including a possibly-empty __init__.py); you could simply have variously named files in the app directory with different serializer classes in them; and so on.
Either split your app into sub application based on usage as mention above.
are you can split it based database like,
app->
tables->
models.py
viewset.py
serializer.py
views->
models.py
viewset.py
serializer.py
procedures->
models.py
viewset.py
serializer.py
Related
I would like to know if there is a way to include/import the models.py from the project directory to multiple apps without copying the model in each app. Thank you!
Every app must have its own models.py present in the app folder.You have models.py in an app folder you can write the following import statement in any file of your project:
from myapp.models import model_to_import
If you have models.py outside any app folder or any other folder, then make sure that folder contains an (with two underscores)init(with two underscores).py file and just write the following in the file you want to import:
from folder_name import models
from models import model_to_import
You could create an app which contains any models which you need project-wide, e.g.
python manage.py startapp projectcore
and then
from projectcore.models import MyModel
as needed.
But probably better to listen to Ludwik and try to restructure if you can!
You are not meant to put models directly on a project level in Django. Every model have to be associated with a particular app. On the other hand you can import models between apps.
If you feel a need for a project level models it just means you haven't partitioned your functionality into apps properly. There shouldn't be any reason to have "project level models" (or "project level views" for that matter). You just need to split the functionality into separate apps.
Let's say you are designing an intranet website for a school. You would have one app that deals with students' accounts, and another app generating timetables, and yet another one for an internal message board, etc.. Every app defines its own models (there are no "project level models"), but apps can import each others models (so message board posts can have a ForeignKey field pointing at student from the "students" app).
I have a flask project which allows users to create projects and to upload files to those projects. The URL structure looks something like /projects/<project_id>/documents/<document_id>.
My problem was that I was repeating /projects/ and /documents/ a lot for all the views that handled projects and documents (a view to list, a view to show, etc. etc.) so I thought that I could make life easier with blueprints. I decided that I could organize my code something like this:
app
projects
views.py
forms.py
__init__.py
documents
views.py
forms.py
__init__.py
views.py
__init__.py
run.py
However, there are forms (as well as pluggable views) that are used in both documents and projects.
My question is, how can I have code in common between my two blueprints? It's also possible that there's a way easier way to implement this (since all I really need is to avoid redundancy in typing out the URL), and I'd love to hear one.
Since you can have multiple documents per project and assuming that one document cannot be shared across multiple projects, I would suggest you only create a "Project" Blueprint and put the "Document" under it as a package. Something like:
app/
projects/
views.py
forms.py
__init__.py
documents/
views.py
forms.py
__init__.py
views.py
__init__.py
run.py
Now, under Projects/forms.py, you can add all the common code that is also relevant to Documents. Additionally, documents have their own forms.py but that could be very specific only to a document.
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.
I am learning Django. My background is from PHP and Java with experience using Model View Controller frameworks. I have always had a seperate file for each of my views, models, and templates - but the Django tutorial only mentions having one views.py and models.py.
That seems to be okay if you have a small application — what if you would like to organise your views and models by their purpose? For example, a Projects view and a Milestones view. I would hope that you would not have to create another Python package (app) for each view module:
python manage.py startapp projects
python manage.py startapp milestones
I can assume that you can have a milestones.py and a projects.py for your views and models instead of a generic views.py and models.py? Then models can be imported where necessary into the views, and requests routed to specific views?
There is no problem with having multiple files containing views and models.
In fact all you need is module views and module models. In python the module is either file that ends with .py or folder that contains file __init__.py.
The app can look something like:
app_folder
- views
| - __init__.py
| - some_view.py
| - some_other_view.py
- models
| - __init__.py
| - some_model.py
| - some_other_model.py
The models/__init__.py should look similar to code below (for submodules to be looked up by django at all).
from some_model import SomeModel
from some_other_model import SomeOtherModel
The only difference from the common approach is to have app_label defined in models:
class SomeModel(models.Model):
class Meta:
app_label = 'app_folder'
Check out the related doc entry.
Update:
The development version docs say you won't have to define app_label in this case any more starting with 1.7 release.
Afterword:
In fact if you need to do that it usually means your app is too big and you should split it into several apps. Most people who come to django are afraid of having many small apps. The more third party apps you read through the more you realize app should solve one and only one problem. In your example having app milestones seems perfectly legit.
I am refactoring a Django application. Specifically, I have an application with a big models.py file and I am trying to split it into a bunch of small files, like
myapp/
models/
__init__.py
somemodels.py
someothers.py
somemore.py
...
and in models/__init__.py I import all models from all other files so that I do not have to change client code.
The problem is that Django now complains about table names. Table for model Foo used to be myapp_foo, but it seems that Django now looks for a table myapp.models_foo. That is, it seems that it uses as prefix the package where the models are defined instead of their application (of course myapp.models is not registered as a Django application).
I know I could manually set the table name for each and every models, but is there a way to avoid this and tell Django that these models are actually part of myapp?
Use Meta.app_label