Je pense que ton soucis de passer le request.user en argument à ton contrôleur de formulaire avec les vues génériques doit pouvoir être simplifié avec l'arrivée des Class Based Views […]
Oui, mais ça ne résout absolument pas le problème des validations, elles auraient besoin du request quand même ! Et les avoir dans le init empêche l'écriture correcte des validations, sauf si on met l'objet request dans l'instance de l'objet. Je trouve pas ça top.
Et c'est plus pour l'aspect cosmétique
Rien à dire au niveau de l'écriture des templates, tout est faisable, sauf dans des cas particuliers où l'écriture d'un tag ou d'un filtre peut s'avérer… fastidieuse (ex : j'ai prévu une méthode dans mon objet pour faire de l'affichage. Cette méthode prend un paramètre : l'utilisateur actuellement identifié. Je ne peux pas l'appeler directement, je dois exécuter cette méthode pour le passer dans le contexte au niveau de la vue, ce qui n'est pas faisable dans le cas de l'affichage d'une liste d'objets, donc je dois écrire un tag…)
Il n'y a pas de réelle validation dans les formulaires sinon ceux des champs de ton modèle
Pas d'accord : il y a toute une page sur la validation des champs de formulaire… D'ailleurs, tous les champs de formulaire ne sont pas nécessairement associés à un champ de modèle. Et justement, cette validation fait double emploi, à mon sens, avec les validateurs qui, eux, agissent au niveau du modèle.
Les releases de Django essayent en général de temporiser entre les gros changements ou ajouts, la 1.3 c'était l'arrivée Class Based Views, la 1.4 laisse un peu le temps aux développeurs pour les implémenter vu que les function views seront deprecated à partir de la 1.5.
Et alors ? Le temps n'a rien à voir avec le numéro de version. Je trouve leur timeline mal fichue, et des fonctionnalités (je veux dire des outils qui apportent un réel plus au développeur, comme des travaux sur les formulaires) se font, à mon sens, attendre. Je parle par exemple d'outils pour une meilleure gestion des fichiers statiques (pour faire du less, ou pour compresser le JS, ou encore créer automatiquement des sprites), ou bien un outil intégré pour faire les migrations, … Alors oui, on va me dire qu'il existe des outils externes (j'en utilise plein), mais j'ose la comparaison avec rails (que je ne maîtrise absolument pas pour l'instant, je suis encore en phase de découverte du produit) et quel bonheur de se retrouver avec plein d'outils qui simplifient la vie dès le début du projet !
Je crois que je pourrais encore bcp critiquer Django, et pourtant je l'utilise tous les jours pour un projet relativement vaste. Ça me fait mal de dénigrer ce projet, car Django m'a sauvé la vie plus d'une fois et m'a fait apprécier le développement web. La version 1.4 m'a déçu parce qu'elle a été longue à arriver pour aucune nouveauté apparente. Dire que ZE big news est la gestion des dates après 1 an de développement, je reste un peu sur ma faim…
[^] # Re: Mangez-en, c'est bon !
Posté par Damien Szczyt (site web personnel) . En réponse à la dépêche Sortie de Django 1.4. Évalué à 1.
Je pense que ton soucis de passer le request.user en argument à ton contrôleur de formulaire avec les vues génériques doit pouvoir être simplifié avec l'arrivée des Class Based Views […]
Oui, mais ça ne résout absolument pas le problème des validations, elles auraient besoin du request quand même ! Et les avoir dans le init empêche l'écriture correcte des validations, sauf si on met l'objet request dans l'instance de l'objet. Je trouve pas ça top.
Et c'est plus pour l'aspect cosmétique
Rien à dire au niveau de l'écriture des templates, tout est faisable, sauf dans des cas particuliers où l'écriture d'un tag ou d'un filtre peut s'avérer… fastidieuse (ex : j'ai prévu une méthode dans mon objet pour faire de l'affichage. Cette méthode prend un paramètre : l'utilisateur actuellement identifié. Je ne peux pas l'appeler directement, je dois exécuter cette méthode pour le passer dans le contexte au niveau de la vue, ce qui n'est pas faisable dans le cas de l'affichage d'une liste d'objets, donc je dois écrire un tag…)
Il n'y a pas de réelle validation dans les formulaires sinon ceux des champs de ton modèle
Pas d'accord : il y a toute une page sur la validation des champs de formulaire… D'ailleurs, tous les champs de formulaire ne sont pas nécessairement associés à un champ de modèle. Et justement, cette validation fait double emploi, à mon sens, avec les validateurs qui, eux, agissent au niveau du modèle.
Les releases de Django essayent en général de temporiser entre les gros changements ou ajouts, la 1.3 c'était l'arrivée Class Based Views, la 1.4 laisse un peu le temps aux développeurs pour les implémenter vu que les function views seront deprecated à partir de la 1.5.
Et alors ? Le temps n'a rien à voir avec le numéro de version. Je trouve leur timeline mal fichue, et des fonctionnalités (je veux dire des outils qui apportent un réel plus au développeur, comme des travaux sur les formulaires) se font, à mon sens, attendre. Je parle par exemple d'outils pour une meilleure gestion des fichiers statiques (pour faire du less, ou pour compresser le JS, ou encore créer automatiquement des sprites), ou bien un outil intégré pour faire les migrations, … Alors oui, on va me dire qu'il existe des outils externes (j'en utilise plein), mais j'ose la comparaison avec rails (que je ne maîtrise absolument pas pour l'instant, je suis encore en phase de découverte du produit) et quel bonheur de se retrouver avec plein d'outils qui simplifient la vie dès le début du projet !
Je crois que je pourrais encore bcp critiquer Django, et pourtant je l'utilise tous les jours pour un projet relativement vaste. Ça me fait mal de dénigrer ce projet, car Django m'a sauvé la vie plus d'une fois et m'a fait apprécier le développement web. La version 1.4 m'a déçu parce qu'elle a été longue à arriver pour aucune nouveauté apparente. Dire que ZE big news est la gestion des dates après 1 an de développement, je reste un peu sur ma faim…