ZEP-02 : Elaboration d'une API

Est-ce qu'on pourrait faire un sujet pour parler de cette refacto ? Car j'ai vu passer deux trois trucs a ce sujet mais rien de complet/detaille/clair

firm1 : C'est tout à fait un prérequis mais qui ne peut pas évoluer dans une branche à part au vu des changements que cela demande dans le code. C'est quelque chose qui doit être fait en amont sur tous les modules, par itération et qui doit être merge régulièrement dans la branche principale sinon j'ose pas imaginer la gueule des conflits.

Eskimon : En gros, il faut pouvoir retirer toute la logique métier des views. Deux gros avantages : les views ne feront plus 3 000 lignes et il n'y aura pas de répétition de code entre les views et l'API. La solution trouvée pour l'instant c'est de passer par des adapteurs (pas un concept django mais bonne pratique) et des managers (si nécessaire puisque ceci ne refactor pas les views mais les models).

Si tel est le cas, ça demande une ZEP en elle-même, puisqu'il s'agit d'un gros refactoring de code. Il n'y a pas matière à discution sur celle-ci, pas à mon sens, mais ça permet de "formaliser" la chose.

Pour moi, une ZEP c'est une nouvelle fonctionnalité qui évolue en parallèle du projet pendant un certain temps (au vue de la définition que m'a donné firm1 un plus plus tôt dans ce sujet). Je ne pense donc pas que cela doit faire l'objet d'une ZEP mais plutôt d'une tendance dans les contributeurs actifs du projet qui doivent soit y aller à coup de grosses PR par module, soit y aller progressivement. La dernière solution retardant sérieusement le développement de l'API.

Le module membre etant celui le moins sujet a mouvement et qui sera atteint par la ZEP-17, est-il envisageable de faire un POC dessus pour cette refacto ou on doit tout refactoriser en meme temps ?

Pour moi, une ZEP c'est une nouvelle fonctionnalité qui évolue en parallèle du projet pendant un certain temps (au vue de la définition que m'a donné firm1 un plus plus tôt dans ce sujet). Je ne pense donc pas que cela doit faire l'objet d'une ZEP mais plutôt d'une tendance dans les contributeurs actifs du projet qui doivent soit y aller à coup de grosses PR par module, soit y aller progressivement. La dernière solution retardant sérieusement le développement de l'API.

Pas tout à fait d'accord, parce que sinon la ZEP-12 (en gros, refactoring du module des tutos) n'aurait pas pu voir le jour. Mais je laisse Firm1 donner son avis

Eskimon : C'est ce que j'avais commencé à faire mais je n'ai pas de temps pour l'instant. Limite, je peux faire une PR WIP dans les jours à venir avec ce que j'avais commencé à faire pour que vous puissiez contribuer dessus. Sachant que je n'avais pas été loin dans le refactoring.

pierre_24 : Dans la cartouche de votre ZEP, je vois "Feature". Si c'est en fait un recactoring, je vous souhaite bien du courage pour son développement. Personnellement, je n'ai aucune envie de m'amuser avec des conflits monstrueux à chacune de mes contributions au projet.

Dans la cartouche de votre ZEP, je vois "Feature"

la ZEP 12 est tellement ambitieuse qu'elle apporte des features énormes ne serait-ce que par la philosophie même de son organisation. Par exemple après la ZEP 12 tu auras des "moyens tutos".

Le seul vrai problème, c'est que pour faire ça, nous avons besoin d'un refactoring complet et donc en effet on pousse très loin la logique.

Ce n'est pas le sujet mais si je comprends bien, votre refactoring se situe plutôt sur les classes du modèle, sur leurs utilisations et dans la gestion des fichiers git correspondants. C'est du gros boulot mais le refactoring dont je parle ici, c'est un refactoring qui se situe dans les views. Déjà que vos conflits doivent être costauds avec votre refactoring (vous avez bien du courage …), imaginez un refactoring où tout le contenu des views est absent maintenant. La finalité m'enchante, la réalisation beaucoup moins.

Ça ne m'enchante pas trop non plus (car comme on a tout changé, en fait les vues aussi souffrent…) mais c'est clair que nos deux ZEP sont des ZEP à haute volatilité du code et donc forcément c'est pas motivant.

Pourquoi ne pas utiliser les ClassBasedView de Django pour faire ça ? Et router sous la forme

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

urlpattern += (
    url(^membres/<id>/,
             MemberListView.as_view(),
             name="member_list"
        ),
    url(^api/<version>/membres/<id>/,
             MemberListView.api_view(),
             name="member_list_api"
        ),
)

En ayant un fichier utils.view qui ressemble à :

1
2
3
4
5
6
7
8
9

class APIMixin:
    def api_view(self):
        return la_fonction_qui_va_bien

class ListView(APIMixin, django.view.ListView):
    pass

class DetailView(APIMixin, django.view.DetailView):
    pass

Luthaf : A terme, c'est tout à fait ça la solution envisagée mais le code actuel du projet ne le permet pas du tout.

Ok, mais quitte a faire du refactoring, pourquoi ne pas aller directement vers la solution définitive ?

C'est ce qui est prévu mais, pour résumer, ça demande tellement de travail qu'il n'y a personne d'assez motivé pour le faire actuellement.

Ce qui m'embête un peu c'est qu'on se décourage avant même d'avoir commencé. Alors que le seul fait de commencer est déjà une avancée. C'est ce que j'appelle penser "communautaire".

Par exemple Andr0, tu parle d'être capable de faire un WIP, j'ai envie de dire "fonce", et si la branche est sur le dépot, ça permet a d'autres de pouvoir avancer au fur à mesure sur la tâche. C'est clair que si tu te mets dans l'idée de faire toute la ZEP toi même, tu va finir par perdre courage en chemin.

Je te propose de créer une branche sur le dépôt, et d'y pousser un WIP (ou une base de la refacto) et de voir comment les choses évoluent là dessus. Tu en penses quoi ?

firm1 : Nous sommes de plus en plus du même avis et ça m'inquiète.

(Surtout que le truc cool c'est que le module member est un des plus simples a tester a la main du coup c'est moins "stressant" pour la refacto (vu que ses vues sont pas couvertes a 100% par les TU (en revanche son modele l'est quasiment))

Moi aussi, mais bon, je considère que je passe par une mauvaise étape de ma vie

Pour information, la PR est faite.

En termes d'implémentation, Tastypie semblerai permettre la mise en place d'une API ReST sans toucher au reste (^^) du code du site.

Y-a-t-il tellement de traitement spécifique dans les vues que cela vaille le coup de réutiliser le code, et de ne pas passer par une implémentation séparée ?

Pour information, le développement de la ZEP-17 a commencé.