Filtre puce_statut et argument menu_rapide

Dev
1

Hello,

Le filtre puce_statut() possède le prototype suivant:

filtre_puce_statut_dist($statut, $objet, $id_objet = 0, $id_parent = 0)

Ce filtre appelle une fonction interne inc/puce_statut qui a elle, le prototype suivant:

inc_puce_statut_dist(
	$id_objet,
	$statut,
	$id_parent,
	$type,
	$ajax = false,
	$menu_rapide = _ACTIVER_PUCE_RAPIDE
)

On note dans ce deuxième prototype une option très intéressante permettant de faire en sorte que la puce soit un menu d’institution ou soit juste un affichage.
Et cette possibilité « affichage uniquement » est utile parfois si on préfère instituer via un bouton d’action avec un libellé qui représente l’action du workflow et pas le statut cible (on ne peut pas mettre l’autorisation à false dans ce cas).

Étant donné que cette option existe je propose qu’on l’introduise dans le filtre comme paramètre optionnel en fin de prototype sous la forme d’une chaine de valeur ‹  › par défaut pour préserver le fonctionnement actuel et qui pourrait être mise à ‹ oui › ou ‹ non › pour écraser le traitement interne basé sur une constante.
Cette modification si ok intègrerait la 4.0.

Vos avis ?

2

Proposition pour le filtre modifié:

function filtre_puce_statut_dist($statut, $objet, $id_objet = 0, $id_parent = 0, $forcer_affichage = false) {
	static $puce_statut = null;
	if (!$puce_statut) {
		$puce_statut = charger_fonction('puce_statut', 'inc');
	}

	$menu_rapide = $forcer_affichage
		? false
		: (objet_info($objet, 'editable') ? _ACTIVER_PUCE_RAPIDE : false);

	return $puce_statut($id_objet, $statut, $id_parent, $objet, false, $menu_rapide);
}
3

Je te propose alors de mettre à null pas défaut (= on prendra la la constante), sinon true ou false.

Je dis ça car je pense que mettre des « oui » et « non » ou " " sur pour les filtres n’est pas la meilleure idée à mon sens de nos jours où PHP peut tester le type attendu à ta place. Qui plus est ça sert aussi à la compréhension / doc en passant (sans avoir besoin d’écrire de PHP doc parfois même, en tout cas pas pour détailler le type de paramètres). PHP8 améliore encore plus ça de différentes manières (mais on y est pas encore totalement dans SPIP 4), en permettant d’expliciter des union type : c’est à dire des choses comme int | string $truc

Ici, pour ta fonction en SPIP 4 — php 7.3+, ça donnerait un paramètre tel que :

filtre_puce_statut_dist($statut, $objet, $id_objet = 0, $id_parent = 0, ?bool $menu_rapide = null)

La contrainte après est de savoir passer « true » ou « false » ou « null » (bon là c’est par défaut si tu mets pas d’arguments). On a #NULL déjà. Mais peut être on pourrait ajouter #TRUE et #FALSE pour clarifier également.

Sinon, tant qu’on n’est pas en PHP dit « strict », PHP castera autant qu’il peut ("oui" = true… 1 = true… " " = true ; 0 = false, "" = false, ...)

4

Ok, oui je vois.

J’ai aussi proposé avant ta réponse une solution simplifiée où le paramètre ne fait que forcer l’affichage sans menu ou laisse le calcul habituel sinon, ce qui me semble en fait suffisant.
On peut choisir l’un ou l’autre des fonctionnements, je ne sais pas ce que tu en penses.

Par contre, oui, le true et false dans les squelettes est toujours une plaie, sauf à utiliser #EVAL{true}.
Un #TRUE ou #FALSE serait pas mal de toute façon oui.

5

Une proposition

filtre_puce_statut_dist($statut, $objet, $id_objet = 0, $id_parent = 0, ?bool $editable = null) {
    if ($editable === null) {
       $editable = (bool) _ACTIVER_PUCE_RAPIDE;
   }
   // si éditable… tester l'autorisation d'éditer...
   $menu_rapide = $editable ? objet_info($objet, 'editable') : false;
   ...
}
6

Bon après relecture de la fonction il est déjà possible d’avoir une puce passive si on ne fournit pas l’id de l’objet.

On peut clore le fil donc, sans rien faire.
Désolé pour le bruit…