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.
Excellent
Etant également un fan inconditionnel de Bottle, ça fait plaisir :-)
Tres sympas.
Merci
Y’a une possibilité de rendre la 404 avec ca ?
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
merci
Et je vais faire chier encore un peu.
Rendre l’interface d’admin avec cela stp ?
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.
Ok, bon bah c’est fait.
pip install django-quicky --upgrade.En gros j’ai juste étendu urlpatterns, et maintenant il accepte:
La dernière est juste un raccourci qui lance le
autodiscover()et fait un include.Pease
Tant que j’y étais, j’ai rajouté la gestion des 404, 504 et 403:
C’est juste pour avoir une API consistante, car ça apparte pas grand chose au final.
merci
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
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:
Fais mois savoir si tu veux plus de détails.
K merci beaucoup je vais tester cela ce soir tranquillement.
Merci encore
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é :/
pip install django-quicky --upgradeerf 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
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.
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.
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.
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.
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
Merci pour l’article, vraiment très interessant !!!
^^ Hey, cool de te voir en dehors de twitter.