According to the documentation:
An app is a Web application that does
something -- e.g., a weblog system, a
database of public records or a simple
poll app. A project is a collection of
configuration and apps for a
particular Web site. A project can
contain multiple apps. An app can be
in multiple projects.
However, what are other examples of what makes an "app"?
What makes an app (for us) is one thing:
An App Is The Unit Of Reuse
If we might want to split it off to use somewhere else, it's an app.
If it has a reusable data model, it's an app. User Profiles: App. Customers: App. Customer Statistical History (this is hard to explain without providing too many details): App. Reporting: App. Actuarial Analysis: App. Vendor API's for data gathering: App.
If it is unique and will never be reused (i.e., customer specific) it's an app that depends on other apps. Data Loads are customer specific. Each is an app that builds on an existing pair of apps (Batch Uploads, and Statistical History)
Django apps are bundles of reusable functionality. When starting off it's easy to just use one custom app for your project, but the "Django way" is to break it up into separate apps that each only do one thing. You can take a look at django.contrib for examples of really well made reusable apps.
A recent example of mine: a client needed a way to import CSV data into the Django models. The easiest way would be to just add a model with a FileField and write a quick parser for the specific format of what they are uploading. That would work fine until the format changed and I had to go make the parser match. But this is a commonly repeated task (importing data) and unrelated to the existing app (managing that data) so I broke it out on its own. This pluggable app can import data for any active model. Now the next time a client needs import functionality I just add this code to installed_apps and run syncdb.
It's a judgement call when to break out an app onto its own, but the rule of thumb for me is if I'm likely to do something again I'll take the extra time to make it a generic app. That means I've created some tiny apps (some just contain a template tag), but it's little overhead for the future gains.
User management could very well be an app, if you are not going to use Django's built in user framework.
It has user interfaces and defined models for stored data, and it is really separate from the Blog or the Wiki application (although the information will be shared).
As long as both applications are in the same 'project' they should use the same settings for the DB. You should be able to by just making sure the proper models are imported where you are trying to use them.
See this link for a little more information.
Related
I made an app(first app) with Django following a tutorial.
And I finally completed a web server with AWS EC2, nginx, uwsgi, mySQL, and Django.
Then I tried to make a new app(second app).
But I found that I put account information(user model) in first app's model.py. Furthermore, I added something like notification functions in first app's model and view etc...
I want to make new app with first app's account and notification, but I am not sure it's possible to split one app to two apps.
I'd like to make a site(project) have three apps which are account apps(including user model, notification, etc.), first app, and second app. Then, I thought second app can use user info like first app. (Is there any better way?)
I just have a questions, how can I split account app from first app without any data loss. Actually I afraid that if I make a problem, it's very hard to restore it. (model, view, url, ...)
My model is following
class Profile(models.Model) # I'd like to split into account app
class Recruit(models.Model) # stay in first app
class Apply(models.Model) # stay in first app
class Comment(models.Model) # stay in first app
I will appreciate if I can get some tips or references.
Thank you.
Create the new app
Move your models to them
Make migrations and fake migrate migrate --fake
Go to database and change the name of tables - Content types - permissions
for help use this one by me GITHUB script to change model names
Inform me if that worked well with you and don't expect it will be straight forward
Don't think about the app as isolated entity. The concept of the app is something that you want to distribute and let other developers reuse. This is not your case.
You refer the site as project and it's normal to have an app to import from another app. I would suggest you call them packages that are part of your projects, yes you add them in your INSTALLED_APPS but at the end are packages.
Try to have a good packages tree where the references are top-down and not crossed referenced.
Remember: you don't build the application for the database, you build it for the Domain, the database is just a Persistence implementation detail.
From this article.
In a project, I'm implementing using Django framework, I have two applications:
Application responsible for REST API, containing production models.py file.
Application responsible for Web client, that uses REST API's models.
Both of them contain vast static files and hierarchy of additional source code, that is why it came to my mind to split this responsibilities into two apps, rather than different views.py and urls.py files inside of one application.
Because application responsible for Web relies entirely on REST API's models is it a good practice to delete models.py file from this application entirely?
The file is only generated for your convenience. If you don't need it, there's no reason to keep it. No part of Django relies on it being present.
I'm build a Django app with a number of models (5-10). There would be an admin side, where an end-user manages the data, and then a user side, where other end-users can only read the data. I understand the point of a Django app is to encourage modularity, but I'm unsure as to "where the line is drawn" so-to-speak.
In "best practices terms": Should each model (or very related groups of models) have their own app? Should there be an 'admin' app and then a 'frontend' app?
In either case, how do the other apps retrieve and use models/data inside other apps?
Apps are logical separators. For example, if your site has blogs, polls and feeds, you might have blog, poll and feed apps. Each app might have multiple models (Blog and Post models for blogs for example), but be separated from each other by function.
You don't strictly have to separate things into separate apps if you don't want to. Splitting things into apps does help a lot with overcrowding. If you think you will grow beyond 10 models you might consider splitting up before it becomes too hard (django really doesn't like you to move stuff between apps).
As for accessing things from other apps, each app is a module, so all you do is
from app1.models import App1Model
and you are all set.
Python\Django is modular.
App should include just those models which usually solve 1 concrete task.
If some of models from p.1 can be usefull in other tasks, then probably would be better to create a new apps for those models. Ie if some models are shared between multiple tasks then there is a logic to make a new apps with those models.
For example you have a forum app. This forum has such features like, polls, registrations, PM, etc. Logically everything seems to be combined together. However, if your site is just a forum - ok, but if there are other content, for example blogs with comments, then "registration model" can be made as a separate app and can be shared between parts of site such as "blogs with comments" and "forum".
Regarding admin\frontend. Ive seen apps\projects with more than 10 models together. Based on the forum example above, if the admin part does not do any task out of scope of your app, then I would make admin and front-end inside of one app. Otherwise, if admin has any relation to another task, which is out of scope of your main app - admin should be as a seperate app.
After reading through How do you divide your project into applications in Django? and Django documentation about applications I am still not sure whether I should make or not a new application for certain stuff.
Let's imagine I have a Website with the following sections: <Home> <Login> <Register> <My account>.
Should all them be different applications? or should they be just one?
Also, imagine I include a section <Wiki> but it is not very linked with the page (I mean, not the design but the content makes relation to it).
Would this be a new project or application?
The individual sets of functionality (such as the ones you listed) should be applications.
When you group several applications together, you form a project.
However, the individual applications are usually self-contained enough that they could be picked up and dropped into another application. In this manner, you can re-use your 'login' application in several projects.
If it's part of the same site or webapp you're building, than don't make another project, one project shares the same settings.py, for example, so you can imagine that everything that relates to it belongs to the same project.
About the apps, you can create an entire project with just one app, but that's not advisable, you can separate your models in apps in a way that you fell confortable with it, for your own organization.
About login/register, take a look on User authentication documentation, that can clarify a little how one part of the site, in this case, authentication, can work with it's own app.
You should also do the Tutorial which could help you to understant how django basically works.
I am begginer in the Django world, I developed some "information sites" (nothing complicated) but this week my boss order me to make a migration of a big software that has 7 modules.
So I went to read the documentation page and search in google for how I could design this software using Django. I know that the every "module" can named as "app", so I create a new project and one app for every module (I dont know if it was right because the modules will not be public).
The problem is that now I don't know what is the next step.
All my apps can share data (every app has its owns models but sometimes one app has a model that was related to the models in other apps)?
Where do I write the code for the login process (I create a manageUsers app that was thinked to handle the registration, edit, share and validate profile of the current or new user ) and we can be able to share this session data accross the apps?
I need one more app for put the website information (like contact, about, pricing ...)? I use Python 2.7, Django 1.3, Memcached and Mysql 5.
If someone can help me or tell me where it may clarify these questions because most explains how to develop using only one app and in the IRC got no reply or else I must be write all the code in one app?
Best Regards
A good place to start (dated, but worth reading; look at user comment bubbles too): http://www.djangobook.com/en/2.0/ . Chapter 1 - 10 are essential reading. You can pick-and-choose to read the remaining chapters, if desired.
Yes, all Django Apps can share data with one another. You make multiple Django Application's, housed under a single Django Project. The Project sets up a common database to use, and each Application creates Models which use said database. App1 can talk to App2 and vice-versa.
Django Project (one) <----->> (many) Django Application
Typically you separate Apps based on common function. User accounts get their own app (see Auth below). Blog postings get another. A Google Maps interface will get another. User subscriptions, another.
For user accounts and login, Django provides the Auth Module. You can have user accounts stored directly in Django, or configure it to talk to something else, like Active Directory. Auth works "pretty good" out of the box, though I personally customized mine a bit to allow 255-character email addresses as usernames (by default, it limits to 40 characters). Chapter 14 in the Django book might be a little easier to read than the official Auth docs. If you do use Auth, you don't have to make your own Django Application, since Auth already is one! You just install it in settings.py and you're golden.
Your Django structure will likely look something like this:
/Project/
__init__.py
manage.py
settings.py
urls.py
App1/
__init__.py
forms.py
models.py
views.py
templates/App1/
template1.html
template2.html
App2/
...
App2 can access the data-models of App1 by doing: from Project.App1.models import someModel
For me, rules are simple.
If you need to copy-paste some code from one project to another - make an app for it
If one of app's modules code is bigger than 1k lines and/or hard to maintain - look for something to move in separate app
Group functionality into apps to minimize cross-linking between them
For interconnection you can use signals and sessions