oui, et de toutes façons il y a plus urgent à mon sens: mettre dans
un script actions la trentaine de UPDATE/REPLACE qui traine dans les
scripts de exec, afin d'etre enfin conforme au modèle REST.
C'est un peu ce que je suis en train de faire, avec l'API d'édition.
Ma chi va piano va sano. Je ne suis pas encore tout à fait content de l'API
pour les articles ; celles pour les brèves, rubriques et auteurs sont des
déclinaisons, et documents et forums ne sont pas faits du tout. Et ensuite
je voudrais unifier toutes ces fonctions.
Au passage, deux trucs que tu as fait récemment se révèlent un peu gênants :
- pour les auteurs, la création de l'enregistrement dans spip_auteurs ne se
fait pas au même moment que pour les autres tables () savoir quand on
renvoie les données du formulaire) ; qu'est-ce qui nécessitait ça, et ne
peut-on faire autrement ? (Pour associer les documents à un article
inexistant j'ai fait un gros hack plutôt que de changer cette logique de
base)
- pour les articles qu'un admin restreint déplace dans une rubrique qui ne
lui appartient pas, il y a tout un mic-mac pour les remettre en mode
"proposé".
Le code est légèrement dérogatoire, mais surtout ça fait une interface
assez peu intuitive.
A mon sens ce qu'il faudrait, c'est 1) *ne pas proposer* les rubriques
interdites dans le formulaire de changement de rubrique ;
2) *refuser* les déplacements dans une rubrique interdite.
Du coup pour déplacer un article vers une rubrique qu'on n'administre pas,
il faudrait explicitement faire la démarche de dépublier, puis déplacer.
- pour les auteurs, la création de l'enregistrement dans spip_auteurs ne se
fait pas au même moment que pour les autres tables () savoir quand on
renvoie les données du formulaire) ; qu'est-ce qui nécessitait ça, et ne
peut-on faire autrement ? (Pour associer les documents à un article
inexistant j'ai fait un gros hack plutôt que de changer cette logique de
base)
Le bouton "créer un auteur et l'ajouter à cet article" appelle ce script en lui demandant d'associer l'auteur à créer à l'article puis de revenir. Comme ce script contient de l'ajax, autrement dit permet de faire mille et une opérations avant de revenir, ça fait un nombre d'information à mémoriser ingérable et contre-intuitif pour le programmeur. De plus, je ne vois pas ce qu'il y a de dérogatoire là-dedans: on crée un auteur, on le modifie ensuite où est le pb ? Ajoute à cet appel l'inscription libre des rédacteurs et des visiteurs et la création ex-niholo, ça fait beaucoup de cas. Ce code est sans doute perfectible, mais il est très contraint, il y a intérêt à regarder tous les appels et scénario potentiels avant de changer quoi que ce soit.
- pour les articles qu'un admin restreint déplace dans une rubrique qui ne
lui appartient pas, il y a tout un mic-mac pour les remettre en mode
"proposé".
Le code est légèrement dérogatoire, mais surtout ça fait une interface
assez peu intuitive.
A mon sens ce qu'il faudrait, c'est 1) *ne pas proposer* les rubriques
interdites dans le formulaire de changement de rubrique ;
2) *refuser* les déplacements dans une rubrique interdite.
Du coup pour déplacer un article vers une rubrique qu'on n'administre pas,
il faudrait explicitement faire la démarche de dépublier, puis déplacer.
Par principe quand on veut faire une chose, l'ergonomie doit permettre de la faire en une seule action. Ici ça répond au scénario d'un admin voulant déléguer un article à une autre admin gérant une rubrique plus appropriée. Ton point 2 obligerait à une démarche en 2 temps qui serait une perte d'ergonomie dont je ne vois pas la contre-partie. En ce qui concerne le point 1, la bonne réponse à mon avis est de différencier graphiquement les 2 types de rubriques, afin que cette possibilité de délégation reste disponible mais soit, c'est ce qui manque en effet, netemment perceptible au moment de l'action.
Le bouton "créer un auteur et l'ajouter à cet article" appelle ce
script en lui demandant d'associer l'auteur à créer à l'article puis
de revenir. Comme ce script contient de l'ajax, autrement dit permet
de faire mille et une opérations avant de revenir, ça fait un nombre
d'information à mémoriser ingérable et contre-intuitif pour le
programmeur. De plus, je ne vois pas ce qu'il y a de dérogatoire là-
dedans: on crée un auteur, on le modifie ensuite où est le pb ?
Ajoute à cet appel l'inscription libre des rédacteurs et des
visiteurs et la création ex-niholo, ça fait beaucoup de cas. Ce code
est sans doute perfectible, mais il est très contraint,
C'est dérogatoire, au sens où l'enregistrement est créé quand tu cliques
"créer un auteur", et non pas quand tu envoies son nom. On pourrait sans
doute limiter cette dérogation au(x) seul(s) cas nécessaire(s) : créer +
ajouter, selon ce que tu dis (je pensais que c'était à cause de l'ajax dans
l'affectation des rubriques d'admin restreint...)
il y a intérêt à regarder tous les appels et scénario potentiels avant de
changer quoi que ce soit.
C'est sûr !
Par principe quand on veut faire une chose, l'ergonomie doit
permettre de la faire en une seule action.
Moui... ici, de fait, on veut faire deux choses : repasser l'article en
proposition (1) et auprès d'un autre admin (2). Moi quand je déplace un
article, je ne m'attends pas à ce qu'il soit dépublié, mais simplement
déplacé. Si je n'ai pas le droit de le déplacer il faut me le dire, pas
dépublier l'article...
mon avis est de différencier graphiquement les 2 types de rubriques, afin
que cette possibilité de délégation reste disponible mais soit, c'est ce
qui manque en effet, netemment perceptible au moment de l'action.
Ce serait déjà mieux, mais sur le fond nos avis divergent. Cela dit c'est
pas très grave, mon point concernait plutôt l'API d'édition, qui se retrouve
à gérer des autorisations, alors qu'en théorie ce n'est pas son rôle, mais
celui de fonctions en amont.