mais après coup je m'interroge : tant en spip 2.0 qu'en spip 2.1,
cette association 'par multiple' + 'inverse' donne le résultat dénoncé
par le ticket.
2 cas de figure donc :
- soit on considère que {par truc, chose}{inverse} ne doit appliquer
{inverse} *que* sur 'truc' et que si on veut {inverse} sur 'truc'
*et* sur 'chose' il faut écrire {!par truc, chose} ;
- soit on considère que les 2 écritures sont équivalentes (ce que
permet donc mon commit) *mais* du coup on ne peut plus jamais avoir
order by truc DESC, chose ASC
de plus, ce commit risque (à l'évidence) de casser des squelettes...
Une petite suggestion… pourquoi ne pas implémenter une écriture du genre {par champ1, !champ2, champ3}?
C'est juste une idée mais je ne vois peut-être pas toutes les implications qui ferait qu'elle soit bonne ou mauvaise…
Attention, je crois que ton commit casse {par titre}{par id_article}{inverse} en appliquant inverse sur les deux par et non uniquement sur le dernier
De fait, le inverse ne s'applique qu'au par qui le précède, ce qui est ambigu en cas de multiple critère fourni dans un seul par. Dans ce ças le {!par} est clairement a préférer.
Le {inverse} pourrait être déprécie si il n'était utile dans sa version dynamique
{inverse #ENV{truc}}
qui pratique un inverse conditionnel selon si truc est vrai ou faux.
Et quand on tient a utiliser inverse, on peut toujours éclater l'écriture en par multiples au lieu de lister tous les criteres dans un seul par. Donc sauf si on sait corriger le cas cité plus haut cassé, je pense que le statut quo est de mise (inverse n'inverse que le dernier critère du dernier par qui le précède)
Attention, je crois que ton commit casse {par titre}{par id_article}{inverse} en appliquant inverse sur les deux par et non uniquement sur le dernier
oui. effectivement.
De fait, le inverse ne s'applique qu'au par qui le précède, ce qui est ambigu en cas de multiple critère fourni dans un seul par. Dans ce ças le {!par} est clairement a préférer.
voilà : d'où ma question. il faut lever l'ambiguité par une bonne doc.
Le {inverse} pourrait être déprécie si il n'était utile dans sa version dynamique
{inverse #ENV{truc}}qui pratique un inverse conditionnel selon si truc est vrai ou faux.
gardons-le donc tel qu'il est.
Et quand on tient a utiliser inverse, on peut toujours éclater l'écriture en par multiples au lieu de lister tous les criteres dans un seul par.
absolument.
Donc sauf si on sait corriger le cas cité plus haut cassé, je pense que le statut quo est de mise (inverse n'inverse que le dernier critère du dernier par qui le précède)
je revert le commit et renforce la doc de {inverse} et de {par ...}