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).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo
# Le buzz autour de Django et les "nouveautés" toutes relatives
Posté par LeBouquetin (site web personnel, Mastodon) . En réponse à la dépêche Retour sur Django 1.5. É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).
#tracim pour la collaboration d'équipe __ #galae pour la messagerie email __ dirigeant @ algoo