Create your first SourceUrl object.

We have defined our model and created the database tables. But we still didn’t completed the User Story we’ve defined. Using Django, having our model, we’ll just let the framework do the job.

Other frameworks like Ruby on Rails and Grails follow the Convention over Configuration paradigm for that purpose. Django is a little different. Instead of providing a scaffold for forms and display pages, it do provide an entire backend, the admin site.When you design a web application, you have the public site where visitors can access your content, but you also need a Staff Only area where site managers can manage the content. The admin site is mandatory, but usually, it is a tedious uncreative work. Django automates the creation of admin interfaces so you can add and browse the content, without any wast of time for such common features.

The admin site is not activated by default. Do you remember the line 9 of the INSTALLED_APPS code snippet ? To activate the admin site, you need to

• Uncomment the corresponding line in the INSTALLED_APPS setting.
• Since you declared an new application, Django needs to create new tables, so run asyncdb.
• Edit the myprivatesite/url.py file to uncomment the lines that reference the admin site. Ok, this is new…

What is the url.py file? It is the module where we’ll define the mapping of URLs to applications. To activate the admin site, the url.py file should look like this:

from django.conf.urls import patterns, include, url

# Uncomment the next two lines to enable the admin:
from django.contrib import admin
admin.autodiscover()

urlpatterns = patterns('',
    # Examples:
    # url(r'^$', 'myprivatesite.views.home', name='home'),
    # url(r'^myprivatesite/', include('myprivatesite.foo.urls')),

    # Uncomment the admin/doc line below to enable admin documentation:
    # url(r'^admin/doc/', include('django.contrib.admindocs.urls')),

    # Uncomment the next line to enable the admin:
    url(r'^admin/', include(admin.site.urls)),
)

Once you’ll have done those 3 steps, you can launch your development server.

python manage.py runserver

Now you can be tempted to connect to the front page of your site. That’s fine, go ahead, if you kept the default, go to http://127.0.0.1:8000/. The It Worked page just became a 404, page not found. This is because, since we uncommented the line 16 in the previous code, Django tries to serve you the page corresponding to its patterns. And the only available pattern is: http://127.0.0.1:8000/admin.

Before entering the admin section, you have to give your credentials. Those are the one you have set up when you first ran the syncdb command. A superuser is created the first time syncdb is run with django.contrib.auth. If you forgot the password, you can create another one using the command line

manage.py createsuperuser --username=username --email=username@myemail.com

Of course, set your own name and email address.

Here it is, you are in the admin section. This is the default display from Django. You didn’t needed to create any line of code to display those pages. From here, you can manage your applications. But where is our application ?

Default Django admin site content.

Django do not automatically enable all applications and models for the administration site. You need to tell Django what you want to see here. Administration is critical for your application, you don’t want any outage because of the wrong parameter modified by the wrong person. Everything here is an opt-in. You should add here only items you want your administrators to have access to. If you don’t want a human to access a model, don’t add it to the admin site.

To add your application to the admin section, you first need to create an admin.py file at the root of your application. You can restart the development server here to see if anything changed.

Then, simply add in the file just created:

from django.contrib import admin
from myprivatesite.models import SourceUrl

admin.site.register(SourceUrl)

If you did not, restart your development server (new file creation do not auto refresh the project) and go back to the admin site. Now you can see your application with the corresponding model.

Django Admin site with our project model.

From this page, you can display the awaited form. But Django also allowed us to go several steps further. It does not just display the form, this is a fully functional form. The next User Stories are usually:

• I want to save the data provided trough the form
• I want to review the saved data
• I want to modify the saved data
• I want to delete a saved entry

Django just offered you all those steps in one single configuration. Lets just test it. Add a new SourceUrl. In the form, add Geekgarage as the name and http://geekgarage.dad3zero.net/ as the URL. Just press save and see what happened. Nice, we have a object. Select it and you’ll see the content of its fields. From this page, you can change their content. Actually, the address is wrong, Change it to http://geekgarage.dad3zero.net/feed/ and save it. You can review it and see that the change have been made. You see the Delete button, so yes, you can delete the entry. Now, lets add another one. Reenter the same data once again, use Geekgarage for the name and http://geekgarage.dad3zero.net/feed/ for the URL. Great, we have a second object. Wait, there’s something wrong here…

Each SourceUrl object represents a feed you want to follow. Having two objects with the same URL will make the system look twice for the same feed. SourceUrl should be unique and Django should forbid us to create two objects with the same URL. Django can manage this, but it must be configured in the model. We’ll have to get back to our model definition. This will be covered in the next post as we’ll see what are the consequences of modifying an existing Model.

For now, lets just discuss about the usefulness of the Admin site. Should you use it in production ? Just take a look on the auth application. Here you have groups and users. No group is defined out of the box. If you check the users, you’ll find only one (or two if you forgot your first created user) user(s) defined. If you select it, you will see a lot of fields in an sober but interesting layout.

As you can expect, only a few lines of code are necessary to create such forms, easier to read for complex objects. You can learn more about it in the Django tutorial. So you can really easily build all the administration area.

You can also see that Django provides everything you may need to manage users and groups. Ok, maybe not everything, but at least a good foundation. Actually, Django provides all the common tools an administrator may need. So don’t waste time recreating what is already provided. Use the admin site for administration purpose.

You may need other intermediate profiles. Contributors are not administrators. They need to add some content but should not access all the parameters in the admin section. You can restrict the access regarding the group of the user. Just as you can add a form on the public site for registered users. For those specific profiles, there may be some magic but you’ll have some work to do.

At this point of the tutorial, we are just creating a single-user web application. We do not need to manage users. But we don’t want to waste time on building forms which will be barely used. So the admin site addresses our need.

In this post, we have enabled the admin site which provides a form to add SourceUrl objects, fulfilling the User Story. We have created and saved two objects which unfortunately revealed a weakness in our model. In the next step we’ll need to go back to our model.

About Darko Stankovski

Darko Stankovski is the founder and editor of Dad 3.0. You can find more about him trough the following links.

• Twitter
|
• Facebook
|
• More Posts(75)