ZEP-12 : refonte du principe des tutoriels et articles

Exactement

Tient, c'est moi ou t'as remis à jour la branche par rapport à upstream ?

je l'ai fait, en effet. J'ai réussi à avoir des conflits avec ça alors crois-moi, je vais tenter de le faire le plus souvent possible

Bon, ben t'as lu dans mes pensées, parce que j'y pensais.

Plus sérieusement, c'est normal qu'il y aie eu des conflits : j'ai au moins modifié 3 fichiers principaux (url.py, settings.py et des machins dans utils.py, si je me souviens bien), puis je me suis planté une fois et j'ai refactorisé trop fort avec pycharm et j'ai bousillé un machin dans /zds/tutorial/ qui a a mon avis du t'ennuyer, même si je l'ai corrigé par après, donc là … C'est ma faute

non, kdiff me l'a géré comme un grand ça. En fait c'est le travail sur les factories qui a eu du mal à passer. Je ne comprends pas comment c'est possible, mais bon, tant que ça marche <3.

Cette ZEP est-elle concernée par ce message et ceux qui suivent ?

Nope. On refait le module de création de contenu pour qu'il n'y ait plus de différence fonctionnelle mais aussi pour que le versionnage soit plus facile et plus cohérent. Surtout, cela permet d'éviter des requêtes absurdes en bdd.

Need Help !

La ZEP 12 permettra au module de tuto de passer en Class Based View ledit module. Cela économise énormément de code, mais… ça change un peu le code qui a été produit quand même.

notamment, la gestion des décorateurs n'est pas la même. J'aimerai avoir votre avis sur ce qu'on doit faire pour jouer avec les décorateurs de type require_permission. J'ai trouvé cet article mais autant je ne comprends pas la "solution crade", autant je n'ai pas envie d'ajouter une dépendance au projet sans votre accord (pour les mixins). Qu'en dites-vous?

T'essaye de faire quoi, exactement ? Parce que jusqu'ici, j'avais l'impression qu'on était dans le bon en décorant dispatch() avec @method_decorator(), mais peut être que je me trompe ?

on peut pas : require_permission demande des arguments spéciaux.

oui, ça j'ai vu, mais tu veux quelle permission ?

Et avec un mixin tout simple comme dans l'article ?

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

class PermissionRequiredMixin(object):
    permissions = []

    def dispatch(self):
        # vérifier les permissions pour l'utilisateur

class ArticleView(PermissionsRequiredMixin, View):
    permissions = [
        'zds.view_article',
        'zds.create_article'
    ]

    ...

tutorial.change_tutorial

Et avec un mixin tout simple comme dans l'article ?

comment? il existe un équivalent du style self.request.user.has_permission('tutorial.change_tutorial') ?

Tu peut toujours l'écrire : dans le mixin, tu met exactement le décorateur qui est utilisé en ce moment sur la méthode dispatch et ça devrait fonctionner

Et dans ce cas, un décorateur avec paramètres ? J'avais fait un truc avec un décorateur qui va chercher les valeurs de ses arguments dans l'instance de l'objet en cours de rendu ici. Et comme ça tu as directement accès à la requête et à l'objet tutoriel.

J'ai fait un mixin et ça donne ça. C'est sûrement améliorable.

Franchement chapeau les gars pour tout le boulot que vous faites !

Je me permet de citer artragis sur IRC :

1
2

[21:45] <artragis> on n'a pas encore fini notre boulot de réduction et on est passé de 2 modules dont les vues ont 3K lignes à un seule module où les vues où les vues ont 2.5K lignes
[21:46] <artragis> et encore, on a commenté comme des malades

Je sais pas si les urls ont été discutées sur ce sujet, mais j'ai vu le fichier urls_contents.py (visible ici). Il y a des urls comme editer-conteneur et editer-extrait ; il plutôt courant de faire editer/conteneur et editer/extrait. Enfin, je pense que si ça n'a pas été discuté ça le sera plus tard ?

1

from zds.member.decorator import PermissionRequiredMixin

Je te suggère de créer un fichier mixins.py dans le module utils pour être plus clair dans l'organisation des fichiers. Ensuite pour éviter de se répéter au niveau des views j'aurais défini les mixins de cette façon :

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

class PermissionRequiredMixin(object):
    permissions = []

    def check_permissions(self):
        if not self.request.user.has_perms(self.permissions):
            raise PermissionDenied

    def dispatch(self, *args, **kwargs):
        self.check_permissions()
        return super(PermissionRequiredMixin, self).dispatch(*args, **kwargs)

class LoginRequiredMixin(object):

    @method_decorator(login_required)
    def dispatch(self, *args, **kwargs):
        return super(LoginRequiredMixin, self).dispatch(*args, **kwargs)

Ce qui permettrait d'éliminer un peu de code pour les views :

1
2
3
4
5
6
7

class ValidationListView(LoginRequiredMixin, PermissionRequiredMixin, ListView):
    permissions = ["tutorial.change_tutorial"]
    context_object_name = "validations"
    template_name = "tutorialv2/validation/index.html"

    def get_queryset(self):
        ...

En effet, ça n'as pas été réellement discuté, j'ai fait ça au feeling. À mon sens, je trouve ton idée séduisante, d'autant que ça ne change rien au résultat (puisque ce qui est toujours appelé, c'est le nom, et pas l'URL).

Du reste, j'aime bien l'idée de poulp, if any (j'envisage de faire un truc du genre pour les FormView pour lesquels la fonction get_object() est stricto facto toujours la même).

Pour quelqu'un qui a l'habitude du Java, C# et des bases en C++, cette ligne, c'est juste incompréhensible : return super(LoginRequiredMixin, self).dispatch(*args, **kwargs). Je lis ça comme "appelle moi la méthode parente de LoginRequirendMixin quis 'appelle dispatch." Or LoginRequiredMixin n'a pas de dispatch. ça fait mal.

Je lis ça comme "appelle moi la méthode parente de LoginRequirendMixin quis 'appelle dispatch." Or LoginRequiredMixin n'a pas de dispatch. ça fait mal.

Non en fait c'est fait pour appeler les methodes des classes parentes (appelé "super" dans le monde python). En gros il faut lire cette ligne "appel moi la methode dispatch des classes parentes de self en le considérant comme un LoginRequiredMixin". Donc ce n'est pas la méthode de LoginRequiredMixin qui va être appelé, mais celle de la première classe parente qui va être disponible.

A cause du ducktyping, on a pas vraiment le choix si on veut éviter de mettre spécifiquement le nom de la classe parente.

Pour autant je concède que c'est cryptique. En python 3 cette technique a été largement simplifié et se résume souvent à super().dispatch(*args, **kwargs)

Voilà, les mixins sont implémentés, ce qui est vraiment un line saviour ^^.

Bon, à périmètre constant (i.e sans compter les tests ni les templates), alors que nous avons encore un gros reliquat de l'ancien système les chiffres ne trompent pas :

Et encore, t'as pas fait le coup de get_object()

(sinon, sérieusement, très bonne nouvelle)