Re: Plugin "Archivage de contenus" - feedback utilisation lister_champs_selection_conditionnelle
Eric Lupinacci <[email protected]>
| Newsgroups | gmane.comp.web.spip.devel |
|---|---|
| Message-ID | <CAM6W4bbw_LpCNV=KZTqiYUX7Hu=nuv_jXjfpm6kovm5TSTF=GQ@mail.gmail.com> |
Hello,
Petite remarque sur le plugin Sites.
Contrairement à d'autres objets, la liste des sites possède la boucle
suivante :
<BOUCLE_liste_sites(SYNDIC){id_syndic?}{id_mot?}{id_rubrique?}{where?}{recherche?}{statut?}{syndication?}{tri
#ENV{par,date},#GET{defaut_tri}}{pagination #ENV{nb,10}}>
On voit qu'il y a encore id_mot? alors qu'on pourrait utiliser id_?.
Je suis aussi étonné qu'on ait le critère conditionnel id_syndic? : à quoi
ça peut servir d'avoir une liste d'un seul site ?
Il faudrait pas corriger cela ?
++
Eric
Le ven. 22 nov. 2019 à 13:34, Eric Lupinacci <[email protected]> a écrit :
> Hello,
>
> Bon je relance un peu ce fil qui a clairement fait l'unanimité :p.
>
> Pour le cas 3, afficher tous les objets archivés ou pas, j'ai essayé
> d'utiliser un array dans le ENV pour la variable est_archive en passant
> soit #ARRAY soit #LISTE{0,1} à l'inclusion liste des objets comme il semble
> être possible de le faire mais ça ne fonctionne pas, j'ai une erreur SQL
> sur le IN.
> C'est quand même étrange car le where calculé par la fonction
> critere_id__dist contient bien un test sur le type array et un sql_in
> pour condition.
>
> Donc si quelqu'un a des idées pour le mail précédent je suis toujours
> preneur.
>
> ++
> Eric
>
>
> Le mer. 20 nov. 2019 à 11:08, Eric Lupinacci <[email protected]> a écrit :
>
>> Hello,
>>
>> J'ai finalisé hier une première version du plugin Archivage de contenus
>> qui permet enfin, par défaut, de supprimer des affichages de liste d'objets
>> les objets archivés et, aussi d'afficher les archives uniquement à partir
>> de ces mêmes liste d'objets.
>> Pour cela j'ai utilisé le critère {id_?} et le pipeline
>> lister_champs_selection_conditionnelle.
>> Voilà mon feedback et quelques idées d'évolutions à discuter.
>>
>> *Le fonctionnement recherché pour les listes d'objets :*
>> 1- si aucun critère d'archivage n'est précisé (explicite ou implicite via
>> id_?) je n'affiche pas les objets archivés
>> 2- on doit pouvoir afficher que les objets archivés
>> 3- on doit pouvoir afficher tous les objets archivés ou pas
>>
>> *Le critère {id_?} et l**e pipeline
>> lister_champs_selection_conditionnelle* :
>> En fait, je ne comprends plus le nom maintenant que combiné avec le
>> pipeline lister_champs_selection_conditionnelle il permet d'insérer un
>> champ id_xx mais aussi tout autre champ comme mon champ "est_archive" par
>> exemple.
>> Il serait peut-être utile de le renommer en rappelant cette aspect
>> pipeline comme on le fait dans le code HTML ou PHP et donc renommer aussi
>> le pipeline qui est assez peu utilisé aujourd'hui.
>> Un truc du style {pipeline_where}, le "?" étant inutile et qui rappelle
>> le critère {where} qui est le pendant "statique" du premier (ou
>> "where_statique", "where_immediat" et "where_dynamique", "where_calcule" et
>> le pipeline lister_champs_where_dynamique).
>>
>> Après, lors de la discussion qui a mené à cette implémentation, il avait
>> été proposé d'appeler une fonction de calcul du critère si elle existe : ce
>> n'est pas le cas actuellement et ça serait bien de l'introduire car dans
>> mon cas je suis obligé de capturer a posteriori , via le pipeline
>> post_boucle, le where calculé par le critère id_ pour le modifier étant
>> donné qu'il n'introduit pas la valeur par défaut (tout sauf les archives)
>> si aucune variable "est_archive" n'est définie dans l'environnement.
>>
>> Néanmoins, le code actuel fonctionne malgré ces désagréments pour les
>> points 1 et 2 précités et j'obtiens bien soit le critère compilé
>> {est_archive=0} soit {est_archive=1}.
>> Par contre, pour le 3 il faudrait que je puisse fournir une valeur
>> différente de 0 ou 1 à est_archive dans l'appel de la liste de l'objet et
>> c'est pas hyper propre.
>> Je n'ai pas encore trouver la façon propre et satsfaisante de le faire.
>>
>> Donc voilà pour le feedback, ça serait bien de discuter des propositions
>> précédentes d'évolutions si elles s'avèrent intéressantes ou de me dire si
>> je me suis totalement fourvoyé et qu'il y a plus simple sans évolution.
>>
>>
>> ++
>> Eric
>>
>