Django for Designers/Starting our project: Difference between revisions

imported>Paulproteus
(Moved, and shrank the section headings)
 
imported>Aldeka
 
(4 intermediate revisions by the same user not shown)
Line 1:
== Part 1: Starting our project ==
 
<div class="instructor">This tutorial goes through the process of building a simple social bookmarking application, where users can save various URLs and tag those bookmarks to make them easier to find later. Our bookmarks application will be built on top of Django, a full-featured web framework written in Python.</div>
 
=== Activate your env ===
Line 15:
You'll know it worked because afterwards, you'll see <source lang="bash">(django-for-designers) $</source> at the front of all your terminal lines in that terminal window!
 
<div class="instructor">(What this did is activate a special Python environment that knows about Django and other dependencies for this tutorial. By keeping our dependencies inside a separate environment, we can keep them from interfering with any other project's dependencies--for instance, if you had one project using Django 1.4 and another using Django 1.5 on the same computer.)</div>
 
===Create a branch in your git repository===
 
<div class="instructor">If you're not familiar with git, git is a version control system that tracks changes you make to files within a git repository (the folder you just cloned). You make commits in git, which are like save points in video games -- the commit messages tell you what changes are included in this commit. If later on you make some changes and delete something or mess something up, you can always go back to a previous commit and try again.
 
Git also has "branches"--parallel timelines where you can go off from the main branch (called "master") and try something out. It's often a good idea to start a new branch when you're writing a new feature. You can make as many commits as you want inside the branch, and it won't affect the main master timeline. You can make as many branches as you want, and branches of branches. You can even share branches with others (though we won't be doing that today). Git's branching system (and its non-centralized architecture generally) make it easy to try out new ideas in code without having to ask permission of everyone else who might be working on the same code as you. Then, when your new feature is done, you can then merge (or rebase--the exact process would take a much longer explanation) the changes back into the master timeline.
 
We'll be using theseveral master branch (the default name for the main branch of code, which you're in right now)branches of the git repository you cloned during laptop setup for syncing up throughout the class in case you get lost. You'll need to make your own branches for playing with the code on your computer, so that it doesn't interfere w. re-syncing later.
 
We've created some branches for you to base your work on. You will use snapshots these as starting points throughout the tutorial. At the end of a section, you'll have your own completed work for that section available, but you'll start fresh from a pristine snapshot of what it would have looked like if you did it our way.</div>
 
To make sure you have the latest collection of thosebranches, run this command:
 
<source lang="bash">
Line 42:
</source>
 
Congratulations! You're now in a branch named my-branch-1!<div class="instructor"> (which is based off of our pre-made branch pre-part-1)</div> Notice that branches on your own computer have no prefix; branches that belong to useothers have ''origin/'' before their names.
 
You can see what branch you are in (and what branches are in your repository) at any time by typing:
Line 80:
* myproject/urls.py: The URL declarations for this Django project; a “table of contents” of your Django-powered site.
 
<div class="instructor">Django comes with some local server software included. The Django development server is not hardy enough for actual production use (please, please don't use it for sites other people are supposed to seeuse!) but it makes it easy to see the changes you make to your web app as you build it.</div> Let's make sure our project works by verifying that the dev server will start:
 
<source lang="bash">
Line 119:
Before we do anything else, let’s commit our work in git.
 
<div class="instructor">As you recall, git lets you create checkpoints over the course of the time a program is being developed. Commits are those checkpoints. Programmers often have to go back into the history of a program to change things--whether it's to diagnose a bug or redesign how a feature works. Programmers also have to have an easy way of being able to edit the same application at the same time, and to share their edits with each other. Thus, besides '''saving''' their work the normal way, programmers '''commit''' their code using version control software.
 
Each commit contains the '''diff'''--the "difference", all of the changes you made to your code base -- between that commit and the commit before it. Different branches in git share the commits made prior to the branching-off point, then each have their own commit history.</div>
 
To make a commit, first type <source lang="bash">
Line 138:
nothing added to commit but untracked files present (use "git add" to track)</source>
 
<div class="instructor">"Untracked files" means that git has noticed some new files inside its repository folder, but you haven't told git explicitly that you want it to "listen" for, and track, changes in those files. './' means that the folder we're in right now is currently untracked.</div>
 
* Add the folder:
Line 188:
<source lang="python">'NAME': 'database.db',</source>
 
Does database.db exist right now? <div class="instructor">(No, but that's okay. It'll get created automatically when it's needed.)</div>
 
Run git status, then git add and commit your change:
Line 200:
Even though git knows to "listen" to settings.py now, it still won't add it to the 'staging area' for your commit unless you tell it to explicitly with git add.
 
Notice the INSTALLED_APPS setting towards the bottom of the settings.py. <div class="instructor">That variable (a python tuple... note the ‘()’ symbols) holds the names of all Django applications that are activated in this Django instance. Apps can be used in multiple projects, and you can package and distribute them for use by others in their projects. Some apps (as you can see) are installed by default!</div>
 
Add South to our list of installed apps. (We'll need it later.)
Line 228:
When prompted, you’ll get a prompt asking you if you’d like to create a superuser account for the authentication system. Say yes! Use 'super' as your password for now.
 
Does database.db exist right now? <div class="instructor">(Yes! Calling syncdb made Django realize it needed a sqlite database file, so it made one for us.)</div>
 
Save and commit your work!
 
<div class="instructor">===Projects vs. apps distinction===
 
We’ve talked a little about Django apps and projects. You might be wondering what that nonsense is all about. Here are the things to know:
Line 243:
Most projects--those for more complex websites--should use multiple apps, one for each core piece of functionality. Ideally, you should reuse existing free, open source Django apps that other people have written for things like user accounts, image galleries, and other common use cases. [http://www.djangopackages.com Django Packages] is a good resource for finding such apps.
 
You can find prewritten Django apps for things like bookmarks and tagging, but we'll be writing them ourselves for the sake of learning. :)</div>
 
===Start your first app===
Line 303:
$ git add bookmarks/
$ git commit -m "Made a bookmarks app"</source>
 
 
[[Django_for_Designers/Basic_views|Next page]]
Anonymous user