Critères optionnels et passage automatique de #ENV dans les modèles
#2788
Closed
opened 11 years ago by maieul
·
15 comments
No Branch/Tag Specified
1.8
1.9.1
1.9.2
2.0
2.1
3.0
3.1
3.2
4.0
4.1
4.2
boutons-danger
coquille_doc
debug_ecrire_fichier
dev-sortable
dev/autoloader
dev/hasard_fixe
dev/instituer_ergo
dev/issue_4626_menu_squelettes
dev/issue_5447_exporter_csv
dev_infos_image
fix/valider_url_distante
fix_issue_5454
fix_modifier_login
issue_4101
issue_4678
issue_4705
issue_4717
issue_4836
issue_4946
issue_5258
issue_5344
issue_5427_bis
issue_5483_find_script_jquery
issue_5487_info_maj
master
v1.8.3+b
v1.9.1+i
v1.9.2+f
v1.9.2+g
v1.9.2+h
v1.9.2+i
v1.9.2+j
v1.9.2+k
v1.9.2+m
v1.9.2+n
v1.9.2+o
v1.9.2+p
v2.0.0
v2.0.1
v2.0.10
v2.0.11
v2.0.12
v2.0.13
v2.0.14
v2.0.15
v2.0.16
v2.0.17
v2.0.18
v2.0.19
v2.0.2
v2.0.20
v2.0.21
v2.0.22
v2.0.23
v2.0.24
v2.0.25
v2.0.26
v2.0.3
v2.0.5
v2.0.6
v2.0.7
v2.0.8
v2.0.9
v2.1.0
v2.1.1
v2.1.10
v2.1.11
v2.1.12
v2.1.13
v2.1.14
v2.1.15
v2.1.16
v2.1.17
v2.1.18
v2.1.19
v2.1.2
v2.1.20
v2.1.21
v2.1.22
v2.1.23
v2.1.24
v2.1.25
v2.1.26
v2.1.27
v2.1.28
v2.1.29
v2.1.3
v2.1.30
v2.1.4
v2.1.5
v2.1.6
v2.1.7
v2.1.8
v2.1.9
v3.0.0
v3.0.0-alpha.1
v3.0.0-beta
v3.0.0-beta.2
v3.0.0-rc
v3.0.1
v3.0.10
v3.0.11
v3.0.12
v3.0.13
v3.0.14
v3.0.15
v3.0.16
v3.0.17
v3.0.18
v3.0.19
v3.0.2
v3.0.20
v3.0.21
v3.0.22
v3.0.23
v3.0.24
v3.0.25
v3.0.26
v3.0.27
v3.0.28
v3.0.3
v3.0.4
v3.0.5
v3.0.6
v3.0.7
v3.0.8
v3.0.9
v3.1.0
v3.1.0-alpha
v3.1.0-beta
v3.1.0-rc
v3.1.0-rc.2
v3.1.0-rc.3
v3.1.1
v3.1.10
v3.1.11
v3.1.12
v3.1.13
v3.1.14
v3.1.15
v3.1.2
v3.1.3
v3.1.4
v3.1.5
v3.1.6
v3.1.7
v3.1.8
v3.1.9
v3.2-alpha.1
v3.2.0
v3.2.0-alpha.1
v3.2.0-beta
v3.2.0-beta.2
v3.2.0-beta.3
v3.2.1
v3.2.10
v3.2.11
v3.2.12
v3.2.13
v3.2.14
v3.2.15
v3.2.16
v3.2.17
v3.2.2
v3.2.3
v3.2.4
v3.2.5
v3.2.6
v3.2.7
v3.2.8
v3.2.9
v4.0.0
v4.0.0-alpha
v4.0.0-beta
v4.0.1
v4.0.2
v4.0.3
v4.0.4
v4.0.5
v4.0.6
v4.0.7
v4.0.8
v4.0.9
v4.1.0
v4.1.0-alpha
v4.1.0-beta
v4.1.0-rc
v4.1.1
v4.1.2
v4.1.3
v4.1.4
v4.1.5
v4.1.6
v4.1.7
v4.2.0-alpha
v4.2.0-alpha2
Labels
Amélioration, nouvelle fonctionnalité APIs authentification base de données bug
Ca ne fonctionne pas code généré compilo css divers documentation doublon
Ce ticket est un doublon ergonomie espace privé filtres et balises formulaires Inscription installation invalide
Ticket invalide javascript langues LDAP plugin PostgreSQL refusé
Ignoré, c'est comme Ca... sécurité traduction
Apply labels
Clear labels
accessibilité
amélioration
Amélioration, nouvelle fonctionnalité APIs authentification base de données bug
Ca ne fonctionne pas code généré compilo css divers documentation doublon
Ce ticket est un doublon ergonomie espace privé filtres et balises formulaires Inscription installation invalide
Ticket invalide javascript langues LDAP plugin PostgreSQL refusé
Ignoré, c'est comme Ca... sécurité traduction
No Label
accessibilité
amélioration
APIs
authentification
base de données
bug
code généré
compilo
css
divers
documentation
doublon
ergonomie
espace privé
filtres et balises
formulaires
Inscription
installation
invalide
javascript
langues
LDAP
plugin
PostgreSQL
refusé
sécurité
traduction
Milestone
Set milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Assign users
Clear assignees
No Assignees
6 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.
No due date set.
Dependencies
This issue currently doesn't have any dependencies.
Reference in new issue
There is no content yet.
Delete Branch '%!s(MISSING)'
Deleting a branch is permanent. It CANNOT be undone. Continue?
No
Yes
Un exemple sera plus simple :
j'avais sous SPIP 2.1 un modèles sites.html de la forme suivante :
Je pouvais l'appeler soit via :
<sites|>
et dans ce cas j'avais les sites de toutes les rubriques, soit via<sites|id_rubrique=1>
et cela me permettait d'avoir les sites de la rubrique 1.Patatra, avec SPIP 3 cette option saute (avec ZPIP). En effet j'ai un id_rubrique dans le squelette appelant, j'ai donc un id_rubrique dans le modèle (selon la nouvelle règle de transmissions des #ENV aux modèles à SPIP 3).
La solution que j'ai trouvé pour le moment (mais pas top) est
Mais c'est moche. Il faudrait trouver un système plus pratique. Sur IRC (avec cerdic et denisb), denisb a suggéré
Sauf que comme le précise http://www.spip.net/fr_article4013.html : « Le critère ne sera pris en compte par la boucle que si une variable de même nom est présente dans l’environnement. »
La question est donc "comment faire un critère conditionnel qui ne prenne que les arguments passés explicitement en paramètre lors de l'appel du modèle".
Vu que ceux ci sont les seuls à pouvoir être récupérés également par #ENV{arg/nomdelargument}, la question est "comment boucler sur l'environnement défini par #ENV{arg/...}"
Une idée serait donc d'ajouter une balise spip permettant de modifier l'environnement de la manière voulue.
#SETENV{arg/} -> l'environnement se réinitialise avec l'ensemble des valeurs de #ENV{arg/...}
Si utile, #SETENV pourrait accepter des arguments d'autres formes pour ajouter ou modifier ou supprimer d'autres valeurs ou jeux de valeurs.
Je ne vois pas en quoi modifier #ENV{arg/} permettra de faire un critère optionnel …
C'est dans le cadre du portage d'un modèle qui fonctionne en SPIP2 et ne fonctionne plus en SPIP3 à cause d'un critère conditionnel. La proposition est de créer une nouvelle commande qui modifie tout l'env (qui le vide d'abord puis le recrée avec les différentes valeurs de arg/ affectées mais sans arg/ , c'est à dire que si ya #ENV{arg/id_article} avant, ce sera #ENV{id_article} après.
Il suffirait de mettre #SETENV{arg/} au début d'un modèle, et l'environnement ne contient plus QUE les paramètres passés explicitement, serait identique en SPIP3 à ce qu'il était en SPIP2, et les anciennes boucles marcheraient.
a ok, #SETENV influencerait l'#ENV de 1er niveau. Ce n'était pas très clair. Je croyais que #SETENV{arg/} permettait de modifier #ENV{arg}
... et en conséquence il sera possible d'utiliser un critère conditionnel.
De manière plus générale une ou des instructions SPIP pour manipuler l'environnement pourraient être utiles.
ouais, mais je crains le pire avec ca (comme les $GLOBALS qu'on trouve de manière pourrie dans certains codes PHP)
oui, dans l'idée #SETENV vide l'env et le réaffecte avec autant de valeurs qu'il y a d'entrées dans le tableau reçu en argument. A adapter ou étendre à d'autres manipulations.
très mauvaise idée que d'introduire une modification du #ENV, je pense qu'il faut trouver autre chose.
Version cible mise à 3.1
Voir la méthode utilisée dans le modèle de GIS pour contourner ce problème :
http://zone.spip.org/trac/spip-zone/browser/plugins/gis/trunk/modeles/carte_gis.html
http://zone.spip.org/trac/spip-zone/changeset/69436/
À mon avis c'est une bonne piste.
on peut regarder aussi l'astuce donnée dans le paragraphe 10 (Les modèles et leur contexte en SPIP3) de http://contrib.spip.net/Astuces-longues-pour-SPIP (utiliser 2 critères dépendants de #ENV{args/id_objet}).
Vu les solutions proposées pour s'adapter au nouveau comportement, je pense qu'on peut fermer le ticket.
Probablement qu'en debut de modèle il suffirait de mettre
[(#ENV{args/id_rubrique}|setenv{id_rubrique})]
et le tour sera jouéStatut changé à Fermé
tiens je remarque que par rapport à il y a 2 ans, cedric s'est converti à la modification de env...
à noter |setenv n'est pas (encore) dispo, c'est juste une proposition envoyée sur la liste spip-dev le 16.10.2014