Feature/extracompanyname

[manuelh78]

Slt,

Pour répondre à cette demande :
https://bugs.galette.eu/issues/1807

A priori, ça fonctionne correctement. J'ai testé avec les tradutions.

Par ailleurs, j'ai refactorisé le code :
ajouté une classe RepositoryTrait qui s'occupe de toutes les méthodes de base getList(), getAll(), load(), installInit(), update()...
ajouté une classe de base Entity qui s'occupe de la connexion avec pg/mysql, elle gère les getters(), setters(), les propriétés virtuelles, les traductions automatiquement

Ainsi, dépôts et entités Title(s), PaymentsStatus, LegalStatus partagent le même code.
les classes Titles, PaymentsStatus et LegalStatus seront quasi vide.

En général, en programmation orienté objet, dès que tu as deux classes qui se ressemblent à 90% en termes de code et de méthodes, c'est que tu peux probablement faire autrement.

Je ne suis pas sûr d'être très disponible dans les 15 jours qui viennent, je mets le code ici, mais j'y reviendrais.
Manu

[trasher]

Cela fait trop de changements ; ce ne sera pas pour la 1.1.

La factorisation, j'ai déjà travaillé un peu dessus, mais il restait beaucoup de cas spécifiques (j'avais commencé par les adhérents et les contributions).
Je ne sais pas trop ce que les tests couvrent de tout ça actuellement (et je ne peux pas lancer le CI sur cette PR, je ne sais pas trop pourquoi).

À suivre :)

[trasher]

À bien y réfléchir, la factorisation ; je ne suis pas pour. C'est pour moi prématuré, et si un tel chantier devait être mené, ce serait de manière bien plus globale. Il aurait été préférable d'aborder avant ce sujet via un ticket d'évolution dédié.

De plus, cela représente beaucoup trop de travail pour moi à relire, corriger, puis maintenir.

Certes, répéter le code n'est pas très OOP ; mais pour le moment ce sera suffisant - surtout pour une fonctionnalité mineure.

[manuelh78]

Slt,

Quand je lance les tests un par un dans l'EDI, certains ne passent pas, car la base contient des données d'un test précédent.
Par exemple, le test qui ajoute et supprime les types de paiements ne passe pas, car la table contributions contient des références sur des types de paiement. Si je vide la table contribution, c'est bon :)

L'ordre des tests semble important ?

Du coup, peux-tu me dire précisément comment tu passes les tests ?

Sinon, tous les tests Repository / Entity sont OK.

Tu pourrais gagner un temps significatif en utilisant une approche objet sur les classes Repository/Entity.
Moins de code = moins de bugs:)
Revoir le code dans sa totalité, me paraît pas judicieux. Tu vas y passer un temps fou. A mon avis, le mieux, c'est de le faire au fur et à mesure.
Par clarté, il faudrait que les noms des propriétés soient exactement les mêmes que les noms des colonnes SQL.

Manu

[trasher]

Slt,

Quand je lance les tests un par un dans l'EDI, certains ne passent pas, car la base contient des données d'un test précédent. Par exemple, le test qui ajoute et supprime les types de paiements ne passe pas, car la table contributions contient des références sur des types de paiement. Si je vide la table contribution, c'est bon :)

L'ordre des tests semble important ?

Non, pas spécialement. En revanche, chaque classe de tests est responsable de nettoyer les données qu'elle a ajoutées (généralement dans la méthode tearDown()).

Tu pourrais gagner un temps significatif en utilisant une approche objet sur les classes Repository/Entity. Moins de code = moins de bugs:) Revoir le code dans sa totalité, me paraît pas judicieux. Tu vas y passer un temps fou. A mon avis, le mieux, c'est de le faire au fur et à mesure. Par clarté, il faudrait que les noms des propriétés soient exactement les mêmes que les noms des colonnes SQL.

Oui, oui.

Quels que soient les "avantages", il y a aussi beaucoup d'inconvénients. Et comme je l'ai déjà dit il reste à mes yeux énormément de travail avant qu'une telle modification soit envisageable sereinement ; et sur la totalité des objets.

Bref, je n'accepterai pas les modifications de factorisation - navré.