Cohérence de placement des behaviors d'action

[JcDenis]

Suivre les modifications faites sur les posts est un vrai défi. Il y a des behaviors dans la classe Blog ou non, dans la classe Action ou pas, certains sont redondants, d'autres manquants, il y en a coté public (entrée programmée) et coté admin, certains plugins modifient les posts sans ajouter les behaviors associés...

Il faudrait:

• Soit à minima faire une relecture est ajouter les manquants et trier les redondants,
• Soit remonter tous ces behaviors dans dcBlog (dans la mesure du possible)
• Soit harmoniser leurs placements et pour aller plus loin refaire un behavior plus générique (mais lourd) du style:

$core->callBehavior('corePostsChange','update',$core,array($args));

[franck]

Suis d'ac, mais il va falloir passer par une phase de "deprecated" pour ceux qu'on souhaitera supprimer, au moins pendant quelques releases. Il y a quelques plugins qui s'appuient dessus :-)

T'as des noms pour les plougs qui sabotent le job ?

Ou alors se pencher sur le dev d'une API REST complète, mais ça va demander du taf et pas grand chose d'autre ne pas avancer pendant ce temps. (je rêve tout haut)

[franck]

J'ajouterai que jusqu'à maintenant on a surtout suivi le principe YAGNI ( https://fr.wikipedia.org/wiki/YAGNI) pour implémenter les behaviours, ça explique surement les défauts…

[JcDenis]

Replying to franck:

J'ajouterai que jusqu'à maintenant on a surtout suivi le principe YAGNI ( https://fr.wikipedia.org/wiki/YAGNI) pour implémenter les behaviours, ça explique surement les défauts…

J'aime bien ce principe, quoi que j'aime bien aussi voir un peu plus loin que le bout de mon code.

Pour ce qui est d'implémenter une API, on est d'accord, on oublie, pas assez de bras pour ça.

Pour des noms de plugins, les premiers dont je me souviens sont periodical, Activity Report et Expired Entries pour ne citer que ceux la qui m'avaient donné la migraine à l'époque, il y en a quelques uns quand même qui scrutent certaines action sur les posts, donc oui, a ne pas prendre à la légère.

Je bosse actuellement sur le possible futur plugin Webmention (voir #1917 ) et pour bien faire, aillant besoin de connaitre le changement de status d'un billet, je me suis rendu compte que c'était impossible, réellement impossible, car il manque des behaviors (et je suis en partie responsable sur de récents commit...) d’où mon interrogation plus générale sur les Behaviors. (Pour Webmention je ferais autrement/sans)

Je crois me souvenir que certains behaviors n'avaient pas été mis directement dans le core pour des raisons de sécurités ou de conflits mais sans plus... Et une nouvelle série de behavior n’empêche pas de garder les anciens en deprecated.

A mes yeux, le système de behaviors est une partie importante et géniale de Dotclear, c'est dommage qu'on soit si bordélique là dessus. Bref je ne sais pas quoi penser, faire...

[franck]

Suis d'accord, les behaviours sont à garder, c'est le meilleur moyen de conserver un "core" mini et efficace.

Sinon, certains behaviours sont potentiellement fouteurs de merde, si on fait pas gaffe avec :-)

Question webmention, ça ressemble assez aux pingbacks (qui sont déjà dans le core), à part, il me semble, que ça discute en JSON au lieu du XML (de mémoire). Quoi qu'il en soit ça ne devrait pas être très compliqué d'intégrer ça une fois le plugin éprouvé.

[JcDenis]

On va parler de Webmention sur l'autre ticket ;)
Mais pour répondre rapidement, j'avoue que j'avais du mal à appréhender le concept et étais partie un peu loin, mais finalement en lisant la recommandation W3C, certaines parties sont plus simples (exemple on peut faire une requête à chaque modif de la page, contrairement à ce que j'avais lu ailleurs). Toujours est-il qu'il y a beaucoup d'échange HTTP entre les deux partis avec du parse content un peu partout, c'est lourd... Et je le laisserais en plugin (inclue à la distribution si ça vaut le coup peu importe). Je vais ouvrir un billet sur le forum, ça permettra d'en discuter. Mais j'avance un peu avant.

[franck]

À faire au fur et à mesure, si besoin…