Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
I know a site can have many apps but all the examples I see have the site called ‘mysite’. I figured the site would be the name of your site, like StackOverflow for example.
Would you do that and then have apps like ‘authentication’, ‘questions’, and ‘search’? Or would you really just have a site called mysite with one app called StackOverflow?
Django actually has 3 concepts here:
Project (I think this is what you’re calling site): This is the directory that contains all the apps. They share a common runtime invocation and can refer to each other.
App: This is a set of views, models, and templates. Apps are often designed so they can be plugged into another project.
Site: You can designate different behaviour for an app based on the site (ie: URL) being visited. This way, the same ‘App’ can customize itself based on whether or not the user has visited ‘StackOverflow.com’ or ‘RackOverflow.com’ (or whatever the IT-targeted version will be called), even though it’s the same codebase that’s handling the request.
How you arrange these is really up to your project. In a complicated case, you might do:
Or, for a simpler project that wants to leverage an open-source plugin:
Aside from the fact that there needs to be a Project, and at least one app, the arrangement is very flexible; you can adapt however suits best to help abstract and manage the complexity (or simplicity) of your deployment.