A Simple Blog With Django

Note: This is based on a presentation I gave here at Logic Supply on 11/14/09, and is meant to be a beginner’s tutorial on using Django to create a simple blog.

What is Django?

Django is a web development framework (set of libraries and tools) for creating websites and web applications.

Why Django?

We use Django here for a number of applications and really love working with it. If you’ve used http://compare.logicsupply.com, that whole application is written in Django. We think Django is a major step forward for quickly and cleanly developing web applications.

Django Introduction

Django’s official website can be found at http://www.djangoproject.com. There you can read through the documentation (it’s really good) and learn how to install/configure Django for your platform.

I’ll be working on an Ubuntu Linux machine on the command line.  I’m not going to go over how to install Django since it’s platform dependent.  For information on how to install Django, go here.  I’ll be using Django 1.0, so that’s the minimum recommended version for this tutorial.  I’m also going to have my database already created so I won’t go over that here.  You’ll want to look up specific instructions on how to create databases for whatever database system you’re using. For the purposes of this tutorial I’ll be using MySQL.

All of the code for this presentation is available at http://www.logicsupply.com/pub/django_presentation.tar.gz (12/27/2012: This link is no longer available). You can either follow along and create your project/application as I do, or download the source now and look through it as we move along. You’re also free to take that code and do whatever you want with it. It’s warranty-free though, which means you’re on your own.

A Brief Tangent About Organization

Before jumping in and showing you code, I’d like to talk briefly about how Django is organized.  At a basic level, Django has projects and applications.  For now, just think of a project as a website, and an application as a specific part of a website.  For example, we may want to have a website that has a blog and a forum.  Our website would be the project, and the blog and forum would be separate applications.  For the purposes of this tutorial, I’m going to have one project (“my_awesome_website”) and one application (“blog”).

Django is loosely inspired by the Model/View/Controller (MVC) design pattern.  This influences how Django expects you to organize your code.  In Django, there are 3 major pieces you need to deal with: Models, Views, and Templates.

A model is a class that represents something you want to work with.  A good way to come up with the models you will need for any given project is to ask yourself,  “What are the nouns in my project?”  So for a blog, what are our nouns?  Well, most blogs have blog posts, so a Post will be one of our models.  Since a post should have an author, we’ll also have an Author model.  There are many other nouns that could (and probably should) exist for a blog, but since we’re just creating something basic, we’ll stick with these two.  Models usually have attributes; for instance, a blog post usually has a title, the date it was created, an author, and the actual body text of the blog post.  Likewise, an author should at least have a name and an e-mail address.  We can also describe relationships between our models; for instance, in a blog, a Post has an Author, and an Author can have many Posts.  You’ll see later on how we define this in Django.

Typically in Django, a model represents a database table, so when we tell Django about our models, it’ll know how to create the actual underlying database tables, and it’ll also give us some really handy methods for storing and retrieving data.  Anytime we create a new instance of a model and save it, a new row will be added to our database.

What about Templates?  A template describes a general format for how we want to represent data to our users.  In web applications and in Django, this usually means HTML.  More specifically, a template gives a description about how to represent data, but a template isn’t complete in and of itself.  A lot of times with web applications, we won’t know beforehand the exact HTML to send to the user.  For instance, every time we create a new blog post, we’ll want to show the user the post’s title, when it was created, the author who wrote the post, and the post’s body.  We’ll also probably want to show the user a list of all the posts we’ve ever written.  Since all posts follow the same format (title, date, author, body), we can create a template that outlines how ANY post should be displayed, and let Django fill in the specific details about a given post when the user asks for it.

In practice, this means that you create an HTML file with special parts inside that Django can look for and replace with actual data from the database.

So how do we marry models, which represent our data (Posts and Authors) with our templates, which know how to display them nicely to the user?  With views.  Views are the glue between our data in our database and what gets sent to the user.  A view in Django is just a function that knows what data to pull from our database (using a model) and what template to use to display that data.  Combining data and templates is often referred to as “rendering a template”, since we will replace parts of the template with actual data.  What this will mean for our blog is that we’ll have a part of our template that says, “Hey Django, here’s where you stick the post’s title,” and, “Hey Django, put the author’s name here!”

High-Level Overview

I think it would help to describe how the general flow of a typical Django application works.

Django Application Flow
Diagram note: I didn’t label the steps, but you can imagine we start at the top of the diagram on the right side and work our way down until we reach the database.  At that point, we start moving back up and to the left.  Don’t ask me why I did it this way…
  1. The user types a URL into their browser
  2. Django looks at the URL to determine what it needs to do
  3. If Django can match the URL to a view, it runs that view
  4. The view is responsible for using a model to retrieve data from the database, which it then combines with a template to generate HTML
  5. Django then sends that HTML back to the user

Getting Started

To get started with Django, you need to create a new project:

django-admin startproject my_awesome_website

where “my_awesome_website” is whatever you want the name of your project to be.  This creates a directory with a set of files inside for you:

__init__.py – This is python’s way of saying, “Hey, this directory is a module.”  If you’re curious about what a python module is, see http://docs.python.org/tutorial/modules.html
manage.py – This is a very handy script that Django copies into any project that you create.  It has many different features, and you’ll see how it gets used later on
settings.py – This is where we store all of our settings for our project; what type of database we’re using, where we store certain files, what applications we want this website to have, etc.
urls.py – This is how we tell Django what URLs map to what actions it should take to spit out web pages.  All this really says is, “When the user puts ‘www.myawesomewebsite.com’ into their browser, I want to show them a list of all of my blog posts, in reverse chronological order.”  We’ll see more on this later.

Now, that we’ve created our project, let’s create our blog application:

./manage.py startapp blog

Where, once again, “blog” is the name of the application we want to create.  This is very similar to “startproject”; it creates a directory with the following files:

__init__.py – See above for information about python modules
models.py – This is where we will store information about our models (authors and posts)
views.py – This is where we will create our view code

Now let’s start by defining our models.  Edit models.py in the “blog” directory and add the following code:

from django.db import models
 
class Author(models.Model):
    name = models.CharField(max_length=64)
    email = models.CharField(max_length=64)
 
    def __str__(self):
        return "%s (%s)" % (self.name, self.email)
 
class Post(models.Model):
    title = models.CharField(max_length=64)
    date = models.DateTimeField()
    author = models.ForeignKey(Author)
    body = models.TextField()
 
    def __str__(self):
        return "%s (%s)" % (self.title, self.author.name)

Let’s go through and explain what we’re doing here:

from django.db import models

Here we’re saying, “Go get me the models python module from the django.db package.”  The models module is going to give us a bunch of nice code to help us work with the database, so we don’t have to do it ourselves.  You’ll see how we use it below.

class Author(models.Model):

Here, we’re defining a python class called “Author” that is a child class of the models.Model class.  What this does is allow our author model to inherit a bunch of functionality for working with a database.

name = models.CharField(max_length=64)

Here, we’re defining an attribute for our author class.  We’re saying, “Hey Django, I want my authors to have a name and store that as a bunch of characters in the database (with a maximum length of 64 characters).”  Django will know what type of database we’re using when we configure our settings.py file, so it will know that in MySQL, a “CharField” should be stored as a VARCHAR field, and other low-level details that we won’t have to worry about.

The next piece of interesting code is in the Post class definition:

author = models.ForeignKey(Author)

What we’re telling Django here is that we want posts to be related to authors.  This is, in fact, going to be what’s referred to as a One-To-Many relationship in a relational database.  Basically what we’re saying is a post belongs to an author, and an author can have many posts.  By telling Django about this relationship, Django will give us some nice ways of dealing with our models and those relationships.

The last interesting piece is the “__str__” methods.  These are python “magic methods”.  The “__str__” magic method gets called whenever we ask for a string (str) represenation of an object.  So what we’re doing, for example, in the Author model’s “__str__” method is saying, “Whenever you ask for a string representation of an author, spit out the author’s name and e-mail address.”  You’ll see this later on.

Next we need to edit our project’s settings.py file.  By default, there is a lot of stuff in here, and you don’t really need to worry about all of it, so I’m only going to mention the important parts.

DATABASE_ENGINE = 'mysql'
DATABASE_NAME = 'blog_db'
DATABASE_USER = 'blog_user'
DATABASE_PASSWORD = 'asdqwe'
DATABASE_HOST = 'local-db01'
DATABASE_PORT = ''

...

TEMPLATE_DIRS = (
'/home/david.davis/my_awesome_website',
)

INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'my_awesome_website.blog',
)

Note: “…” means we skipped a bunch of stuff, as I only want to highlight the critical parts.

The first block of code you see up there is configuration for our database.  So we tell Django that we’re using MySQL, our database name is “blog_db”, and we give it credentials for logging in and using that database.  We also tell it the host on which the database lives.  As I mentioned before, you don’t have to use MySQL; you can use any of the other database engines that Django supports.  The database name, user, and password are whatever you want them to be for your application, and will need to be configured on your database engine.  Finally, the host is the machine that the database server is running on.  If you’re running the database server on the same machine as your Django project, you can simply put “localhost”; but, we’re running our database on another system here so I used that instead.

Next, we tell Django where on the file system our templates will live.  This, again, will be specific to your installation and platform.  Remember to use full paths here as well.

Finally, we tell Django about what applications we have installed (remember, settings.py is at the project level).  Don’t worry about the default installed applications for now; the important line is the last one, where we’re telling Django that we have an application called “blog” that lives in the “my_awesome_website” project.  These are, again, whatever you called your project and application when you first created them.

That’s it for configuration!  Since we defined our models in blog/models.py and we just told Django what and where our database is, we can tell Django to go out and actually create the database tables for our models.

./manage.py syncdb

Django will read our models.py file, and use the configuration information to go out and create our tables in the database.  If you made any mistakes defining your models, Django will tell you about them and won’t create the tables.  You can check if your model definitions are valid at any time by running:

./manage.py validate

Django will look at your models.py file and make sure the definitions are correct, and tell you if anything is configured improperly.

You may also be prompted to create a super user and password for your site; this will come into play later when we work with the admin application.  For now, enter whatever you like here.

Now that we’ve created our database tables, let’s put some test data in to see how easy it is to work with Django models.  (Note: This part requires that you have iPython, an interactive python interpreter, installed.  If you don’t, see http://ipython.scipy.org/moin/ for how to set it up and documentation on working with it. It’s a great tool!).

./manage.py shell

This should start an iPython session for you.  Next, we need to import our models so we can start working with them:

from blog.models import Author, Post

This is how you import classes/modules to work with them in python.  If you received no output, that means that the classes were imported successfully.  So, let’s see if we have anything in our database yet:

Author.objects.all()

This should return “[]“, or an empty list in python.  This is what you would expect; we haven’t entered any data into our database yet, so we get nothing.

One of the nice things you might notice is that we didn’t have to write any SQL!  This is one of the benefits of having our models inherit from the Django “models.Model” class; we get some nice convenient methods for working with the database.  So, as you might guess from the code above, we’re asking Django to go to the database and get all of the rows from the Author table.

Now let’s create an author:

dave = Author()
dave.name = 'David'
dave.email = 'david.davis@example.com'
dave.save()

If you’ve worked with Object-Oriented (OO) code before, this should look somewhat familiar.  We’re creating a new instance of the Author class, or a new author.  We then set some of the attributes on that class; namely, the name of the author, and the e-mail address.  Lastly, we call “save()” on that object.  The “save()” method is one we get for free because we are a subclass of the “models.Model” class, and its purpose is to write our new author information out to the the database.  Now if we run:

Author.objects.all()

We no longer get an empty list (“[]“), we get a list with one Author object inside, with the fancy string representation we defined earlier.

Now that we have an author, let’s create a post:

from datetime import datetime
first_post = Post()
first_post.title = 'First Post (w00t!)'
first_post.author = dave
first_post.date = datetime.now()
first_post.body = "Hello world!"
first_post.save()

This is very similar to when we created our author; we create a new Post object and we set a bunch of its attributes.  The interesting part here, though, is this line:

first_post.author = dave

Remember, “dave” is the author we just defined, so it’s a reference to an Author object.  When we defined our models in models.py, we said:

author = models.ForeignKey(Author)

So Django is smart enough to know that the “author” attribute on a Post object is actually a reference to an Author in the database.  This makes our life a WHOLE lot easier; instead of having to write a bunch of SQL and shuffle around IDs, we just say, “This Post object belongs to this Author object,” and Django does the hard work for us.

Let’s create a second post:

second_post = Post()
second_post.title = 'Second Post'
second_post.author = dave
second_post.date = datetime.now()
second_post.body = "I'm back!"
second_post.save()

So this is very similar to the first post, only we’ve changed the title, date, and body attributes.  Notice though that we’ve set the author attribute to be “dave” again.  This means that we’ve created a second blog post by the same author!  It’s as easy as that.  Now if we want to see all authors:

Author.objects.all()

We see that there is still just one author, but if we check all posts:

Post.objects.all()

We see that we now have two entries in our list!

One more handy thing; some blogs will have more than one author, right?

bob = Author()
bob.name = 'Bob'
bob.email = 'bob@example.com'
bob.save()

So we’ve created another author.   If we want to see all of the posts that this author has created:

bob.post_set.all()

This should return nothing; we haven’t created any posts for this author yet.  However, notice how we ask for all of his posts?  We call “post_set.all()”.  This works because of the relationship we established between our models.  Remember when I said that we have a “One-To-Many” relationship between authors and posts?  Well that’s what we’re using here; we’re asking Django to get us the set of posts that belong to author “bob”.  So, again, this is free functionality that we get from using the Django models, and we don’t have to write any SQL.

What about if we ask for all posts for dave?

dave.post_set.all()

We get a list back with both of our posts!

Alright, we’re done messing around with our models and iPython.  To exit, use Ctrl+d, and answer “y” to exit.

Now that we have some test data in our database, let’s tell Django about our URL structure by editing urls.py.  The urls.py file tells Django how we want URLs in our browser to map to a view.  Remember, it’s a view’s job to pull data out of a database, combine that data with a template (render the template), and send that back to the user.

We want the user, when they go to our website, to see a list of all our blog posts, with the most recent blog posts showing up first.  To do that, let’s add an entry to the urlpatterns like so:

urlpatterns = patterns('',
    (r'^$', 'blog.views.index'),
)

What we’re doing here is defining a pattern that, when it matches the path in our URL, runs a given view function.  Patterns are specified using regular expressions.  Don’t worry too much if you don’t know a lot about regular expressions; you can read more about them at http://en.wikipedia.org/wiki/Regular_expressions.  Django is smart enough to strip off the ‘/’ for us before we test for matches in our urlpatterns, so that’s why we can test for the empty string.

Anyway, we then tell Django which view function we want to run.  In this case, we refer to ‘blog.views.index’; that says “run the index function from the blog application’s views.py file”.  We haven’t defined that yet though, so let’s go do that now.

Edit your blog/views.py file.  It should, at this point, be completely empty.  Add the following:

from django.shortcuts import render_to_response
from blog.models import Post, Author
 
def index(request):
    all_posts = Post.objects.all().order_by('-date')
    template_data = {'posts' : all_posts}
 
    return render_to_response('index.html', template_data)

Let’s go through and describe what’s going on here line by line:

from django.shortcuts import render_to_response

First, we import a handy helper function from the django.shortcuts module called “render_to_response”.  This method is REALLY nice; it knows how to take a template and some data, mash them together, and spit out an HTML file with all of the special template code replaced.  So remember before when I talked about how Django renders a template?  That’s what this method is used for.

from blog.models import Post, Author

This line should look familiar; this is the same thing we did when we worked in iPython.  We’re importing our models so that we can easily pull data out of the database.

def index(request):

Here we’re defining a method called index.  Remember what we told Django before in our urls.py file?  We said, “When the user goes to www.myawesomewebsite.com, run the index function from blog.views.”  Well, that’s the function we’re creating now.  What did we say we wanted to do?  Get a list of all of the posts:

all_posts = Post.objects.all().order_by('-date')

So that’s all we’re doing here; grabbing a list of all of the posts in our database, and assigning them to the “all_posts” variable.  We’re also using the “order_by” function to sort the posts from newest to oldest (“-date” means “by date descending”).

template_data = {'posts' : all_posts}

Next, we’re defining a dictionary called “template_data” that will hold any information we want to send to the template and how the template should refer to that data.  We’ll work with templates shortly and go into more detail on how this works, but basically what we’re saying here is, “I have this thing here called ‘all_posts’.  When you render the template, anywhere you see the word ‘posts’, just use the data from ‘all_posts’.”

return render_to_response('index.html', template_data)

Lastly, we call “render_to_response”, telling it to use the “index.html” template and the template_data to render the template.  We then return the results of that, which should be an HTML file with all of the posts for our blog.

Okay, so the last thing we need to do before we can see this blog in action is define our template.  Above, when we set up our settings.py file, we told Django where our templates would live.  If you don’t remember, see “TEMPLATE_DIRS” in the settings.py description above.  You need to make sure you create the directory in the right place; I told Django that my templates directory would be called “templates” in my blog directory.  So, let’s create the template “index.html”:

{% for p in posts %}

{{p.title}}

Written by {{p.author.name}} on {{p.date}} {{p.body}} {% endfor %}

For the most part, this is standard HTML, but you’ll notice some interesting parts in here: namely, the parts with curly braces.  These are the “placeholders” in the template.  The placeholders will get replaced by Django whenever we go to our index URL with the data from the database.  Let’s look at this in detail:

{% for p in posts %}

What we’re saying here is, “For every entry in the posts list, do the following.”  So for every post that we pulled from the database, run everything between the {% for … %} and the {% endfor %} tags.  So that means for every post, display the following HTML with its title, author, date, and body.

{{p.title}}

In this case, we’re going to replace “{{p.title}}” with the title from the post object.  Don’t worry too much about the distinction between {{}} and {% %}; when we look at the HTML that gets spit out you’ll see the difference.

The other lines that contain “p.author.name” and “p.date” are similar; we’re just going to replace those with the actual values from the individual posts when we render the template.

Okay, now we’re ready to test this out!  Let’s briefly overview all the steps we took to get here:

  1. We created our project (“my_awesome_website”) and our application (“blog”)
  2. We told Django about our models by editing blog/models.py
  3. We told Django about our database configuration, where it should look for templates, and that we have a blog application in our project by editing settings.py
  4. We then told Django to create our database tables based on our models using ./mange.py syncdb
  5. Then we used iPython to play with our models and create some test data
  6. Next we told Django how to interpret URLs in our browser in order to present us with some data from the database by editing urls.py
  7. We then created the view we mentioned in urls.py by creating a function in views.py, which pulls data using our models and renders output using a template
  8. Lastly, we created the template our view method uses by creating a file called “index.html” in our template directory

That’s it!  Okay, so let’s see this in action.  Django comes with a built-in web server for development purposes.  To start it:

./manage.py runserver

That’s it!  If everything is working correctly, you should see a message like “Quit the server with CONTROL-C.” and the server will wait for requests from our browser.  The webserver also tells you what IP address and port the server is running on, so to get to our blog, copy and paste that URL from the server output into your browser.  If you’re running this on your local machine, then you can probably just go to “http://localhost:8000″, as 8000 is the default port.  If all is well, you should see two blog posts, with all the information we specified when working in iPython!  You now have a fully functioning, albeit very basic, blog.

Admin

Let’s go one step further though.  What if we want to add another blog post; how should we do that?  Well, you could fire up iPython again, but there’s an easier way.  Wouldn’t it be nice if we could just add posts and authors right from the site?  Well, luckily for us, Django comes with a built-in application called “admin” that we can use to do just that, and it’s really easy to set up.

First, we need to edit our settings.py file again and tell it we want to use the admin application.  To do this, add the following code at the end of your “INSTALLED_APPS” section:

'django.contrib.admin',

Your “INSTALLED_APPS” section should now look something like:

INSTALLED_APPS = (
'django.contrib.auth',
'django.contrib.contenttypes',
'django.contrib.sessions',
'django.contrib.sites',
'my_awesome_website.blog',
'django.contrib.admin',
)

That’s right, the admin is just another application, like our blog, except it comes with Django.  So for all those people out there who are paying attention, at the beginning of this article when I said we’d only have one project and one application: yes, I lied!  The admin application is technically a second application.

Anyway, next we need to add a URL to get to the admin section of our site, so edit urls.py and uncomment the line that looks like “(r’^admin/(.*)’, admin.site.root),”, or add it if it isn’t there.  This just says that any URL that starts with “admin/” should be handled by the views in admin.site.root.  We’ll also need to add a line like the following (after our imports is fine):

admin.autodiscover()

This is what allows us to use the “admin.site.root” module.  In case you’re wondering, admin.site refers to a sites.py file that Django automatically knows where to find.

Next, we need to run the syncdb command again, since the admin application has some database tables it uses (for things like users, permissions, etc.):

./manage.py syncdb

You should see a few tables get created, and if you didn’t create them before, it may ask you to create an admin username and password.

Lastly, we need to tell the admin which models we want to be able to manage from the admin interface.  In our case, since we want to be able to create Posts and Authors, we’ll register both, but there may be cases when you don’t want to register all of your models.  To do this, create a file called “admin.py” in your application directory (blog/admin.py) with the following contents:

from blog.models import Post, Author
from django.contrib import admin
 
admin.site.register(Author)
admin.site.register(Post)

The first two lines are simple; we’re telling Django to import our models and to import the admin class.  We’re then telling Django which models we want to manage by registering them with the admin module.

Alright, let’s fire up our web server again:

./manage.py runserver

Now, let’s take our web browsers to “http://localhost:8000/admin” (or whatever host/port is running the Django development server).  You should see a page with a form to log in; use the username and password you just set up.  You’re now presented with the Admin interface.  You should notice a couple different sections here; the “Auth” section, for example, is for managing the admin interface’s users and permissions.  The interesting section though is the “blog” section.  If you click the “Authors” link, you’ll see a list of all authors, where you can view, edit, and add new authors.  Let’s go back and click on the “Posts” link.  We see our two blog posts that we created from iPython.  Let’s add one more post.  Click on the “Add Post” button near the upper right.  You’re now presented with a nice form to create a new post.  Notice that Django is smart enough to give you different form widgets depending on the type of the attribute. For instance, our “date” attribute gives us a handy javascript calendar and time picker, and our “body” field is a text area, which is ideal for long form input.  Lastly, and maybe the coolest of all, the “author” attribute automatically gets filled with all of the available authors, and by clicking the plus icon next to the field, we can add authors on-the-fly and create a new blog post by them all at once.  This is all due to using the Django models.Model class.

If you want, create a new author by clicking the plus and filling out the fields.  Next, fill out the fields for a new blog post and select the new author we just created.  Then click save, and navigate to “http://localhost:8000″, and voila!  Our new blog post shows up at the top of our blog.

Summary

So, hopefully this has been a helpful tutorial.  You’ve seen how using Django models makes dealing with your database extremely simple.  You’ve seen how we can use templates to make generic HTML files that can be reused easily depending on what data we want to look at.  And you’ve seen how to wire these two parts together using views to pull data dynamically and present it to the user.  Lastly, we set up the admin interface to make adding new data super easy.

We’ve just scratched the surface of what you can do with Django; for a full rundown, see http://docs.djangoproject.com/en/dev/ (8/29/14 – link no longer available).

References

http://www.djangoproject.com
http://docs.djangoproject.com/en/dev/(8/29/14 – link no longer available)
http://docs.djangoproject.com/en/dev/intro/install/#intro-install (8/29/14 – link no longer available)
http://docs.python.org/tutorial/modules.html
http://ipython.scipy.org/moin/
http://en.wikipedia.org/wiki/Regular_expressions
http://www.logicsupply.com/pub/django_presentation.tar.gz (12/27/2012: This link is no longer available)
http://compare.logicsupply.com

This entry was posted in Applications, Technology and tagged , , . Bookmark the permalink.

17 Responses to A Simple Blog With Django

  1. Andrew says:

    Ah, glad to see you’re enjoying using Django. Python is a wonderful language to code in and I’ve used Django in a number of different projects to great success.

    What does the main site use out of curiosity? PHP? Java? ASP?

  2. david says:

    Hi Andrew,

    We use PHP for the main site. It’s been a nice change to work with Python for web development :)

  3. Thomas Wanschik says:

    Hi,
    really nice post. As far as i can tell from your post, source code is not downable :(, your Django blog should work on Google App Engine without any problems using Django-nonrel(http://www.allbuttonspressed.com/projects/django-nonrel).
    If someone plans to continue building this blog, please take into consideration making it non-relational database compatible.

    Again, really nice tutorial.

    Bye,
    Thomas

  4. david says:

    Hi Thomas,

    Thanks for pointing out the broken link, it should work now.

    I’m glad you enjoyed the post!

  5. Nicola Culli says:

    Hey

    Thank you so much this tutorial has helped me so much in my project!! and has helped me understand more as im only a django beginner!

  6. John says:

    Reallyy great tutorial:) i have a problem though, after i opened the admin page.. i clicked on Authors and Posts but they donnot work what do i do?
    Thanks

  7. Vinil says:

    i am indeed thankful for the nice post i tried this one for practice and successfully created in one shot .expecting some more great tutorials soon

  8. Kristina Bond Kristina Bond says:

    Hi Vinil,
    Great! That’s nice to hear :)

    Kristina

  9. Vinil says:

    but i am practicing with vies -templates only and not with admin panel .a customize cms is what you can say .so if you have some good code or tutorials ,let us know

  10. EngineeringDuniya says:

    Django is really nice. Benefitted by this tutorial. Thank you so much.

  11. shiva krishna says:

    The tar file that can be downloaded from the link (http://www.logicsupply.com/pub/django_presentation.tar.gz) is not working… It is saying

    /bin/gtar: This does not look like a tar archive
    /bin/gtar: Skipping to next header
    /bin/gtar: Exiting with failure status due to previous errors

    Can anyone please correct the format of tar file

  12. Erika Austin Erika Austin says:
    Logic Supply

    Hi Shiva,

    Thank you for bringing this to our attention. I apologize but we no longer have this information available as a resource. I apologize for the inconvenience and I will update the blog post to reflect the same.

    -Erika

  13. http://e-ureka.com/ says:

    Hi there, I want to join for this web site to obtain hottest updates, so where can i do
    it, please assist.

  14. Katrina VanTyne Katrina VanTyne says:
    Logic Supply

    You can subscribe to our newsletter via our homepage: http://www.logicsupply.com/ or subscribe to our blog here: http://www.logicsupply.com/blog/.

    Thanks!
    Katrina

  15. Alta says:

    Pretty nice post. I just stumbled upon your blog and wished to say that I’ve truly enjoyed browsing your blog posts. In any case I’ll be subscribing to your rss feed and I hope you write again soon!

  16. steve shepard says:

    Hi, I just “published” a working example based on the code; it may not be perfect, but it does work. Thank you very much for your kind blog post.
    steve

    https://github.com/scshepard

  17. Lila says:

    Also, like other Chromebooks it comes loaded with Gmail, Search, Hangouts
    and You – Tube. All genres are represented fairly well on this site.
    Just before the advent of studying how softmod wii, Nintendo gamers modify their consoles employing pricey mod chips to be able to play additional games or unlock the Wii’s other
    capabilities.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>