Rachel’s Blog

In 0.96, if you dive straight in with a POST to your login page with username/password, you’ll get a login error, saying “Your Web browser doesn’t appear to have cookies enabled. Cookies are required for logging in.”.

This is because the test cookie only gets set when you do a GET.

So doing this works:


response=client.get(login_page)
response=client.post(login_page, {'username': username, 'password': password, 'next': home_page})


But just doing the post doesn’t.

If you’re creating a test user for a unit test, do it this way:


newuser=User.objects.create_user('john', 'lennon@thebeatles.com', 'johnpassword')


rather than this:


newuser=User(username="john",email="lennon@thebeatles.com",password="johnpassword")


The latter looks correct, but you’ll get problems logging in since Django stores the *hash* of the password in the db, not the clear text.

Another gotcha is that the client.login() function only works with pages where you can’t get at them until you have logged in - if the page is available to AnonymousUser, then login() will always fail.

This means you have a naming conflict between the core python module calendar and another one which is taking precendence.

If you’ve got your own module called calendar, rename it…

You can access the Django request within a Template Tag by enabling the request context processor.

If you’re using a generic view, for example, ‘direct_to_template’, your render() function will then be passed a RequestContext , and you can access the request by context[’request’].

If you’re not using a generic view, and are using render_to_response(), then you have to explicitly pass context_instance=RequestContext(request) as the third parameter.

You enable the request context processor by adding this to your settings file:

TEMPLATE_CONTEXT_PROCESSORS = ('django.core.context_processors.request',)

You might also need to add back the default context processors. These vary from version to version - check the django documentation for the settings file for details.

For example, in 0.96, I’ve got this in my settings file

TEMPLATE_CONTEXT_PROCESSORS = ('django.core.context_processors.request',
'django.core.context_processors.auth',
'django.core.context_processors.debug',
'django.core.context_processors.i18n',
)


• The obvious cause of this is that the settings.py doesn’t have the directory containing blah listed in INSTALLED_APPS.
• A less obvious cause: you’ll also get this error if the directory doesn’t contain a file __init__.py.

I’ve published 2 template tags for use with GeoIP at geoip.py.

Hope they may be of use…

Usage:

# Templatetag get_country_name returns the client’s country code
#
# Example:
# {% ifequal get_country “GB” %}
# do something
# {% endifequal %}

# Templatetag get_country sets the given variable name
# to the client’s country code
#
# Example:
# {% get_country as my_country %}
# {% ifequal my_country “GB” %}
# do something
# {% endifequal %}

An excellent tutorial from James Bennett for your first step into combining AJAX with Django

“A step-by-step walk through a simple AJAX form with Django backend”

Looks like you need to have both blank=True and null=True to make a ForeignKey optional in a django model…

I wanted to start writing a Django app which was to allow a user to enter data in various tables, and then run a workflow process.

I liked the admin front-end but thought I needed to do something clever with generic views to replicate this in my own application.

So I asked this question on the django-users list

On 04/09/05, Rachel Willmer  wrote:
> I want to use the generic view mechanism to add/change/delete but I
> don’t want to have to write my own form template for each page.
>
> I’d like it to work just like the admin interface does. Is it
> possible/sensible to hook into the admin code which seems to use
> add_stage/change_stage to automatically generate the templates? Or is
> there a better way of doing this?
>
> Any pointers welcome…
> Rachel

Now I’ve read a bit more about it, the answer is of course to just use the admin interface.

django-admin.py includes a useful command “adminindex”, which will auto-generate a copy of the admin interface index page.

So generate that, and copy it into your template directory to over-ride the inbuilt one, as described in Tutorial2

Then you can modify that as you wish…

Hey presto, instant application front end that you can use as the basis for the new application…

In retrospect, this is obvious and documented in the Django tutorial. But at the time, I was thinking in terms of “admin” interface and “main” interface, and it slipped past me that I could in fact use the admin interface *as* the main interface…

That might not work too well for most web applications, but for my purposes, (a local single-user application), it will work just fine…

Rachel

To help me get to grips with Django quickly, I created a search engine
of the documentation.

On the off-chance this is useful to others, I made it available at http://www.hobthross.com/docs/django/phpdig/search.php

(Sorry if this does not show up as a hyperlink, WordPress appears to be chewing that up and ignoring it)