Le mardi 26 février, 11 mois après la 1.4, est sortie la version 1.5 du framework web Django, écrit en Python. Ce framework, basé sur un concept Modèle-Gabarit-Vue (MGV, à rapprocher du MVC), est conçu pour le développement rapide et reprend la plupart des grands principes de Python (« Explicit is better than implicit », notamment), ce qui en fait la plate-forme de développement Web idéale pour les perfectionnistes sous pression.
De plus en plus de sites utilisent Django (par exemple, 20minutes, Libération.fr, Disqus, Century21, Convore, Instagram, Threadless…) pour sa flexibilité et pour le nombre d’applications Django réutilisables, qui ne cesse de croître. Je vous propose de découvrir les quelques nouveautés que vous offrent les développeurs Django et toute la communauté.
NdM : le 28 mars la version 1.5.1 de Django est sortie. Il s'agit d'une version de maintenance corrigeant quelques bogues mineurs et un problème de fuite de mémoire introduit par la version 1.5.
Sommaire
- Notes de version
- Modules utiles
Notes de version
Principales nouveautés
- Configuration du modèle User
- Compatibilité « expérimentale » avec Python 3
- Meilleure gestion des streaming responses
- Sélection des champs mis à jour lors de la sauvegarde d'un modèle
- Prise en charge de l'enregistrement d'un sous-ensemble des champs du modèle
- Mise en cache des instances liées au modèle
- {% verbatim %} template tag
- Récupération des instances associées ContentType avec des modèles de proxy
- Nouvelle variable view dans le contexte des vues basées sur des classes
- GeoDjango
Détails
Modèle User configurable
Les versions précédentes imposent un modèle d'utilisateur. Ce modèle sert notamment à authentifier les utilisateurs et gérer les permissions. Pour étendre ce modèle il faut définir un autre modèle (nommé profile) qui contient les champs supplémentaires. Cette solution présente plusieurs inconvénients. Une requête SQL supplémentaire ou une jointure est nécessaire pour obtenir les autres champs et il n'est pas possible de modifier le champs username.e
La version 1.5 introduit la prise en charge des modèles utilisateurs configurable (Configurable User model). Il est donc possible de remplacer le modèle par défaut. Plusieurs classes abstraites sont disponibles pour faciliter l'intégration de son modèle avec le reste du framework (gestion des permissions) ou étendre le modèle User existant.
L'utilisation des profiles est toujours prise en charge mais la méthode get_profile du modèle User sera supprimée dans la version 1.7.
Pour ceux qui souhaitent migrer vers ces nouveaux modèles d'utilisateurs, south devrait faciliter la migration de la base de données. Cette question sur Stack Overflow donne quelques pistes.
Python 3
Il y a du changement sur les versions de Python prises en charge. Le support de Python 3 (en version 3.2) est de la partie. Pour le moment ce support est expérimental et certaines fonctionnalités dépendant de bibliothèques externes ne sont pas disponible avec Python 3. De plus, il faudra attendre que les applications les plus populaires soient également compatibles. À noter que la même base de code tourne sous Python 2 et Python 3.
Le support de Python 2.5 est quant à lui passé à la trappe. Cela devrait surtout impacter les utilisateurs de Jython qui peuvent se rabattre sur la version alpha de Jython 2.7 (supportée par Django).
Gestion améliorée des streamings responses
Avant Django 1.5, il était possible de créer des réponses de type « streaming » en passant un itérateur au constructeur HttpResponse. Malheureusement, ce comportement complique l'écriture des middlewares qui risquent de consommer l'itérateur. Pour palier ce problème, une nouvelle classe (StreamingHttpResponse) est disponible. Les middlewares peuvent dorénavant adapter leur comportement suivant le type des réponses reçues.
Améliorations de l'ORM
Plusieurs nouvelles fonctionnalités peuvent améliorées les performances de l'ORM.
Lors de l'enregistrement d'une instance (méthode .save() en base de données, il est désormais possible de limiter les champs sauvegardés. Cela permet de limiter les risques d'écrasement lors d'accès concurrents. Les instances différées (obtenues via les méthodes .only() et .differ()) limitent automatiquement aux champs pré-chargés et à ceux qui ont été explicitement modifiés.
Lors du parcours des relations, l'ORM évitera de récupérer les objets précédemment chargés. Par exemple, dans l'exemple suivant :
>>> first_poll = Poll.objects.all()[0]
>>> first_choice = first_poll.choice_set.all()[0]
>>> first_choice.poll is first_poll
TrueAvec Django 1.5, la troisième ligne n'exécute plus de requête SQL pour récupérer first_choice.poll puisqu'il a été défini par la deuxième ligne. Cette amélioration peut s'avérer très utile en combinaison de la méthode prefetch_related introduite dans Django 1.4.
La suppression d'un ou plusieurs objets est accélérée quand il n'y a ni signaux enregistrés ni suppressions en cascade.
Les modèles peuvent définir des index multi-colonnes.
Améliorations de la documentation
Les djangonautes auront l'agréable surprise de découvrir une nouvelle page d'accueil de la documentation mieux structurée. Plusieurs nouveaux tutoriels ont été écris dont l'un sur l'écriture d'applications réutilisables et un autre sur l'écriture de tests.
Template tag {% verbatim %}
Les templates javascript devenant de plus en plus populaire il fallait une solution pour éviter leur collision avec la syntaxe de template de Django. Vous pouvez maintenant utiliser la balise de bloc verbatim afin d'éviter l'analyse du contenu de la balise.
Récupération des instances associées ContentType avec des modèles de proxy
Les méthodes ContentTypeManager.get_for_model() et ContentTypeManager.get_for_models() ont un nouveau mot-clé comme argument- respectivement for_concrete_model et for_concrete_models. En passant False en utilisant cet argument, il est désormais possible de récupérer le ContentType associé à des modèles de proxy.
Autres changements
- La commande
dumpdataretourne les données lignes par ligne pour éviter les congestions de mémoire lors de l'export d'un grand nombre de données -
LOGIN_URLetLOGIN_REDIRECT_URLaccepte désormais les chemins de vues ou les noms de chemin d'URL tels que l'on puisse désormais écrireLOGIN_URL="testapp.mavue"ouLOGIN_URL="mylogin" - Fini les erreurs bien moches si l'on a oublié d'avoir des templates
404.htmlou500.html: Django affiche désormais des pages génériques pour ces situations si les templates correspondants ne sont pas présents. Les codeurs consciencieux que sont les developeurs Python s'assureront tout de même de que ces templates soient présents. - Un signal existe si un utilisateur n'a pas réussi a s'authentifier.
- Abandon du module simplejson pour le module standard json
- La commande
loaddatapossède un argumentignorenonexistentpour ignorer les champs présents dans le fichier qui n'existent plus dans vos modèles - Possibilité de filtrer par requête dans l'administration
Quelques statistiques
Le projet django a migré de subversion vers git en avril 2012.
Entre la version 1.4 et la version 1.5, il y a eu 13513 commits (git log --no-merges --pretty=oneline 1.4 1.5 | wc -l)
$ git diff --shortstat 1.4 1.5
3758 files changed, 164853 insertions(+), 153265 deletions(-)
Modules utiles
On compense le retard de l'annonce de la sortie de Django en parlant de modules sympas sortis ou ayant une utilité particulière entre la 1.4 et 1.5 :
- Le tueur de Wordpress : Mezzanine (CMS)
- Le destructeur de Piston : Django REST Framework (API)
- L'altérateur de l'Escuelle : South (DB)
Mezzanine
Mezzanine est un Système de gestion de contenu (Content Management System ou CMS) distribué sous licence BSD. Basé sur Django, il se veut être une alternative à Wordpress. Il fournit un CMS complet qui peut être déployé sans écrire une seule ligne de code. Il propose de nombreuses fonctionnalités, telles que :
- navigation hiérarchique
- une interface d'administration complète (édition des pages, gestion des redirections, des médias, des formulaires)
- éditeur WYSISWYG (via TinyMCE, remplaçable par du Markdown)
- moteur de blog
- gestion des tags
- intégration avec plusieurs services externes (Disqus, Gravatar, Twitter, bit.ly, Askimet…)
- une boutique en ligne Cartridge
- et beaucoup d'autres fonctionnalités
Ces fonctionnalités sont intégrées de manière cohérente. Par exemple, le thème par défaut (basé sur Twitter Bootstrap) active le service de commentaires Disqus si celui-ci est configuré. Si Mezzanine propose un CMS complet, il reste facilement personnalisable. Les templates sont plutôt bien découpés et il est assez simple d'intégrer ses propres modèles de pages.
Mezzanine est un bon choix pour les débutants qui veulent déployer un CMS tout en découvrant Django.
La version 1.4.3 est sortie le 27 février et est compatible avec Django 1.5.
Django REST Framework
Dans ce joli monde des frameworks Javascript la nécéssité de représenter ses modèles via une interface CRUD devient de plus en plus impérative. Plusieurs applications Django existent dans ce sens comme :
Ce dernier à l'avantage de possèder une syntaxe se rapprochant du système de vues objet naturel de Django Class based views
La jolie n'image présente en page d'accueil du site de Django REST Framework est la représentation en HTML de l'API. Toute requête sur la même url avec par exemple le content-type application/json ou le paramètre format=json l'affichera en JSON.
Pour reprendre l'exemple voici ce que donnerai l'exposition du modèle User de base de Django : Tout d'abord, on configure un serialiseur qui s'occupera de déterminer comment traiter les données :
testapp/serializers.py
from rest_framework import serializers
class UserSerializer(serializers.ModelSerializer):
class Meta:
model = User
fields = ('url', 'username', 'email')Une vue pour présenter ces données :
testapp/views.py
from django.contrib.auth.models import User
from testapp.serializers import UserSerializer
from rest_framework import generics
class UserList(generics.ListCreateAPIView):
model = User
serializer_class = UserSerializerEt enfin les urls associées :
testapp/urls.py
from django.conf.urls import patterns, url
from rest_framework.urlpatterns import format_suffix_patterns
from testapp import views
urlpatterns = patterns('',
url(r'^users/$', views.UserList.as_view(), name='user-list'),
url(r'^users/(?P<pk>[0-9]+)/$', views.UserDetail.as_view(), name='user-detail')
)Pour jouer avec vous avez un joli bac à sable
south
South est une application qui se révèle rapidement indispensable puisqu'elle apporte la gestion des migrations des bases de données.
La dernière version de south (0.7.6) est en grande partie compatible avec Django 1.5 à l'exception de :
- la prise en charge des index multi-colonnes ticket correspondant
- le changement simple du modèle User (voir cette discussion sur les problèmes à résoudre)
Aller plus loin
- Notes de version (141 clics)
- Annonce de la sortie (41 clics)
- Annonce de la sortie de la 1.4 sur LinuxFR.org (40 clics)
# Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 10. Dernière modification le 06 mai 2013 à 11:38.
Je vais faire le mec sceptique… Il y a quelques années (2009 je crois) j'ai mis en place une archi "cloud" basée sur Turbogears pour toute la partie interface utilisateur / admin, web d'une manière générale. Depuis, mes anciens collègues ne jurant que par Django me remontent à chaque fois l'avance technologique et le plaisir d'utiliser et de développer avec Django.
A l'époque, ce qui m'avait principalement décidé à ne pas utiliser Django, c'était l'ORM complètement intégré et pas "exportable", par exemple pour faire des cron ou des démons indépendants, tout en factorisant au maximum le code et en le réutilisant.
Turbogears n'est pas un framework très à la mode, il a failli l'être mais je dirais qu'il est désormais plus "un ancien outsider". Il avait pour faiblesses par rapport à Django, à l'époque, entre autres des performances nettement moindre et moins d'applications "ready-to-use" disponibles. C'est toujours le cas, je pense.
Néanmoins, Django 1.5 apporte comme nouveautés :
- un ORM qui autorise les index multi-colonnes - c'était déjà disponible sur Turbogears via SQLAlchemy en 2009
- La sélection des champs mis à jour lors de la sauvegarde en base de données - c'est ce que fait nativement SQLAlchemy depuis bien longtemps également
- Un modèle d'utilisteur configurable - c'est également quelque chose qui était déjà disponible en 2009 dans TG ; je m'étonne même que ce n'était pas disponible dans Django avant la version 1.5
Un autre sujet qui me gène toujours avec Django, c'est la "non-réutilisabilité" de l'ORM hors web. Comme je n'ai pas beaucoup développé en python ces dernières années, je me demande comment font les dév. utilisant Django pour toutes les tâches de backoffice. Est-ce que vous codez du SQL en dur si vous en avez besoin ? Est-ce que vous utilisez d'autres technos "ORM" ? Est-ce que tout tourne sur un serveur web - quel genre d'infra vous utilisez ?
Ceci est une vraie question : quand je vois l'engouement pour Django, je me dis qu'il y a bien une raison - et que ce n'est pas juste la multitude de "composants" (ou applications) dispo qui décide à choisir cette techno par rapport à d'autres (comme Pyramid, par exemple) ; et je me pose la question de la réutilisation du code "hors web".
Je suis curieux (sincèrement) de retours d'expériences, de ce que Django vous a apporté par rapport aux framework concurrents, les limites que vous y trouvez et comment vous les avez contournées.
Sinon, pas totalement dans le sujet, mais pas hors-sujet non plus, un très bon texte expliquant les différences de philosophie entre l'ORM intégré à Django et SQLAlchemy - http://lucumr.pocoo.org/2011/7/19/sqlachemy-and-you/ . On y découvre la "super-puissance" de SQLAlchemy - au prix d'une mise en oeuvre plus complexe (en tout cas pour les premiers pas).
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par claudex . Évalué à 4.
Je n'ai pas une grande expérience de Django mais pour le site que je développe (si je retrouve du temps pour m'y mettre), j'ai besoin d'un daemon qui met régulièrement la base de données à jour. Et je me suis orienté vers une API REST que le daemon appelle.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par redgriff . Évalué à 9.
On peut définir ses propres commandes que l'on peut appeler via le script
./manage.py. Ça se lance facilement via une tâche cron. Et il y a aussi le shell python (./manage.py shell) qui initialise l'ORM.[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par flan (site web personnel) . Évalué à 2.
Accessoirement, on peut faire les choses encore plus proprement, avec un fichier setup.py bien construit, et en renommant (et modifiant un peu) le manage.py en monprojet-admin.
Le setup.py permettra d'installer le site web (qui est en fait un — ou plusieurs — module Python) comme n'importe quel autre module Python, et monprojet-admin sera installé parmi les autres binaires, donc dans /usr/bin ou /usr/local/bin.
Il faut simplement modifier le manage.py pour changer le env.setdefault('DJANGO_SETTINGS', 'monprojet.settings') en env['DJANGO_SETTINGS'] = 'monprojet.settings'
On aura donc un exécutable accessible depuis n'importe quel dossier permettant d'appeler les différentes commandes, y compris les commandes définies dans monprojet/manage/commands ( cf. https://docs.djangoproject.com/en/1.5/howto/custom-management-commands/ )
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par laurentm . Évalué à 1.
C'est exactement le principe que j'utilise pour mes nouveaux projets réalisés avec Django. J'ai au final un fichier .tar.gz installable facilement avec
pip. Ça simplifie pas mal les déploiements.Tout est décrit en détail ici : http://www.deltalima.net/blog/django-packager-un-projet/
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par godzom . Évalué à 3.
Pour les batchs, rien ne t'interdit de les écrire en Python, tu peux avoir accès ainsi à toute l'API, le modèle, l'ORM…
Ton batch sera juste un programme python qui utilise les modules de ton application Django.
Je ne saisis pas vraiment le problème.
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 2.
En fait, la question c'est de pouvoir embarquer le minimum de dépendances pour ce que l'on veut faire.
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par morgotth . Évalué à 2.
Ton commentaire me fait sourire car j'avais les mêmes questions sans réponse il y a 6 mois :)
Pour vendre Django (que j'utilise actuellement pour un projet scolaire depuis 6 mois), je dirais que tous les composants à utiliser apportent :
une communauté "pertinente" : il n'y a qu'un seul moyen recommandé de faire, et quelqu'un a déjà eu le problème qu'on peut rencontrer : la réponse est déjà sur stackoverflow/dans la doc. Reprendre le code d'un autre développeur est même un jeu d'enfant
de la simplicité : vu que tous les composants sont fournis par Django, ils ont la même logique et interagissent entre eux nativement
de la productivité : tout est super bien pensé, contrairement à d'autres concurrents (voir ce comparatif des frameworks Web Python)
Après pour ton problème d'accès à la BDD, j'ai eu le même problème et j'ai choisi la facilité : j'ai pris Peewee et je l'ai laissé créer les classes de base via ma base, produite par Django via :
Et après quelques corrections, j'ai pu l'attaquer avec un Peewee à la syntaxe semblable à l'ORM Django.
C'est sur que c'est pas très DRY mais tout l'univers Django n'est pas fermé sur l'extérieur, pour preuve son système de template utilisable via Jinja2.
La solution de faire ses propres commandes par redgriff est sympa également, où encore cette solution (non testé).
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par David Thenon (site web personnel) . Évalué à 3.
Je fais du Django depuis la 0.95, j'ai commencé avec Django principalement parce que les autres frameworks de l'époque ne me plaisaient pas, globalement je les trouvaient beaucoup plus compliqué à utiliser pour mettre en oeuvre des choses assez simples. L'API de Django me semblaient plus souple et plus "évidente".
Au fil du temps je n'ai pas vu grand chose de plus engageant chez les autres frameworks web Python, à part depuis 1 ou deux ans avec des projets comme Pyramid. Et puis la communauté et les applications Django ont tellement bien évolués que je trouve peu d'intérêts à passer à un autre framework web Python.
J'ai fait pas mal de sites "vitrines", mais aussi des grosses usines à gaz comme une plateforme de médias, un site communautaire-social-machin, une plateforme de dossiers de financements, etc.. Et j'ai eu peu de gros soucis techniques sur lesquels me prendre la tête, à part le fameux modèle utilisateur et profile, ainsi qu'un truc plus pointu avec les uploads de très très gros fichiers. Bref au final, j'ai rarement eu à me prendre la tête à savoir si je pourrais faire telle ou telle chose avec Django, uniquement le "plaisir" de le modéliser.
Pour ce qui est du côté portable de ce que produit son ORM, je suis toujours parti du principe "d'embrasser" le principe de l'ORM au maximum, pour les scripts CRON tu peux facilement leur faire accéder à l'API et ton environnement Django. Je me doute que c'est pas aussi léger que certains pourrait le souhaiter, pour des modèles de données relativement simples tu peux facilement les porter pour SQLAlchemy, ensuite pour des choses plus évolués c'est évidemment moins simples.
Je faisais ça dans certains cas jusque dans la version 1.1 où l'ORM s'est vachement arrangé, ensuite j'ai totalement abandonné le principe, c'est trop lourd à maintenir je trouve.
Depuis 2/3 ans je crois qu'il doit y avoir vraiment très peu de services que tu ne puisses pas monter avec Django. Personellement j'aime bien la simplicité de monter sa webapp avec Apache+fcgi, mais dans ma boîte c'est que du nginx et c'est très satisfaisant, j'ai pas connaissances de crash ou de gros problèmes de charges anormales.
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par GeneralZod . Évalué à 5.
Je partage ton opinion sur Django ORM, sans l'intégration poussée au reste qui rattrape le tout, c'est une belle #?@!§ d'autant plus quand on le compare à l'existant (SQLA, Storm, Peewee). Mais pour moi, le véritable inconvénient de Django est le non support de la norme WSGI.
Je ne parle pas de la partie déploiement, mais des middlewares qui font tout l'intérêt de la chose. Ça fait des années que RoR supporte Rack (plus ou moins l'équivalent rubyiste de WSGI).
La plupart du temps, SQLA est capable d'importer n'importe qu'elles tables sans problèmes, mais Django ORM non. Le plus simple c'est de concevoir sa base avec Django ORM et d'utiliser un vrai ORM pour le backend. J'aime pas trop l'idée que ça se fasse dans ce sens mais c'est le plus simple.
Sinon, t'abstrait complétement la base de données métiers mais ça demande plus de taff.
La vraie force de Django c'est qu'il réponds à 80% des besoins avec un minimum d'efforts, là où d'autres frameworks comme Pyramid, Flask, etc. t'offrent plus de puissance mais au prix d'une configuration un peu plus longue et l'utilisation de plugins tiers.
Le seul vrai concurrent dans la catégorie framework tout-en-un que Django ait vraiment connu c'est TurboGears, mais les différentes migrations (TG 1/ 1.1/2.x etc.) et leurs aléas, une documentation moins complète, et une gestion de projet parfois chaotique (TG3 il est où ?) ont fait que ce qui était en 2006/2007 un produit supérieur à Django, aujourd'hui, un projet clairement sur le déclin (beaucoup sont passé à Pyramid).
Au final, Django est dans la lignée "Get the shit done", avec une très bonne finition (migration de version, documentation, etc.)
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par flan (site web personnel) . Évalué à 1.
quels sont les problèmes avec wsgi et l'ORM, exactement ?
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par LeBouquetin (site web personnel, Mastodon) . Évalué à 1.
De ce que j'ai lu à propos de l'ORM de Django, et par rapport à SQLAlchemy que je connais bien :
- il ne supporte les clés primaires multiples que depuis la version 1.5 (la dernière). Pour quelqu'un qui conçoit un schéma de base avec en tête l'idée que la base de données garantit autant que faire se peut l'intégrité et la cohérence des données, c'est un cas classique.
- il ne gère pas des transactions "tout en un" comme le fait SQLAlchemy par exemple. Exemple : tu as un formulaire qui génère différentes requêtes SQL qui doivent êtres toutes faites dans une unique transaction, Django ne le gère pas. Dans beaucoup de cas, ce n'est pas utile, mais dans certains cas c'est rédhibitoire. Par exemple, si ton formulaire doit faire un insert dans 2 tables et que l'un ne va pas sans l'autre, ce n'est pas garanti quand tu développes avec Django, ça l'est (ou ça peut l'être) quand tu utilises SQLAlchemy
- tu ne peux pas utiliser l'ORM de Django sans emporter avec toi django-full-package ;)
- il n'enregistre pas "les valeurs qui ont été changées" mais "un tuple complet" ; quoique visiblement cela ait été amélioré dans la dernière version.
En fait, pour moi ce qui est vraiment "moche", c'est d'emporter tout Django si tu veux juste l'ORM. Par exemple, si j'ai un client lourd et une appli web qui accèdent à la même base de données, soit je dois utiliser 2 technos différentes pour faire l'ORM, soit je dois embarquer Django dans mon client lourt.
Est-ce que tu utiliserais une techno qui t'impose d'embarquer QT pour tes applis web ?
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par laurentm . Évalué à 4. Dernière modification le 07 mai 2013 à 10:16.
Si je comprends bien de quoi tu parles, c'est tout à fait possible avec Django, mais ce n'est pas le comportement par défaut (ce que je trouve dommage…).
Par défaut, Django fait de l'auto-commit pour chaque query, c'est pas terrible dans certain cas (comme celui de ton exemple). Mais il est toutefois est possible de coupler une transaction SQL à une requête HTTP. Dans ce cas, la transaction commence avant le traitement de la View et est commitée si tout se passe bien, si une exception est levée pendant le traitement, la transaction est annulée (rollback).
Django permet également de gérer finement les transactions en indiquant explicitement quand elle commence, et si on fait un commit ou un rollback.
Tous les détails sont ici : https://docs.djangoproject.com/en/1.5/topics/db/transactions/
Pour les cas tordus comme une transaction qui dure plusieurs requêtes HTTP (dans le cas d'un wizard qui est sur plusieurs "écrans" par exemple), je ne sais pas si c'est possible avec Django, je n'en ai jamais eu besoin.
Pour les autres points, je suis d'accord avec toi.
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par flan (site web personnel) . Évalué à 1.
Nous sommes d'accord, il y a un certain nombre de manques, mais beaucoup ont été comblés sur les dernières versions 1.4 et 1.5.
Quant à la dépendance à Django… bof, je ne suis pas convaincu.
Oui, il faut installer une dépendance à django quand on veut utiliser « django-orm ». Mais je ne vois pas le problème, à vrai dire.
Que tu installes « django-orm » ou « django-full », dans les deux cas, tu as une seule et unique dépendance. Effectivement, si tu utilises uniquement l'ORM, tu as quelques fichiers qui ne serviront jamais à rien, et qui doivent bien prendre 0,01% de l'espace sur un serveur de base.
Ce n'est pas comme pyqt qui ramène un certain nombre d'autres dépendances (et binaires qui plus est, donc moins évidentes à distribuer).
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par GeneralZod . Évalué à 4.
Pour l'ORM, on a déjà répondu.
Pour les middlewares WSGI, Django propose les apps, mais du coup ça fragmente l'écosystème: Django ne peut pas monter une application WSGI facilement (chose qui est extrêmement courante dans le monde Ruby), se prive de composants éprouvés (notamment repoze.*) et inversement les app Django ne sont pas réutilisables dans une app WSGI classique.
Supposons que tu veuilles migrer progressivement une application d'un framework à l'autre ou réécrire certaines parties avec un framework plus adapté (par exemple un endpoint API extrêmement sollicité), n'importe quel framework WSGI te permettra de le faire assez simplement, avec Django, tu es obligé d'en réécrire une bonne partie.
La question est de savoir si oui ou non, c'est un problème dans ton contexte ? Le but de Django c'est de monter rapidement des applications web de manière propre et la mission est réussie. Mais il y a différents cas où Django n'est pas forcément la meilleure solution: intégration à un système existant, endpoint API etc.
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par laurentm . Évalué à 3.
Peux-tu expliquer ce que tu entends par la non-réutilisabilité de l'ORM hors web ? Je ne vois pas trop ce qui pourrait empêcher l'utilisation de l'ORM Django en dehors d'un environnement web … même si Django lui-même est très très orienté web.
Personnellement, pour les tâches CRON, j'utilise un script Python qui ressemble à ceci :
Ce script fonctionne très bien hors web, j'ai bien accès à l'ORM de Django. Le seul truc un peu sioux c'est l'ajout de la ligne
os.environ.setdefault("DJANGO_SETTINGS_MODULE", "myapp.settings")avant l'import du modèle.Mais ce n'est peut-être pas ce genre de chose que tu appelles des tâches de backoffice…
[^] # Re: Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par Antoine . Évalué à 2.
Bien sûr qu'il est réutilisable, le seul truc pénible est de devoir malgré tout créer un ersatz de projet Django avec son settings.py associé.
(mais, oui, SQLAlchemy est plus puissant)
C'est surtout qu'il est à peu près mort. Et à l'époque où je l'avais utilisé, il y avait de gros problèmes de qualité. Django est vivant et bien maintenu.
# Django : profitons de l'occasion ...
Posté par Christophe B. (site web personnel) . Évalué à 1.
Bonjour à tous,
Je cherche des réponses sur un certain nombre de questions et notamment sur Django et le dev WEB.
mon vrai job c'est Administrateur Système DBA, mais dans ma jeunesse (au siècle dernier) j'ai beaucoup développé mais le web n'existait pas.
Bref j'essaie de me bricoler des petites applis Web sans résultat flamboyant il faut le reconnaître.
Django est un bel outil, il permet de faire rapidement des choses propres et simples coté serveur, la structure app views urls est limpide.
Mais je suis a la recherche de quelque chose d'aussi simple coté Navigateur, j'ai essayé plusieurs pistes :
- XUL, très bien mais ça bouge plus et ne tourne que sur firefox
- HTML+CSS+templates Django : mon dieu que c'est compliqué, vous faites ça tout les jours ?
Faire une appli simple (style gestion de contact) avec une liste + un formulaire cela va tres vite. Lui donner un "look" sympa avec les interactions qui vont bien c'est loin d'être simple et limpide. Rien que le fait de vouloir conserver la liste au milieu avec une taille fixe et la pagination …
Alors dernierement pour avoir un semblant de résultat qui ne ressemble pas à l'époque MOSAIC NCSA, j'utilise framework Javascript Extjs, mais plutôt que de me cogner pour chaque page des centaines de lignes de javascript, je le fais générer par Django et la cela devient presque simple, par contre j'en suis au stade de la gestion de contact CRUD.
ET n'ai AUCUNE idée si c'est franchement utilisable en production.
Ma question dans tout cela est :
- avec Django qu'utilisez vous coté navigateur ?
- Le CSS est il la seule solution ?
- Javascript est ce la panacée ?
je cherche une solution simple et efficace (même si ya pas de logo en flamme :))
BEGIN MODE TROLL
Pour moi, Javascript (comparé à python) ressemble à un long discours d'un seule phrase sans ponctuation ni paragraphe, et donc il faut avoir du souffle pour le lire a voix haute :)
une vrai plaie ces accolades et parenthèses …
END MODE TROLL
Messieurs les pros du web, je vous saluent.
A+
[^] # Re: Django : profitons de l'occasion ...
Posté par laurentm . Évalué à 1.
Salut Christophe,
Beaucoup de questions … je vais essayer d'y répondre :)
Pour faire du web maintenant, c'est HTML5+CSS+JS. Tu peux oublier tout le reste (flash, xul, activex, etc.). Par contre, tu n'est pas obligé de faire du HTML5/CSS/JS à la main si tu n'aimes pas ça. Il existe des alternatives qui permettent d'améliorer les choses (syntax plus simple, plus haut niveau, …).
Pour le look sympa, tu peux jeter un oeil du côté des framework CSS. Perso, je suis fan de Bootstrap. Ça permet d'avoir un style pas trop mal dès le début du projet, et si tu n'aimes pas le style par défaut tu peux lui ajouter un thême.
Pour les intéractions côté client, c'est du JS uniquement (via CoffeeScript tu si préfères). C'est un peu la loose de tout gérer à partir de rien. Et là aussi, il existe des framework qui nous viennent en aide : jquery, EmberJS, Angular, Backbone, …
Et si à ce stage vous n'avez pas encore rempli votre grille de Bullshit Bingo, je vais vous arranger ça… :)
Dernièrement, j'ai réalisé une petite appli web en mode "Single-page application" pour gérer une liste de contacts. Elle a été réalisé avec les outils suivants : Ember.js, Django, Bootstrap, Tastypie et ember-data-tastypie-adapter.
Le code est sur github si tu veux y jeter un oeil : https://github.com/lmeunier/django-ember-contactmvc
J'espère que ça répond à tes questions…
[^] # Re: Django : profitons de l'occasion ...
Posté par Christophe B. (site web personnel) . Évalué à 2.
Tout d'abord merci, enfin quelques pistes pour se diriger dans cette jungle :)
activex : une erreur de la nature :)
xul : dommage j'aimais bien, pour moi il ne manquait que certaines petites choses comme la possibilité d'éditer les colonnes d'une grille sinon j'avais reussi a faire de petites choses sympa.
J'avais envisagé la même chose mais pour la génération de rapport automatique, tu generes du Rst
puis un petit coup de rSt2html
oula, tres interressant je vais creuser la question …
La aussi, tres interressant a creuser
Merci pour la découverte de tout ca, en plus il pleut … cela tombe bien
J'ai vu la demo de ta gestion de contact, simple, efficace.
Encore merci …
A+
chris
[^] # Re: Django : profitons de l'occasion ...
Posté par laurentm . Évalué à 1.
En y réfléchissant un peu plus, utiliser c'est le markdown ou rst c'est pas forcement la meilleur solution pour générer du HTML. On est bien trop limité. Tu trouveras peut-être ton bonheur avec des trucs comme Haml ou Slim.
Je ne sais pas où tu te trouves, mais ici meteofrance a prévu plusieurs jours de pluie :) Si c'est pareils pour toi, voici encore un peu de lecture.
CrEv a écrit une série de journaux sur toutes les nouvelles techno pour faire du web. C'est très intéressant et tu découvriras plein d'autres outils.
http://linuxfr.org/users/crev/journaux/ecrire-une-page-web-de-nos-jours
http://log.winsos.net/2012/12/05/ecrire-une-page-web-de-nos-jours-suite-des-aventures.html
http://linuxfr.org/users/crev/journaux/ecrire-une-page-web-de-nos-jours-troisieme-partie
http://linuxfr.org/users/crev/journaux/web-log-today-est-juillet-ecrire-un-blog-de-nos-jours
[^] # Re: Django : profitons de l'occasion ...
Posté par Christophe B. (site web personnel) . Évalué à 1.
J'en ai profité pour chercher un hebergement gratuit pour "faire comme les grands" et mettre en pratique sur le web.
J'ai commencé par Openshift : prometteur mais pas stable
ensuite j'ai trouvé pythonanywhere
Dommage Django 1.3.7 et un peu lourd a utiliser mais on y arrive
si quelqu'un sait pourquoi leur console ne gere pas certaines touches …
Et donc voila que pensez vous de ça :
petite gestion de contact ?
Le truc je genere du javascript a la volée ainsi la création de la grille est faites comme ceci
vous pouvez voir le code généré dans la source de la page
Les templates deviennent ridiculement simple, tout se gère coté Django/views (donc python) bref que du bonheur pour moi.
par contre c'est lié au framework JS mais bon ExtJS m'a l'air complet et le look est simple et efficace comme j'aime.
[^] # Re: Django : profitons de l'occasion ...
Posté par CrEv (site web personnel) . Évalué à 2.
Tu parles du code que tu as écris, tu code que tu as lu, du code écris avec une lib ?
En général, lorsque tu lis du code jquery, ça va souvent être le cas. Récemment j'ai du corriger le code d'un plugin pour jquery, c'est juste horrible.
Mais ce n'est pas lié vraiment à javascript, c'est plus lié à une mauvaise façon de l'écrire. On n'est pas dans du spaghetti, mais au final ce n'est pas mieux. Mais il est tout à fait possible d'écrire du code js clair, bien formé, lisible.
Voir par exemples les recommandations de Google sur le sujet : http://google-styleguide.googlecode.com/svn/trunk/javascriptguide.xml
[^] # Re: Django : profitons de l'occasion ...
Posté par Christophe B. (site web personnel) . Évalué à 1.
Du code ecris avec la lib extjs (toutes versions confondues), pour être précis.
J'avais ecris un peu de trucs avec xul mais bon c'était mon code.
La pour apprendre, tu prends les exemples, tu regardes les sources des autres … et une bonne partie de tout cela est une immense fonction Ext.OnReady composée de fonction Ext.Create elles mêmes composées de Fonction callback etc … même bien indentées c'est pas lisible comme du python.
La recherche de l'accolade ou de la parenthese manquante demande parfois un grand ecran vu que le debut de la fonction se trouvent 200 lignes + haut.
Bon pour être honnête c'était surtout l'occasion de dire une méchanceté gratuite, il faut reconnaître que ce langage permet de faire beaucoup de choses :).
A+
chris
# Guide pour la migration du "user_profile" vers un "custom user model"
Posté par Ponytech (site web personnel) . Évalué à 2.
Si vous aviez un projet utilisant le user_profile et que vous souhaitez le migrer vers un custom user model (pour, comme évoqué dans la news, éviter de faire une jointure par exemple) j'ai écrit un petit guide avec South (en anglais) détaillant les étapes.
Feedback bienvenu.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.