Bonjour, je me permet de répondre à ce message pour y apporter quelques compléments.
[*]À chacune de nos mises à jour du framework, la compatibilité ascendante a été brisée
L'une des nouveautés de Copix version 3 (pour PHP5) est justement d'assurer cette compatibilité ascendante. C'est aujourd'hui une volonté forte de l'équipe de développement (pour ne pas reproduire les erreurs de la version 2).
[*]Pas de tests unitaires (donc pas possible de vérifier cette compatibilité ascendante avant de faire l'upgrade)
Il existe des tests unitaires dans Copix, il utilise PHPUnit comme framework de test. Un module (copixtest) permet de plus de lancer les tests de façon intégrée a l'application.
[*]Beaucoup de petites choses mal pensées voire frôlant l'amateurisme, j'en prends une au hasard parce qu'elle me vient en tête : pour savoir dans quelle module ou actiongroup on se trouve (dans une zone ça peut être très utile par exemple) il faut lire _request('module') ou _request('groupe'). Implication immédiate, si tu veux passer un champ de formulaire nommé "module", il vaut mieux t'abstenir
La, c'est très subjectif.... entre mal pensé / mal comprises / choix de conception, la frontière est souvent minime.
Il existe en effet trois paramètres réservés pour diriger un internaute vers une action (module, group et action). Maintenant, je crois qu'il n'existe pas d'autre solution magique afin de permettre cette manipulation sans demander au développeur ou à l'administrateur système d'ouvrir les .htaccess ou autres configurations serveur.
Le choix de Copix est de proposer 3 paramètres figés pour toute l'application, c'est historique et cela n'a jamais posé de problème en 7 ans d'utilisation.
[*]La doc est très incomplète,
C'est vrai, la documentation est toujours en cours de rédaction, mais elle se complète de jour en jour. Pour les problèmes concrets, il existe un forum (
http://forum.copix.org) ou les développeurs répondent aux questions en quelques heures tout au plus.
et l'API... Parfois on a l'impression qu'ils ont fait de l'objet histoire de dire que c'est POO, mais le nombre de classes avec seulement une ou deux méthodes est hallucinant
Oula, ça je ne peux le laisser passer
Rien n'est fait "histoire de" faire de la POO. Copix est développé et utilise dans sa conception tout un tas de Design Patterns (Factory pour les classes, Singleton pour la config, Builder pour les DAO, bien évidemment MVC, Proxy pour les classes de session, Oserver pour les évènements, ...)
et pour les droits que tu cites ici :
(rien que pour brancher le système d'identification sur une classe perso, ou surcharger le système de vérification des credentials, rien n'est prévu ou alors très limité, c'est décourageant
).
Le système de droit fonctionne sur un principe de chaine de responsabilité. Il t'es ainsi possible de remplacer tout ou partie du système d'authentification, de rajouter des systèmes de droits, des systèmes de groupe, ...
J'avoue toutefois que cette partie n'est pas encore complètement documentée, d'ou la probable incompréhension.
J'insiste sur le fait qu'il ne faut pas hésiter à utiliser le forum en cas de problèmes d'utilisation, les développeurs répondent très rapidement !
Merci en tout cas pour le retour d'expérience, cela donne des pistes d'amélioration !!
Un bon maître a ce souci constant : enseigner à se passer de lui.
