I have been following Django tutorials. It says I can create projects using the following command:
django-admin startproject mysite
And then I can create apps using
python manage.py startapp polls
This gives me a standard project structure. When creating real life websites/portal is this how project structures are? Are there other ways of creating projects?
In Django you can change the structure somewhat providing you add your apps to your settings.py file.
The structure is mostly just a recommended way, so you could choose to mess around with it, but most people don't mess around too much otherwise it will throw other people who are used to the standard structure.
You could take a look at how Ruby On Rails structures their projects for some alternative thoughts: https://www.sitepoint.com/a-quick-study-of-the-rails-directory-structure/
Related
I followed the polls tutorial for Django and am beginning my own hobby project today. When creating an app, the following really confused me -
Your apps can live anywhere on your Python path. In this tutorial, we’ll create our poll app in the same directory as your manage.py file so that it can be imported as its own top-level module, rather than a submodule of mysite.
So my question is - What is the difference between a top-level module vs a submodule for my project?
And how do I decide which one to choose?
Any help will be greatly appreciated as I am a noob coder working on my first hobby project lol.
There's no real other difference than matters of taste, organization, and naming.
For what it's worth, with my 10+ years of Django, I still generally like to just have the app packages parallel to the project package (i.e. what that passage suggests).
(It's occasionally also handy to make the project package an app, for some very core models such as custom users, etc.)
There are cases when it does make sense to have packages of interrelated apps, but those are generally for reusable apps such as allauth etc.
As the title states, I am curious what I need to know to make a website with Django.
My Attempts:
I am familiar with Python, but despite my attempts to begin work on a webpage(attempted some Django tutorials online and purchased "2 Scoops of Django" and started to work with some of its recommendations) I always feel like it points me at something else to learn. (PostgreSQL, git, virtualenv, VirtualBox, Vagrant, and more.) I understand that some of these are tools I just need to implement, but I feel as if I could delve into these much further and don't understand when I should stop trying to learn more about these.
My Goal:
I want to be able to develop a webpage with Django, and understand the steps and tools I am implementing.
My Question:
What tools do I need to learn, and how much about them do I need to learn to be able to begin working effectively with Django?
This is a very broad question but I can try to answer it as clearly as possible.
You said you are familiar with Python, that's a good thing. The next thing you should know is the MVC framework that Django is based on and uses extensively.
You can refer to Django tutorial here: https://docs.djangoproject.com/en/1.9/intro/tutorial01/ (as already mentioned)
I can give you a TLDR of how this can work:
1. Create a django project : $ django-admin startproject mysite
2. In the file structure that is created, the most important things would be:
a. models.py - your database models or schema defined as classes and objects
b. views.py - the view you are trying to display (mainly rendering .html in your case)
c. settings.py - you path, app setting, permissions, etc
d. urls.py - how you will be calling your specific views (redirect urls)
Once you write a basic app, try to run it using $python manage.py runserver and voila!
For the website part, there a few easy ways. You can download twitter bootstrap and try to attempt a simple page that you can find online with django http://getbootstrap.com/2.3.2/
As far as technologies go:
venv: is so that you do not mess up your other python, etc versions on your laptop, it isn't necessary
git: this is something you should learn irrespective of a project requirement. There are basic 3 commands that will be enough.
You might have to learn basics of HTML and CSS for manipulating your own website. Most of the backend can be handled on Django using objects of models you created.
Try these things out and let me know if you need anymore information.
In one of the apps of my Django site I require a third-party module/library. I've been reading up on how a good Django project should be structured but it doesn't mention much about storing libraries. My current project is structured like so:
urls.py
manage.py
settings.py
apps
app1
views.py
models.py
manager.py
tests.py
app2
...
...
...
...
Should a create a directory at the top-level named libs and dump it there or should I create a libs directory under the specific app folder that I'll be using this in?
Another thing was that when I code Django, I try and keep my views, models and managers very light. If some complex stuff is needed, I create a class/module and dump stuff there. Should I put this in the specific app folder that I'll be using this in or should this go to libs folder as well? I often have a helpers.py file in my apps but I use that for generally storing quite small and simple helper functions.
One could obviously put the library anywhere. It's all the same to Python but not necessarily the right way to go about this.
Thanks.
If this is a third-party library, it shouldn't be kept in your source code at all.
If you use virtualenv, you get a complete environment that you can install libraries in specifically for that project. Plus, in conjunction with pip, you can set up a requirements.txt file which specifies all the libraries you need to run the project, and installs them in one go when you start on a new machine, or deploy to production.
I am trying to get an overview of a Django website application structure. The way I have done this in the past with other frameworks (Symfony, RoR etc) is to look at the application folder structure, work out which bits go where, and then work my way on from there onwards.
I have been searching online for similar info about Django website folder structure - but have been unable to find one. Is there a recommended folder structure for Django apps? - and if yes, where I can obtain the document that details this?
Yes see
Folder structure for a Django project
also see
Writing your first Django app, part 1 - Creating a project
startproject script by default generates
mysite/
__init__.py
manage.py
settings.py
urls.py
Take a look at the tutorial on djangoproject.com - the directory structure is pretty clearly stated.
I think the philosophy was letting you have control over that. You can take a look at djangoproject's structure for inspiration:
http://code.djangoproject.com/browser/djangoproject.com/django_website
I am in a team developing a web-based university portal, which will be based on Django. We are still in the exploratory stages, and I am trying to find the best way to lay the project/development environment out.
My initial idea is to develop the system as a Django "app", which contains sub-applications to separate out the different parts of the system. The reason I intended to make these "sub" applications is that they would not have any use outside the parent application whatsoever, so there would be little point in distributing them separately. We envisage that the portal will be installed in multiple locations (at different universities, for example) so the main app can be dropped into a number of Django projects to install it. We therefore have a different repository for each location's project, which is really just a settings.py file defining the installed portal applications, and a urls.py routing the urls to it.
I have started to write some initial code, though, and I've come up against a problem. Some of the code that handles user authentication and profiles seems to be without a home. It doesn't conceptually belong in the portal application as it doesn't relate to the portal's functionality. It also, however, can't go in the project repository - as I would then be duplicating the code over each location's repository. If I then discovered a bug in this code, for example, I would have to manually replicate the fix over all of the location's project files.
My idea for a fix is to make all the project repos a fork of a "master" location project, so that I can pull any changes from that master. I think this is messy though, and it means that I have one more repository to look after.
I'm looking for a better way to achieve this project. Can anyone recommend a solution or a similar example I can take a look at? The problem seems to be that I am developing a Django project rather than just a Django application.
The best way that I have found to go about this is to create applications and then a project to glue them together. Most of my projects have similar apps which are included in each. Emails, notes, action reminders, user auth, etc. My preferred layout is like so:
project/
settings.py
urls.py
views.py
...
apps/
emails/
urls.py
views.py
...
notes/
urls.py
views.py
...
...
apps:
Each of the "apps" stands on its own, and other than a settings.py, does not rely on the project itself (though it can rely on other apps). One of the apps, is the user authentication and management. It has all of the URLs for accomplishing its tasks in apps/auth/urls.py. All of its templates are in apps/auth/templates/auth/. All of its functionality is self-contained, so that when I need to tweak something, I know where to go.
project:
The project/ contains all of the glue required to put these individual apps together into the final project. In my case, I made use heavy of settings.INSTALLED_APPS in project/ to discern which views from the apps were available to me. This way, if I take apps.notes out of my INSTALLED_APPS, everything still works wonderfully, just with no notes.
Maintenance:
This layout/methodology/plan also has long-term positive ramifications. You can re-use any of the apps later on, with almost no work. You can test the system from the bottom up, ensuring that each of the apps works as intended before being integrated into the whole, helping you find/fix bugs quicker. You can implement a new feature without rolling it out to existing instances of the application (if it isn't in INSTALLED_APPS, they can't see it).
I'm sure there are better documented ways of laying out a project, and more widely used ways, but this is the one which has worked best for me so far.
You should take a look at :
Django generic relations
Django reusable apps best practices if you want to re-use
GIT or any other CVS (git is great for maintaining + deployment)
Fabric if you need automated deployments/updates
I usually use this project structure :
/djangoproject
/apps
/main # the main code
/static # each sub app can serve statics
/app1
/static # each sub app can serve statics
/app2...
/scripts # manage.py, wsgi, apache.conf, fabfile.py...
/core # your libraries ...
settings.py
local_settings.py
Each app in /apps have an urls.py thats autoincluded in the main urls.py. And each app can be a git submodule (or svn external)
Also, using git, you can work on different parallels branches (master/dev/customerA/customerB...) and merge updates.
Creating real reusable is not so easy with django.
You can extract the common functionality into a separate module and make your apps depend on it:
my_portal
auth_module
profiles_module
application1 (depends on auth_module)
application2 (depends on auth_module and profiles_module)
I think the fact that a 'classical' Django project appear to 'contain' the apps it's using prevent you from seeing the picture - in fact, it's not necessary. For a project where you're going to have some sort of pluggable modules I'd suggest organizing the apps as eggs and using zc.buildout+djangorecipe to manage everything.
This way you'll be able to keep your modules in a flat one-level structure. Eggs have the ability to specify dependencies, so if you install application1 (see above), auth_module will be installed automatically.
Also it'll be easy to have different configurations deployed to different servers. Suppose, you have server1 which has application1 installed and server2 which has both application1 and application2 installed - you can just have two configs:
server1.cfg:
[buildout]
extends = base_deployment.cfg
eggs += application1
server2.cfg:
[buildout]
extends = base_seployment.cfg
eggs += application1
application2
djangorecipe also allows you to specify different settings files for each buildout config so you'll be able to add the necessary bits to the main project's urls and installed apps settings.
Not to mention, you can also have a separate config for development configuration (with debug=True and Django Debug Toolbar installed, for example).