Le livre de

QueryDict Objects

Pour un objet HttpRequest, les attributs GET et POST sont des instances de django.http.QueryDict. QueryDict est une classe assimilable à un dictionnaire, et personnalisée pour gérer les valeurs multiples d’une même clef. Ceci est nécessaire parceque certains éléments de formulaire HTML, notablement <select multiple="multiple">, transmettent des valeurs multiples pour une même clef.

Les instances QueryDict sont immuables, à moins d’avoir créé une copy(). cela signifie que vous ne pouvez pas directement modifier les attributs de request.POST et request.GET.

QueryDict implemente toutes les méthodes standards des dictionnaires, puisque c’est une sous-classe de dictionnaire. Les exceptions sont abordées au Tableau H-3.

Table H-3. How QueryDicts Differ from Standard Dictionaries.

>>> q = QueryDict('a=1')
>>> q = q.copy() # to make it mutable
>>> q.update({'a': '2'})
>>> q.getlist('a')
['1', '2']
>>> q['a'] # returns the last
['2']

>>> q = QueryDict('a=1&a=2&a=3')
>>> q.items()
[('a', '3')]

En complément, QueryDict propose les méthodes figurants dans le Tableau H-4.

H-4. Extra (Nondictionary) QueryDict Methods

>>> q = QueryDict('a=1&a=2&a=3')
>>> q.lists()
[('a', ['1', '2', '3'])]

Un exemple complet

Par exemple, considérons ce formulaire HTML:

<form action="/foo/bar/" method="post">
<input type="text" name="your_name" />
<select multiple="multiple" name="bands">
    <option value="beatles">The Beatles</option>
    <option value="who">The Who</option>
    <option value="zombies">The Zombies</option>
</select>
<input type="submit" />
</form>

Si l’utilisateur saisi "John Smith" dans le champ your_name et sélectionne à la fois «The Beatles» et «The Zombies» dans la boîte de sélection multiple, voici ce que l’objet requête contiendra:

>>> request.GET
{}
>>> request.POST
{'your_name': ['John Smith'], 'bands': ['beatles', 'zombies']}
>>> request.POST['your_name']
'John Smith'
>>> request.POST['bands']
'zombies'
>>> request.POST.getlist('bands')
['beatles', 'zombies']
>>> request.POST.get('your_name', 'Adrian')
'John Smith'
>>> request.POST.get('nonexistent_field', 'Nowhere Man')
'Nowhere Man'

Note d’implémentation:

Les attributs GET, POST, COOKIES, FILES, META, REQUEST, raw_post_data, et user sont tous chargés à minima. Cela signifie que Django n’utilise pas de ressources en calculant les valeurs de ces attributs avant que le code ne les demande.

Construction des HttpResponses

Typiquement, vous construirez une HttpResponse pour transmettre le contenu de la page, sous forme de chaîne, au contructeur de HttpResponse:

>>> response = HttpResponse("Here's the text of the Web page.")
>>> response = HttpResponse("Text only, please.",
mimetype="text/plain")

Mais si voulez ajouter du contenu de façon incrémentale, vous pouvez utiliser response comme un objet similaire à un objet:

>>> response = HttpResponse()
>>> response.write("<p>Here's the text of the Web page.</p>")
>>> response.write("<p>Here's another paragraph.</p>")

Vous pouvez passer à HttpResponse un itérateur au lieu de passer sa chaîne codée en dure. Si vous utilisez cette technique, suivez ces règles:

• L’itérateur doit retourner des chaînes.
• Si une HttpResponse a été initialisée avec un itérateur pour contenu, vous ne pouvez pas utiliser l’instance HttpResponse comme un objet de type fichier. Faire ainsi lévera une Exception.

Finallement, notez que HttpResponse implémente une méthode write(), qui est disponible pour être utilisée partout où Python attends un objet assimilable à un fichier. Consultez le chapitre 11 pour des exemples d’utilisation de cette technique.

Paramètre d’en-têtes

Vous pouvez ajouter et supprimer les en-têtes en utilisant la syntaxe des dictionnaires:

>>> response = HttpResponse()
>>> response['X-DJANGO'] = "It's the best."
>>> del response['X-PHP']
>>> response['X-DJANGO']
"It's the best."

Vous pouvez aussi utiliser has_header(header) pour vérifier l’existence d’une en-tête.

Évitez de paramétrer l’en-tête Cookie à la main; au lieu de cela, lisez le chapitre 12 pour connaître le fonctionnement des cookies sous Django.

Sous classes de HttpResponse

Django inclu de nombreuses sous classes de HttpResponse qui gèrent différents types de reponses HTTP (voir le Tableau H-5). Comme HttpResponse, ces sous classes résident dans django.http.

Table H-5. HttpResponse Subclasses

Vous pouvez, bine sur, définir votre propre sous classe HttpResponse pour supporter différents types de réponses qui ne soient pas supportées nativement.

Renvoyer les erreurs

Retourner les codes d’erreur HTTP sous Django est facile. Nous avons déjà mentionné HttpResponseNotFound, HttpResponseForbidden, HttpResponseServerError, et autres sous classes. Retournez une instance de l’une de ces sous classes à la place d’une HttpResponse normale de façon à préciser une erreur, par exemple:

def my_view(request):
    # ...
    if foo:
        return HttpResponseNotFound('<h1>Page not
        found</h1>')
    else:
        return HttpResponse('<h1>Page was found</h1>')

Puisque l’erreur 404 est de loin l’erreur HTTP la plsu commune, il existe une façon simple de les gérer.

Lorsque vous retournez une erreur telle que HttpResponseNotFound, vous êtes responsable de définir le HTML de la page d’erreur résultante:

return HttpResponseNotFound('<h1>Page not found</h1>')

Par commodité, et puisque c’est une bonne idée d’avoir une page d’erreur 404 consistante au sein de votre site, Django founrit une exception Http404. Si vous levez Http404 à n’importe quel endroit d’une fonction vue, Django l’attrapera et retournera la page d’erreur standard pour votre application, avec un code d’erreur HTTP 404.

Voici un exemple:

from django.http import Http404

def detail(request, poll_id):
    try:
        p = Poll.objects.get(pk=poll_id)
    except Poll.DoesNotExist:
        raise Http404
    return render_to_response('polls/detail.html', {'poll': p})

De façon à utiliser l’exception Http404 à son plein, vous devez créer un gabarit qui est affiché lorsqu’une erreur 404 est levée. Ce gabarit doit être nommé 404.html, et doit être situé à la racine de votre arborescence de gabarit.

Personnaliser la vue 404 (Not Found)

Lorsque vous levez une exception Http404, Django charge une vue spéciale dédiéé à la prise en charge des erreurs 404. Par défault, c’est la vue django.views.defaults.page_not_found, qui charge et retourne le gabarit 404.html.

Ceci signifie que vous devez définir un gabarit 404.html dans la racine de votre répertoire de gabarit. Ce gabarit sera utilisé pour toutes les erreurs 404.

Cette vue page_not_found doit suffire pour 99% des applications web, mais si vous voulez écraser la vue 404, vous pouvez spécifier handler404 dans votre URLconf, comme ceci:

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    ...
)

handler404 = 'mysite.views.my_custom_404_view'

En coulisse, Django détermine la vue 404 en recherchant le handler404. Par défaut, URLConfs contient la ligne suivante:

from django.conf.urls.defaults import *

Ceci prends soin de paramétrer handler404 dans le module courant. Comme vous pouvez le voir dans django/conf/urls/defaults.py, handler404 est fixé à 'django.views.defaults.page_not_found' par défaut.

Il y a trois choses à noter au sujet des vues 404:

• La vue 404 est aussi appellée si Django ne trouve pas de correspondance après avoir vérifié chaque expression régulière présente dans l’URLConf.
• Si vous ne définissez pas votre propre vue 404 - et utilisez simplement celle par défaut, ce qui est recommandé - vous aurez toujours une obligation: pour créer un gabarit 404.html dans la racine de votre répertoire de gabarit. La vue 404 par défaut utilisera ce gabarit pour toutes les erreurs 404.
• Si DEBUG est fixé à True (dans votre module «settings»), alors votre vue 404 ne sera jamais utilisée, et le rapport d’erreur sera affiché à la place.

Personnaliser la vue 500 (Server Error)

De la même façon, Django à un comportement spécifique dans le cas d’une erreur d’exécution au niveau du code de la vue. Si une vue génère une exception, Django appellera, par défaut, la vue django.views.defaults.server_error, qui chargera et retournera le gabarit 500.html.

Cela signifie que vous devez définir un gabarit 500.html à la racine de votre répertoire de gabarit. Ce gabarit sera utilisé pour toutes les erreurs relatives au serveur.

Cette vue server_error doit suffire pour 99% des applications web, mais si vous voulez écraser cette vue, vous pouvez spécifier handler500 dans votre URLconf, comme ceci:

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    ...
)

handler500 = 'mysite.views.my_custom_error_view'

<< précédent