Conseils et fonctionnalités Django préférés?

Inspiré par la série de questions «Caractéristiques cachées de ...», je suis curieux de connaître vos astuces Django préférées ou des fonctionnalités moins connues mais utiles que vous connaissez.

• Veuillez inclure un seul pourboire par réponse.
• Ajoutez les exigences de version de Django s'il y en a.

Je vais juste commencer par un conseil de moi-même :)

Utilisez os.path.dirname () dans settings.py pour éviter les noms de répertoire codés en dur.

Ne codez pas en dur le chemin d'accès dans votre settings.py si vous souhaitez exécuter votre projet à différents endroits. Utilisez le code suivant dans settings.py si vos modèles et fichiers statiques se trouvent dans le répertoire du projet Django:

# settings.py
import os
PROJECT_DIR = os.path.dirname(__file__)
...
STATIC_DOC_ROOT = os.path.join(PROJECT_DIR, "static")
...
TEMPLATE_DIRS = (
    os.path.join(PROJECT_DIR, "templates"),
)

Crédits: J'ai obtenu cette astuce du screencast ' Django From the Ground Up '.

Installez les extensions de commande Django et pygraphviz , puis exécutez la commande suivante pour obtenir une visualisation de modèle Django très agréable:

./manage.py graph_models -a -g -o my_project.png

Utilisez le render_to décorateur de django-ennuyeux au lieu de render_to_response.

@render_to('template.html')
def foo(request):
    bars = Bar.objects.all()
    if request.user.is_authenticated():
        return HttpResponseRedirect("/some/url/")
    else:
        return {'bars': bars}

# equals to
def foo(request):
    bars = Bar.objects.all()
    if request.user.is_authenticated():
        return HttpResponseRedirect("/some/url/")
    else:
        return render_to_response('template.html',
                              {'bars': bars},
                              context_instance=RequestContext(request))

Modifié pour souligner que le retour d'une réponse HttpResponse (telle qu'une redirection) court-circuitera le décorateur et fonctionnera comme prévu.

Il y a un ensemble de balises personnalisées que j'utilise partout dans les modèles de mon site. Vous cherchez un moyen de le charger automatiquement (SEC, rappelez-vous?), J'ai trouvé ce qui suit:

from django import template
template.add_to_builtins('project.app.templatetags.custom_tag_module')

Si vous placez cela dans un module qui est chargé par défaut (votre URL principale par exemple), vous aurez les balises et les filtres de votre module de balises personnalisées disponibles dans n'importe quel modèle, sans utiliser {% load custom_tag_module %}.

L'argument passé à template.add_to_builtins()peut être n'importe quel chemin de module; votre module de balise personnalisé ne doit pas nécessairement vivre dans une application spécifique. Par exemple, il peut également s'agir d'un module dans le répertoire racine de votre projet (par exemple. 'project.custom_tag_module').

Virtualenv + Python = économiseur de vie si vous travaillez sur plusieurs projets Django et qu'il est possible qu'ils ne dépendent pas tous de la même version de Django / d'une application.

Ne codez pas en dur vos URL!

Utilisez plutôt les noms d'URL et la reversefonction pour obtenir l'URL elle-même.

Lorsque vous définissez vos mappages d'URL, donnez des noms à vos URL.

urlpatterns += ('project.application.views'
   url( r'^something/$', 'view_function', name="url-name" ),
   ....
)

Assurez-vous que le nom est unique par URL.

J'ai généralement un format cohérent "project-appplication-view", par exemple "cbx-forum-thread" pour une vue de thread.

MISE À JOUR (volant sans vergogne l'ajout d'ayaz ):

Ce nom peut être utilisé dans les modèles avec la urlbalise .

Utilisez la barre d'outils de débogage django . Par exemple, il permet d'afficher toutes les requêtes SQL effectuées lors du rendu de la vue et vous pouvez également afficher la trace de pile pour chacune d'entre elles.

N'écrivez pas vos propres pages de connexion. Si vous utilisez django.contrib.auth.

Le vrai et sale secret est que si vous utilisez également django.contrib.admin et que django.template.loaders.app_directories.load_template_source se trouve dans vos chargeurs de modèles, vous pouvez également obtenir vos modèles gratuitement!

# somewhere in urls.py
urlpatterns += patterns('django.contrib.auth',
    (r'^accounts/login/$','views.login', {'template_name': 'admin/login.html'}),
    (r'^accounts/logout/$','views.logout'),
)

Les processeurs de contexte sont géniaux.

Supposons que vous ayez un modèle d'utilisateur différent et que vous souhaitiez l'inclure dans chaque réponse. Au lieu de faire ceci:

def myview(request, arg, arg2=None, template='my/template.html'):
    ''' My view... '''
    response = dict()
    myuser = MyUser.objects.get(user=request.user)
    response['my_user'] = myuser
    ...
    return render_to_response(template,
                              response,
                              context_instance=RequestContext(request))

Les processus contextuels vous permettent de transmettre n'importe quelle variable à vos modèles. Je mets généralement le mien dans 'my_project/apps/core/context.py:

def my_context(request):
    try:
        return dict(my_user=MyUser.objects.get(user=request.user))
    except ObjectNotFound:
        return dict(my_user='')

Dans votre, settings.pyajoutez la ligne suivante à votreTEMPLATE_CONTEXT_PROCESSORS

TEMPLATE_CONTEXT_PROCESSORS = (
    'my_project.apps.core.context.my_context',
    ...
)

Désormais, chaque fois qu'une demande est faite, elle inclut my_userautomatiquement la clé.

Signale également la victoire.

J'ai écrit un article à ce sujet il y a quelques mois, donc je vais juste copier-coller:

Hors de la boîte Django vous donne plusieurs signaux qui sont incroyablement utiles. Vous avez la possibilité de faire des choses avant et après l'enregistrement, l'initialisation, la suppression ou même lorsqu'une demande est en cours de traitement. Permet donc de s'éloigner des concepts et de montrer comment ils sont utilisés. Disons que nous avons un blog

from django.utils.translation import ugettext_lazy as _
class Post(models.Model):
    title = models.CharField(_('title'), max_length=255)
    body = models.TextField(_('body'))
    created = models.DateTimeField(auto_now_add=True)

Donc, d'une manière ou d'une autre, vous souhaitez informer l'un des nombreux services de ping de blog que nous avons créé un nouveau message, reconstruire le cache des messages les plus récents et tweeter à ce sujet. Eh bien, avec les signaux, vous avez la possibilité de faire tout cela sans avoir à ajouter de méthodes à la classe Post.

import twitter

from django.core.cache import cache
from django.db.models.signals import post_save
from django.conf import settings

def posted_blog(sender, created=None, instance=None, **kwargs):
    ''' Listens for a blog post to save and alerts some services. '''
    if (created and instance is not None):
        tweet = 'New blog post! %s' instance.title
        t = twitter.PostUpdate(settings.TWITTER_USER,
                               settings.TWITTER_PASSWD,
                               tweet)
        cache.set(instance.cache_key, instance, 60*5)
       # send pingbacks
       # ...
       # whatever else
    else:
        cache.delete(instance.cache_key)
post_save.connect(posted_blog, sender=Post)

Nous y voilà, en définissant cette fonction et en utilisant le signal post_init pour connecter la fonction au modèle Post et l'exécuter après l'avoir enregistrée.

Quand je commençais, je ne savais pas qu'il y avait un Paginator , assurez-vous de connaître son existence !!

Utilisez IPython pour accéder à votre code à n'importe quel niveau et déboguer en utilisant la puissance d'IPython. Une fois que vous avez installé IPython, placez simplement ce code là où vous voulez déboguer:

from IPython.Shell import IPShellEmbed; IPShellEmbed()()

Ensuite, actualisez la page, allez dans votre fenêtre runserver et vous serez dans une fenêtre IPython interactive.

J'ai un extrait de code mis en place dans TextMate donc je tape juste ipshell et appuie sur tab. Je ne pourrais pas vivre sans ça.

Exécutez un serveur SMTP de développement qui ne fera que sortir tout ce qui lui est envoyé (si vous ne voulez pas réellement installer SMTP sur votre serveur de développement.)

ligne de commande:

python -m smtpd -n -c DebuggingServer localhost:1025

Depuis la documentation de django-admin :

Si vous utilisez le shell Bash, envisagez d'installer le script d'achèvement de bash Django, qui réside extras/django_bash_completiondans la distribution Django. Il permet la complétion par tabulation des commandes django-admin.pyet manage.py, vous pouvez donc, par exemple ...

• Tapez django-admin.py.
• Appuyez sur [TAB] pour voir toutes les options disponibles.
• Tapez sql, puis [TAB], pour voir toutes les options disponibles dont les noms commencent par sql.

La ./manage.py runserver_plusfacilité qui vient avec django_extensions est vraiment géniale.

Il crée une page de débogage améliorée qui, entre autres, utilise le débogueur Werkzeug pour créer des consoles de débogage interactives pour chaque point de la pile (voir capture d'écran). Il fournit également une méthode de débogage pratique très utile dump()pour afficher des informations sur un objet / cadre.

Pour installer, vous pouvez utiliser pip:

pip install django_extensions
pip install Werkzeug

Ajoutez ensuite 'django_extensions'à votre INSTALLED_APPStuple settings.pyet démarrez le serveur de développement avec la nouvelle extension:

./manage.py runserver_plus

Cela va changer la façon dont vous déboguez.

J'aime utiliser le débogueur Python pdb pour déboguer des projets Django.

Il s'agit d'un lien utile pour apprendre à l'utiliser: http://www.ferg.org/papers/debugging_in_python.html

Lorsque vous essayez d'échanger des données entre Django et une autre application, request.raw_post_datac'est un bon ami. Utilisez-le pour recevoir et traiter, par exemple, des données XML.

Documentation: http://docs.djangoproject.com/en/dev/ref/request-response/

Utilisez Jinja2 aux côtés de Django.

Si vous trouvez le langage de gabarit Django extrêmement restrictif (comme moi!), Alors vous n'avez pas à vous en tenir à lui. Django est flexible, et le langage de modèle est vaguement couplé au reste du système, alors il suffit de brancher un autre langage de modèle et de l'utiliser pour rendre vos réponses http!

J'utilise Jinja2 , c'est presque comme une version optimisée du langage de modèle django, il utilise la même syntaxe et vous permet d'utiliser des expressions dans les instructions if! plus besoin de faire des if-tags personnalisés comme if_item_in_list! vous pouvez simplement dire %{ if item in list %}, ou {% if object.field < 10 %}.

Mais ce n'est pas tout; il a beaucoup plus de fonctionnalités pour faciliter la création de modèles, que je ne peux pas parcourir tous ici.

Ajoutez assert Falsevotre code d'affichage pour vider les informations de débogage.

Cela ajoute à la réponse ci-dessus à propos des noms d'URL de Django et de la répartition inverse des URL .

Les noms d'URL peuvent également être utilisés efficacement dans les modèles. Par exemple, pour un modèle d'URL donné:

url(r'(?P<project_id>\d+)/team/$', 'project_team', name='project_team')

vous pouvez avoir les éléments suivants dans les modèles:

<a href="{% url project_team project.id %}">Team</a>

Étant donné que les "vues" Django doivent uniquement être des callables qui renvoient une HttpResponse, vous pouvez facilement créer des vues basées sur des classes comme celles de Ruby on Rails et d'autres frameworks.

Il existe plusieurs façons de créer des vues basées sur une classe, voici ma préférée:

from django import http

class RestView(object):
    methods = ('GET', 'HEAD')

    @classmethod
    def dispatch(cls, request, *args, **kwargs):
        resource = cls()
        if request.method.lower() not in (method.lower() for method in resource.methods):
            return http.HttpResponseNotAllowed(resource.methods)
        try:
            method = getattr(resource, request.method.lower())
        except AttributeError:
            raise Exception("View method `%s` does not exist." % request.method.lower())
        if not callable(method):
            raise Exception("View method `%s` is not callable." % request.method.lower())
        return method(request, *args, **kwargs)

    def get(self, request, *args, **kwargs):
        return http.HttpResponse()

    def head(self, request, *args, **kwargs):
        response = self.get(request, *args, **kwargs)
        response.content = ''
        return response

Vous pouvez ajouter toutes sortes d'autres éléments, tels que le traitement et l'autorisation conditionnelle des demandes dans votre vue de base.

Une fois que vous avez configuré vos vues, votre urls.py ressemblera à ceci:

from django.conf.urls.defaults import *
from views import MyRestView

urlpatterns = patterns('',
    (r'^restview/', MyRestView.dispatch),
)

Au lieu d'utiliser render_to_responsepour lier votre contexte à un modèle et le rendre (ce que les documents Django montrent généralement), utilisez la vue générique direct_to_template. Il fait la même chose render_to_responsemais ajoute automatiquement RequestContext au contexte du modèle, permettant implicitement d'utiliser des processeurs de contexte. Vous pouvez le faire manuellement en utilisant render_to_response, mais pourquoi s'embêter? C'est juste une autre étape à retenir et un autre LOC. En plus d'utiliser des processeurs de contexte, avoir RequestContext dans votre modèle vous permet de faire des choses comme:

<a href="{{MEDIA_URL}}images/frog.jpg">A frog</a> 

ce qui est très utile. En fait, +1 sur les vues génériques en général. Les documents Django les montrent principalement sous forme de raccourcis pour ne même pas avoir de fichier views.py pour des applications simples, mais vous pouvez également les utiliser dans vos propres fonctions d'affichage:

from django.views.generic import simple

def article_detail(request, slug=None):
    article = get_object_or_404(Article, slug=slug)
    return simple.direct_to_template(request, 
        template="articles/article_detail.html",
        extra_context={'article': article}
    )

Je n'ai pas assez de réputation pour répondre au commentaire en question, mais il est important de noter que si vous allez utiliser Jinja , il ne prend pas en charge le caractère «-» dans les noms de blocs de modèle, contrairement à Django. Cela m'a causé beaucoup de problèmes et perdu du temps à essayer de retrouver le message d'erreur très obscur qu'il a généré.

L' application webdesign est très utile lorsque vous commencez à concevoir votre site Web. Une fois importé, vous pouvez l'ajouter pour générer un exemple de texte:

{% load webdesign %}
{% lorem 5 p %}

django.db.models.get_model vous permet de récupérer un modèle sans l'importer.

James montre à quel point cela peut être pratique: "Astuces Django: Écrivez de meilleures balises de modèle - Itération 4" .

Tout le monde sait qu'il existe un serveur de développement que vous pouvez exécuter avec "manage.py runserver", mais saviez-vous qu'il existe également une vue de développement pour servir des fichiers statiques (CSS / JS / IMG)?

Les nouveaux arrivants sont toujours perplexes car Django ne propose aucun moyen de servir des fichiers statiques. C'est parce que l'équipe de développement pense que c'est le travail d'un serveur Web réel.

Mais lors du développement, vous ne voudrez peut-être pas configurer Apache + mod_wisgi, c'est lourd. Ensuite, vous pouvez simplement ajouter ce qui suit à urls.py:

(r'^site_media/(?P<path>.*)$', 'django.views.static.serve',
        {'document_root': '/path/to/media'}),

Votre CSS / JS / IMG sera disponible sur www.yoursite.com/site_media/.

Bien sûr, ne l'utilisez pas dans un environnement de production.

J'ai appris celui-ci dans la documentation de l'application sorl-thumbnails . Vous pouvez utiliser le mot clé "as" dans les balises de modèle pour utiliser les résultats de l'appel ailleurs dans votre modèle.

Par exemple:

{% url image-processor uid as img_src %}
<img src="{% thumbnail img_src 100x100 %}"/>

Ceci est mentionné en passant dans la documentation Django templatetag, mais en référence aux boucles uniquement. Ils n'appellent pas que vous pouvez également l'utiliser ailleurs (n'importe où?).

django.views.generic.list_detail.object_list - Il fournit toutes les variables de logique et de modèle pour la pagination (une de ces tâches que j'ai écrites mille fois maintenant). L'emballage permet à toute logique dont vous avez besoin. Cette gemme m'a sauvé de nombreuses heures de débogage des erreurs ponctuelles dans mes pages "Résultats de la recherche" et rend le code d'affichage plus propre dans le processus.

PyCharm IDE est un environnement agréable pour coder et surtout déboguer, avec un support intégré pour Django.

Utilisez xml_models pour créer des modèles Django qui utilisent un backend d'API REST XML (au lieu d'un SQL). Cela est très utile, en particulier lors de la modélisation d'API tierces - vous obtenez la même syntaxe QuerySet que celle à laquelle vous êtes habitué. Vous pouvez l'installer à partir de PyPI.

XML à partir d'une API:

<profile id=4>
    <email>joe@example.com</email>
    <first_name>Joe</first_name>
    <last_name>Example</last_name>
    <date_of_birth>1975-05-15</date_of_birth>
</profile>

Et maintenant en python:

class Profile(xml_models.Model):
    user_id = xml_models.IntField(xpath='/profile/@id')
    email = xml_models.CharField(xpath='/profile/email')
    first = xml_models.CharField(xpath='/profile/first_name')
    last = xml_models.CharField(xpath='/profile/last_name')
    birthday = xml_models.DateField(xpath='/profile/date_of_birth')

    finders = {
        (user_id,):  settings.API_URL +'/api/v1/profile/userid/%s',
        (email,):  settings.API_URL +'/api/v1/profile/email/%s',
    }

profile = Profile.objects.get(user_id=4)
print profile.email
# would print 'joe@example.com'

Il peut également gérer les relations et les collections. Nous l'utilisons tous les jours dans du code de production très utilisé, donc même s'il s'agit d'une version bêta, il est très utilisable. Il dispose également d'un bon ensemble de talons que vous pouvez utiliser dans vos tests.

(Avertissement: bien que je ne sois pas l'auteur de cette bibliothèque, je suis maintenant un committer, après avoir fait quelques commits mineurs)

Utilisez les migrations de base de données. Utilisez Sud .