http://www.spip.net/ecrire/?exec=articles&id_article=4009#forum174333
denisb dit:
> ** #ARRAY
>
> * |in_any si ma liste de valeurs $vals n'est pas un tableau je
> retourne la valeur par défaut $def et les parties conditionnelles de
> ma balise seront prises en compte si ma valeur $val est dans le
> tableau $vals je retourne un espace donc le test est positif et les
> parties conditionnelles de ma balise seront prises en compte sinon je
> ne retourne rien et les parties conditionnelles de ma balise ne
> seront pas prises en compte
Y'a quand même un truc que je ne m'explique pas.
Je n'arrive pas à me représenter un cas de figure où ceci trouve une application. Soit la valeur est dans le tableau, ok ça affiche les parties conditionnelles (même chose que |find|oui en fait). Soit le tableau n'existe pas, donc la valeur ne peut pas être dedans, et ça affiche aussi les parties conditionnelles. Quel intérêt???
Dès que l'on utilise in_any avec une valeur par défaut $def, sa seule utilité devient de démontrer
soit que $vals n'est pas un tableau,
soit que $vals ne contient pas $val
mais en aucun cas que $val est dans le tableau!
Enfin, dis-moi si je me trompe.
> >find si ma valeur $val est dans $array et que celui-ci est bien un
> tableau je retourne true (1) et les parties conditionnelles de ma
> balise seront prises en compte sinon (ma $val n'est pas dans le
> tableau ou $array n'est pas un tableau) je retourne false (rien) et
> les parties conditionnelles de ma balise ne seront pas prises en
> compte.
>
> les différences ?
>
> >in_any offre la possibillité de retourner une valeur par défaut.
En définitive, find et in_any sont complètement équivalents dès lors que la variable est un tableau, sauf que find a une syntaxe plus jolie puisqu'il prend le tableau en premier paramètre et que in_any a un résultat plus joli puisqu'il retourne ' ' au lieu de 1 (find demande l'ajout de |oui pour obtenir le même résultat).
[(#GET{mon_tableau}|find{une_valeur}|oui)]
[(#VAL{une_valeur}|in_any{#GET{mon_tableau}})]
Une fois que la variable n'est pas un tableau, in_any offre le must de pouvoir préciser une chaîne à retourner, sauf qu'alors, il ne fait plus le boulot qu'on lui demande, à savoir: nous dire si la valeur est dans le tableau.
Ou bien?
Sauf avis contraire, la solution serait de documenter find et éventuellement is_array pour le surplus, et de jeter in_any aux oubliettes de l'histoire...
Aurélie
PS. pour info, in_any arrive ici: http://trac.rezo.net/trac/spip/changeset/5713/spip/ecrire/inc_filtres.php
(Je ne citerai personne ;-))
>> [(#VAL{abc}|in_any{#GET{tablo}, truc à faire si GET_tablo n'est pas un
>> array}|?{truc à faire si abc est une valeur de GET_tablo, truc à
>> faire si abc n'est pas une valeur de GET_tablo})]
>>
>> D’après mes tests,
>> [(#VAL{abc}|in_any{#GET{tablo},"tablo n'est pas un tableau mais on
>> s'en fout parce que ce message ne s'affichera jamais :-)"}|?{
>> "tablo est un tableau et abc est dedans
>> OU tablo est une variable égale à abc
>> OU tablo n'existe pas OU tablo est vide
>> OU tablo n'est pas un tableau :-)",
>> "tablo est un tableau mais abc n'est pas dedans"})]
[...]
>> Dès qu'on utilise le deuxième paramètre de in_any, sensée être la
>> valeur par défaut si tablo n'est pas un tableau, les filtres |oui,
>> >non, |sinon et |?{} commencent à produire des comportements
>> incompréhensibles.
[...]
