Je ne connais pas Django, mais ça m'intéresse de savoir se qui se fait ailleurs, et je n'ai pas compris le passage sur QuerySetManager.
La dépêche dit que si l'on voulait créer son propre QuerySetManager, il était alors pénible de l'interfacer avec le QuerySet associé. La solution proposée est de ne pas créer son propre QuerySetManager, mais d'en générer un à la volée. Stricto senso, ça ne répond pas au problème initial, à moins que les classes -SetManager soient toujours des surcouches neutres sur les -Set.
À première vue, ça semble surtout très mal ficelé : dès qu'on voudra enrichir ce SetManager, il faudra changer la structure du code et se taper l'ancienne syntaxe ? Mais j'ai sans doute mal compris.
# Préciser "Simplification des QuerySetManager"
Posté par rogo . En réponse à la dépêche Django 1.7, « le framework web pour les perfectionnistes sous pression ». Évalué à 5.
Je ne connais pas Django, mais ça m'intéresse de savoir se qui se fait ailleurs, et je n'ai pas compris le passage sur QuerySetManager.
La dépêche dit que si l'on voulait créer son propre QuerySetManager, il était alors pénible de l'interfacer avec le QuerySet associé. La solution proposée est de ne pas créer son propre QuerySetManager, mais d'en générer un à la volée. Stricto senso, ça ne répond pas au problème initial, à moins que les classes -SetManager soient toujours des surcouches neutres sur les -Set.
À première vue, ça semble surtout très mal ficelé : dès qu'on voudra enrichir ce SetManager, il faudra changer la structure du code et se taper l'ancienne syntaxe ? Mais j'ai sans doute mal compris.