Django-quicky: l’abolition des préliminaires, par Sam et Max | Sam & Max: Python, Django, Git et du cul

Django-quicky: l’abolition des préliminaires, par Sam et Max

Max aime Bottle pour sa simplicité. J’aime Django pour sa puissance. Nous aimons tous les deux les jeux de mots graveleux à connotations sexuelles.

Ainsi est né django-quicky, une petite app qui permet de faire du routing et du rendering déclaratif en Django.

pip install django-quicky

Par toutes les routes

Vous avez envie d’un site, maintenant, tout de suite. Mais il faut créer l’urls.py, et les vues, et les mapper. Et jongler entre les deux fichiers.

Ou alors vous pouvez juste faire:

from django_quicky import routing

url, urlpatterns = routing()


@url('/une/regex/que/django/comprends')
def une_vue(request):
    ...


@url('/on/peut/cummuler/les/routes')
@url('/une/regex/que/django/comprends')
def une_vue(request):
    ...

Le résultat est parfaitement compatible (et mélangeable) avec le routing habituel de Django. Il suffit juste d’utiliser views.py à la place d’urls.py, par exemple dans URL_ROOT ou dans include().

Rien ne vaut une bonne renderette

Declarer sa vue, c’est comme les jupes, c’est de plus en plus court avec le temps qui passe (et la méthode render()). Mais on peut faire encore plus court, genre limite tanga:

from django_quicky import view

@view(render_to='template.html')
def une_vue(request):
    return {'truc': truc}


@view(render_to='json')
def une_vue_json(request):
    return {'truc': truc}

Dans la première vue, le dico est utilisé comme contexte pour faire le rendu du template. Dans la seconde vue, le dico est retourné sérialisé en JSON.

On change de position ?

Des fois vous êtes sur une bonne lancée, mais vous voudriez changer juste un truc. Et garder le code précédent bien sûr. C’est d’ailleurs pour ça qu’on nous vend les CBV, c’est tellement plus flexible !

Vous aimez la souplesse ? Voici de quoi mettre les chevilles très près des oreilles:

from django_quicky import view

@view(render_to='template.html')
def vue_commune(request):
    return {'stuff': stuff}

@vue_commune.post()
def vue_POST(request, context):
    # do more stuff
    return context

@vue_commune.ajax(render_to='json')
def vue_AJAX(request, context):
    return context

On a ici une seule et même vue. La première partie est rendue sous forme de template si on y arrive par une requête GET ordinaire. La seconde si c’est une requête POST. La troisième si c’est une requête en AJAX, avec rendering JSON en prime. Et les deux dernières récupèrent toujours le résultat de la première avant de s’exécuter, ce qui permet d’avoir le code en commun dans la première.

C’est sous licence zlib.

  22 comments for “Django-quicky: l’abolition des préliminaires, par Sam et Max

  1. Jean-Francois
    09/10/2012 at 10:54

    Excellent
    Etant également un fan inconditionnel de Bottle, ça fait plaisir :-)

  2. bussiere
    09/10/2012 at 15:46

    Tres sympas.
    Merci
    Y’a une possibilité de rendre la 404 avec ca ?

  3. Sam
    09/10/2012 at 18:20

    Il n’y a rien de spécificique à faire, c’est déjà très simple en Django, se serait overkill de rajouter un truc.

    Soit on fait juste le template 404.html (et ça utilise la vue par défaut, suffisante dans 99% des cas).

    Soit on se chauffe, et on met des truc dynamique dedans, et là il suffit de déclarer une vue comme gérant la 404 en mettant dans l’urls.py à la racine (qui peut être un views.py dans notre cas):

    handler404 = ‘mysite.views.my_custom_404_view’

    Pour une ligne de code utilisée une fois, on va pas faire un décorateur, se serait un peu le bon vieux bazooka pour la ptite mouche.

    handler404 = ‘mysite.views.my_custom_404_view’ dans un utils.py ou dans le views.py

  4. bussiere
    10/10/2012 at 14:43

    merci

  5. bussiere
    10/10/2012 at 15:07

    Et je vais faire chier encore un peu.
    Rendre l’interface d’admin avec cela stp ?

  6. Sam
    10/10/2012 at 20:23

    Pour l’instant j’ai pas encore mis de raccourcis pour faire un include, donc il faut faire comme d’hab

    url, urlpatterns = routing()

    et utilise urlpatterns comme dans urls.py pour ajouter l’admin. Et bien sur mettre le autodiscover.

    C’est clair que je devrais rajouter un ‘include’ et un include_admin(). Parce qu’on l’utilise vachement souvent.

  7. Sam
    10/10/2012 at 21:10

    Ok, bon bah c’est fait.

    pip install django-quicky --upgrade.

    En gros j’ai juste étendu urlpatterns, et maintenant il accepte:

    urlpatterns.add_url(même param que la fonction url() de Django)
    urlpatterns.include(url, view [, name, prefix])
    urlpattern.add_admin(url)
    

    La dernière est juste un raccourci qui lance le autodiscover() et fait un include.

    Pease

  8. Sam
    10/10/2012 at 21:51

    Tant que j’y étais, j’ai rajouté la gestion des 404, 504 et 403:

    @url.http404
    def vue(request)

    C’est juste pour avoir une API consistante, car ça apparte pas grand chose au final.

  9. bussiere
    11/10/2012 at 09:24

    merci
    Bussiere

  10. bussiere
    11/10/2012 at 09:28

    ceci dit j’ai un tout petit peu de mal a comprendre comment marche urlpattern je veux bien un petit exemple stp.

    Merci
    Bussiere

  11. Sam
    11/10/2012 at 10:10
    urls, urlpatterns = routing()
    
    urlpatterns.add_url(r'/user/\d+', user_view)
    urlpatterns.include(r'/other/app/', 'module.to.other.app')
    urlpatterns.add_admin('/admin/')

    urlpatterns a exactement le même rôle que dans un urls.py ordinnaire. En fait il peut être utilisé exactement de la même façon. Ces méthodes ne sont que des raccourcis pour les traditionnels:

    urlpatterns += patterns('',
    url(...)
    )

    Fais mois savoir si tu veux plus de détails.

  12. bussiere
    11/10/2012 at 11:44

    K merci beaucoup je vais tester cela ce soir tranquillement.

    Merci encore
    Bussiere

  13. bussiere
    12/10/2012 at 12:00

    scheisse :
    from django_quicky import routing

    urls, urlpatterns = routing()

    urlpatterns.add_admin(‘/admin/’)

    resultat sous django :
    AttributeError at /
    ‘list’ object has no attribute ‘add_admin’
    Request Method: GET
    Request URL: http://127.0.0.1:8000/
    Django Version: 1.4.1
    Exception Type: AttributeError
    Exception Value:
    ‘list’ object has no attribute ‘add_admin’

    ▶ Local vars
    D:\Documents\GitHub\Yuki\engine\views.py in
    urlpatterns.add_admin(‘/admin/’)

    Désolé :/

  14. Sam
    12/10/2012 at 12:58

    pip install django-quicky --upgrade

  15. bussiere
    22/10/2012 at 08:54

    erf par contre du coup ca ne fout pas la grouille dans les statics et media ?

    Ca fait un peu merdé pour moi quand j’ai un lien en media ou static notamment avec des dossiers.

    Merci
    Bussiere

  16. Sam
    22/10/2012 at 10:25

    Les medias se gèrent exactement de la même manière que sans django-quicky.

    Tu es en dev ? En prod ? Tu utilise le middleware pour servir les fichiers statiques ou non (les deux réponses sont valides) ?

    Globalement django-quicky n’influence pas la manière dont sont gérés les médias: on les sert de la même façon, et on peut faire les mêmes erreurs. Servir les fichiers statiques a toujours été une énorme source d’erreurs chez les débutants avec Django, donc on peut s’attendre à pas mal de méli mélo.

    Il y a un article à écrire sur servir les fichiers statiques en Django, mais c’est un énooooooooooooooorme article. Donc j’ai pas encore le courage de le faire.

  17. Sam
    22/10/2012 at 18:00

    Bon, @bussiere, j’ai fini par écrire l’article:

    http://sametmax.com/comment-servir-les-fichiers-statiques-avec-django-en-dev-et-en-prod/

    Vu que c’est une question TRES récurrente sur les forums, y en avait besoin de toute façon.

  18. bussiere
    23/10/2012 at 09:30

    En fait ca fout la grouille au niveau des urls.
    Il cherche mes urls /media ou /static comme si c’etait des urls définit par quicky. Et comme il ne les trouve pas il me fait chier :/
    Mais merci pour l’autre article.

  19. Sam
    23/10/2012 at 09:36

    Busiere, ça ne veut rien dire “Il cherche mes urls /media ou /static comme si c’etait des urls définit par quicky”. Les urls définies par quicky ne sont pas différentes que celles définies dans un urls.py. Les structures de données sont les mêmes, les règles sont les mêmes. Quicky créé juste des raccourcis, mais seule la syntaxe diffère.

    Pour résoudre ton problème, il faut savoir ce qui se passe vraiment:

    http://sametmax.com/template-de-demande-daide-en-informatique/

    On va t’aider à débugger ça petit à petit, mais il faut tout le contexte, et tout le code.

  20. bussiere
    23/10/2012 at 10:51

    T’inquiete le code est sur github, je vais prendre quelques minutes pour pondre un truc bien.

    Et je te remercie je t’envois un email.

    Bussiere

  21. 08/11/2012 at 17:13

    Merci pour l’article, vraiment très interessant !!!

  22. Sam
    08/11/2012 at 17:30

    ^^ Hey, cool de te voir en dehors de twitter.

Leave a Reply

Your email address will not be published. Required fields are marked *