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

This entry was posted in Programmation and tagged decorators django python routing on by

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 thoughts on “Django-quicky: l’abolition des préliminaires, par Sam et Max”

  • Jean-Francois

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

  • bussiere

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

  • Sam Post author

    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

  • bussiere

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

  • Sam Post author

    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.

  • Sam Post author

    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

  • Sam Post author

    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.

  • bussiere

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

    Merci
    Bussiere

  • Sam Post author 
    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.

  • bussiere

    K merci beaucoup je vais tester cela ce soir tranquillement.

    Merci encore
    Bussiere

  • bussiere

    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é :/

  • bussiere

    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

  • Sam Post author

    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.

  • bussiere

    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.

  • Sam Post author

    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.

  • bussiere

    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

Comments are closed.

Des questions Python sans rapport avec l'article ? Posez-les sur IndexError.