Produits Entr'ouvert » w.c.s.

Oui filter_by c'est pour les données; comme on a |filter_by_user ou |filter_by_status, on pourrait avoir un nouveau filtre dédié mais quel serait l'objectif réel ? question parce que si ce qui est souhaité est obtenir une demande particulière, je serais plutôt pour permettre form_objects|get:... plutôt qu'à passer par une liste terminée par |first pour obtenir l'élément concerné.

Frédéric Péters a écrit :

Oui filter_by c'est pour les données;

ok, merci, je m'en doutais.

question parce que si ce qui est souhaité est obtenir une demande particulière,

Oui

je serais plutôt pour permettre form_objects|get:... plutôt qu'à passer par une liste terminée par |first pour obtenir l'élément concerné.

je ne comprends pas ce que tu dis.

Ma question sur l'objectif c'est que je vois une utilité à pouvoir récupérer une demande/fiche par son identifiant, pour faire quelque chose du genre :

{% with demande=form_objects|TODO %}
  La demande a le numéro {{demande|get:"form_number"}}
{% endwith %}

Avec pour expliciter les deux options sur l'idée de requête filtrée, on ferait :

{% with demande=form_objects|filter_by_number:"12"|first %}

et sur l'idée du |get, on ferait :

{% with demande=form_objects|get:"12" %}

Dans ce contexte je trouve plus de sens à avoir la forme en |get.

Le cas d'usage est de demander dans une démarche à l'usager le numéro d'une autre démarche qu'il a faite pour s'y référer (cette autre démarche doit exister pour pouvoir faire la nouvelle démarche).

Frédéric Péters a écrit :

Oui filter_by c'est pour les données; comme on a |filter_by_user ou |filter_by_status, on pourrait avoir un nouveau filtre dédié mais quel serait l'objectif réel ? question parce que si ce qui est souhaité est obtenir une demande particulière, je serais plutôt pour permettre form_objects|get:... plutôt qu'à passer par une liste terminée par |first pour obtenir l'élément concerné.

Évidemment ce que tu proposes sans passer par |first est plus simple mais ça m'ennuie un peu de ne pas utiliser la logique filter_by* qui est maintenant connue par les CPF et quelques clients.

Ca va être des discussions sans fin mais j'aimerai qu'on tente de rester un peu dans des rails : les form_number qu'on connait ont la forme "xx-yy". Et ça va pas marcher là, on cherche en faire le number_raw ou le internal_id.

Je concois que filter_by_form_number_raw ou filter_by_internal_id c'est un peu longuet, mais c'est tout de même ainsi que ça devrait être écrit.

(Mais passons, je sais que je vais pas gagner, les gens aiment le perl et le php "je vais tenter cette syntaxe, ça finira bien par marcher"... tant pis pour notre cellule support)

En tout cas je ne suis pas d'accord avec le sucre filter_by:"form_number" : ça devrait être filter_by:"number". Pas chaud non plus pour accepter filter_by:"form_user" ou filter_by:"form_status". En effet filter_by c'est un filtrage selon les identifiants des champs, donc sans le prefixe "form" ou "form_var". (mais on peut aussi imaginer un plan où on finirait, lassés, par accepter filter_by:form_var_foo et filter_by:var_foo, et je pourrais tout à faire être d'accord avec ça)

Pour éviter de désigner par form_number ce qui est un internal_id, on peut pas juste rester sur le truc évoqué au départ filter_by_number ? Correctement documenté en expliquant que c'est le internal_id qui est concerné.

Concernant la possibilité d'utiliser une autre syntaxe filter_by:"form_status" ou filter_by:"status" , j'y vois toujours plutôt une source de confusion qu'une opportunité mais c'est mon côté nazi. Je ne documenterai que filter_by_* si ça vous va.

Frédéric Péters a écrit :

Pour le coup j'ai oublié de retirer la seconde partie du message de commit; tant pis.

T'as rien oublié : la faute sur le relecteur.