Re: [SPIP Zone] SPIP 3.3-beta

Hello,

Pour info, j'ai commité hier la fonction objet_lire() avec les
améliorations proposés par Tcharlss et Rasta.
A diffuser et utiliser maintenant pour avoir un feedback.

Il reste donc le sujet du critère id_?.
Ma proposition est la suivante :
- limiter ce critère aux id_xxx et au traitement automatique fait par le
core sur la recherche des id_xxx possibles.
- ajouter systématiquement id_secteur si on a id_rubrique (règle le sujet
des brèves)
- changer le pipeline en exclure_id_conditionnel et ne lui permettre que de
supprimer des id_xxx détecté mais inutiles (cas de SVP pour id_plugin et
id_paquet).
Je trouve qu'ainsi ce critère est plus cohérent, à voir plus tard le fameux
critère "injectable" dans une boucle.

++
Eric


Le mar. 10 déc. 2019 à 16:33, Eric Lupinacci <[email protected]> a écrit :

> hello,
>
> Le mar. 10 déc. 2019 à 14:08, RastaPopoulos <[email protected]> a
> écrit :
>
>> Le 10/12/2019 à 10:48, cy_altern a écrit :
>> > +1 pour moi aussi: dans la majorité des cas de toute façon le champ
>> > id_XYZ est construit à partir du nom de l'objet
>>
>> Vu qu'en fait mis à part objet et id_objet, tout est facultatif, mais en
>> plus assez rare, et que je ne vois pas trop d'ordre logique genre "si on
>> remplit celui là, faut forcément remplir le précédent avant", est-ce qu'on
>> pourrait pas juste avoir un tableau d'options dès le départ ?
>>
>> $objet, $id_objet, $options=array()
>>
>
> Oui c'est pas mal aussi.
> J'avais déjà pris en compte la remarque de tcharlss mais je peux passer
> les arguments en $options ça sera plus perenne.
> Donc l'argument $champ_id devient $options['champ_id'] et idem pour
> l'argument $informations.
> Par contre on ne peux plus passer une seule information sous forme de
> chaine mais c'est pas grave.
>
> Je commite une première version ce soir.
>
> ++
> Eric
>
>