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?
A project refers to the entire application and all its parts. An app refers to a submodule of the project. It's self-sufficient and not intertwined with the other apps in the project such that, in theory, you could pick it up and plop it down into another project without any modification.
A Django app is a small library representing a discrete part of a larger project. For example, our blog web application might have an app for posts , one for static pages like an About page called pages , and another app called payments to charge logged-in subscribers.
Django is a high-level Python web framework that enables rapid development of secure and maintainable websites. Built by experienced developers, Django takes care of much of the hassle of web development, so you can focus on writing your app without needing to reinvent the wheel.
The main purpose of apps is, in my eyes, to provide logical separation of reusable components - specifically, a first-class namespace for models/admin/etc. - and to provide an easy way to turn things “on” or “off”.
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:
Project: StackOverflowProject App: Web Version Site: StackOverflow.com Site: RackOverflow.com App: XML API Version Site: StackOverflow.com Site: RackOverflow.com Common non-app settings, libraries, auth, etc
Or, for a simpler project that wants to leverage an open-source plugin:
Project: StackOverflowProject App: Stackoverflow (No specific use of the sites feature... it's just one site) App: Plug-in TinyMCE editor with image upload (No specific use of the sites feature)
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With