Viewing Records

Let's start with the simplest view, whose purpose is to represent information about all networks that are defined in the database. For now you will have to use the administration interface, which you created earlier, to add new networks and define relations.

First of all we need to define the URL mapping rules, so the requests are redirected to the appropriate view function:

urlpatterns = patterns('www_example_com.ip_addresses.views', (r'Anetworkaddress/$', 'display'),

(r'Anetworkaddress/(?P<address>\d{l,3}\.\d{l,3}\.\d{l,B}\.\d{l,B}\/\d{l,2})/$', 'display'),

The first rule matches the URL /ip_address/networkaddress/ and calls the display function from the views module. The second rule searches for URLs that look like

/ip_address/networkaddress/a .b.c. d/x/. It also calls the display function, but this time it passes the keyword argument address, which is initialized with the string a.b.c.d/x.

Let's quickly test whether this works by defining a simplified version of the view. All we want to know at this stage is whether our two rules work as expected. Listing 3-6 is an example of a simple views. py file that will test our URLs.

Listing 3-6. A simple view to test the URL dispatcher rules from www_example_com.ip_addresses.models import * from django.http import HttpResponse def display(request, address=None): if not address:

msg = "Top of the address tree" else:

msg = "Top level address: %s" % address return HttpResponse(msg)

What happens here is pretty straightforward. We import the model class and also the HttpResponse class. The Django framework expects either an instance of HttpResponse or an exception raised as a result from any view function that it calls. Obviously, the view function doesn't do much at this point; it will only display the IP address from the URL or tell you that it's at the top of the address tree if no IP is found in the URL. This is a good technique to sort out your URL mapping regular expressions before you start creating more complex views. When debugging the view functionality, you need to know that your mappings are functioning as expected.

â– Note The reason for including both the IP address and the network size is that only the pair creates a unique object. If we used only the IP address, in most cases it might be ambiguous. For example, 192.168.0.0 (/24) and 192.168.0.0 (/25) are not the same network, although their IP addresses are the same.

Now, before proceeding let's create some entries in the database. You will have to use the Django administration interface as there are no custom forms for entering the data. Table 3-3 contains sample data you can use to create similar entries and compare the results in this book with what you get as you go along with the implementation.

Table 3-3. A Sample IP Network and Address Dataset

Address

Network size

Parent (network)

Description

192.168.0.0

24

none

First top-level network

192.168.1.0

24

none

Second top-level network

192.168.0.0

25

192.168.0.0/25

Subnet 1-1

192.168.0.128

25

192.168.0.0/25

Subnet 1-2

192.168.1.0

26

192.168.1.0/26

Subnet 2-1

192.168.1.64

26

192.168.1.0/26

Subnet 2-2

192.168.1.128

26

192.168.1.0/26

Subnet 2-3

192.168.1.192

26

192.168.1.0/26

Subnet 2-4

192.168.0.1

32

192.168.0.0/25

IP 1 in Subnet 1-1

192.168.0.2

32

192.168.0.0/25

IP 2 in Subnet 1-1

192.168.0.129

32

192.168.0.128/25

IP 1 in Subnet 1-2

192.168.0.130

32

192.168.0.128/25

IP 2 in Subnet 1-2

192.168.1.1

32

192.168.1.0/26

IP 1 in Subnet 2-1

192.168.1.2

32

192.168.1.0/26

IP 2 in Subnet 2-1

192.168.1.65

32

192.168.1.64/26

IP 1 in Subnet 2-2

192.168.1.66

32

192.168.1.64/26

IP 2 in Subnet 2-2

Address Network size Parent (network) Description

192.168.1.129

32

192.168.1.128/26

IP 1 in Subnet 2-3

192.168.1.130

32

192.168.1.128/26

IP 2 in Subnet 2-3

192.168.1.193

32

192.168.1.192/26

IP 1 in Subnet 2-4

192.168.1.194

32

192.168.1.192/26

IP 2 in Subnet 2-4

This might seem to be a lot to add manually. If you feel like creating all records manually, that's fine, but Django has another feature: you can provide initial data as a fixture file. Version 1.1 of Django understands three formats: XML, YAML, and JSON. This is very useful during the development and test phases; you create initial data once, and then re-create your database whenever you need to with the exact set of data. Listing 3-7 shows part of the sample fixtures file we will use to initialize the database. I've chosen to use JSON here, mostly because of its simplicity, readability, and supportability.

Listing 3-7. An excerpt from the sample_data.json file used to load initial data [

"model": "ip_addresses.networkaddress", "pk": 1, "fields": {

"address": "192.168.0.0", "network_size": 24,

"description": "First top level network"

"model": "ip_addresses.networkaddress", "pk": 3, "fields": {

"address": "192.168.0.0", "network_size": 25, "description": "Subnet 1-1", "parent": 1

The structure of the file is pretty self-explanatory. Each record starts by defining the model class and is followed by the primary key, which is an integer unless you have explicitly redefined it. Finally, all class fields are listed in "key" :"value" pairs in the "fields" section. If there are any relationships between records, they are defined by using primary key values, just as in this example, Subnet 1-1 has a parent a parent and references it by setting "parent" to value of 1 (the primary key of the parent record). If the field is optional, you can just skip it. Once you have created the file, load the data with the following command:

$ python manage.py loaddata sample_data.json Installing json fixture 'sample_data' from absolute path.

Installed 20 object(s) from 1 fixture(s) $

Was this article helpful?

0 0

Post a comment