Petite question un peu incongrue peut être : Peut-on en SPIP 192e avoir un syntaxe de ce type dans une boucle {par #GET{tri}} ? J’aimerais rendre variable le choix de l’ordre de tri de la boucle par date, titre, num titre ou tout autre champ, est-ce possible ? Si oui est-ce que quelqu’un peut m’expliquer comment car j’ai bien entendu fait un truc de ce type :
Il me semble que c'est tout à fait faisable mais en mettant un #ENV à la place ce de #GET.
Ainsi tu mets en parametre url le terme de tri, ce qui donnerai:
tri=date
tri=titre
etc.
A tester...
Le 12 nov. 08 à 06:24, Xébiaut a écrit :
Bonjour,
Petite question un peu incongrue peut être : Peut-on en SPIP 192e avoir un syntaxe de ce type dans une boucle {par #GET{tri}} ? J’aimerais rendre variable le choix de l’ordre de tri de la boucle par date, titre, num titre ou tout autre champ, est-ce possible ? Si oui est-ce que quelqu’un peut m’expliquer comment car j’ai bien entendu fait un truc de ce type :
J’aimerais rendre variable le choix de l’ordre de tri de la boucle par date, titre, num titre ou tout autre champ, est-ce possible ?
d'abord :
{par num titre, date, id_auteur}
est équivalent à :
{par num titre} {par date} {par id_auteur}
ensuite : #SET{crit_par, 'num titre'}
...
{par #GET{crit_par}}
ne fonctionnera pas :
'num titre' sera traduit par 'numtitre'
car c'est un critère calculé (ce n'est pas un champ de table)
il te faut donc revoir la logique de ton processus de proposition des choix...
J’aimerais rendre variable le choix de l’ordre de tri de la boucle par date, titre, num titre ou tout autre champ, est-ce possible ?
d'abord :
{par num titre, date, id_auteur}
est équivalent à :
{par num titre} {par date} {par id_auteur}
ensuite : #SET{crit_par, 'num titre'}
...
{par #GET{crit_par}}
ne fonctionnera pas :
'num titre' sera traduit par 'numtitre'
car c'est un critère calculé (ce n'est pas un champ de table)
il te faut donc revoir la logique de ton processus de proposition des choix...
Une solution possible est l'inclusion conditionnelle : en fonction du critère de tri tu fais un INCLURE{fond=pardate}{idxxxx} etc. Dans la mesure où il n'y a pas de problème d'inclusion de boucles (genre doublons, recursivité etc)
autre solution : comme la balise est interprétée, il est envisageable d'utiliser le nom de la colonne dans la base mais c'est limite en terme de pérennité/portabilité.
je me permets de relancer un sujet ouvert il y a quelques mois, concernant la possibilité de configurer le critère de tri {par ... }.
Je souhaite utiliser une variable #SET{montri} avec 3 valeurs : #SET{montri, date} #SET{montri, titre} #SET{montri, num titre}
Le problème c'est que lors de l'appel de la variable dans mon critère par #GET{montri}}, la valeur "num titre" est remplacée par "numtitre".
J'ai bien pensé à la solution de l'include proposée par denisb, mais je souhaiterais limiter le nombre de fichier (je suis déjà dans un inclure!!!>
Où se passe la modification du contenu de la balise ?
Est-il possible d'éviter que soient supprimés les espaces contenus dans une balise lorsque celle-ci est utilisée dans un critère ?
(j'avais pensé aux étoiles #GET*{montri} mais ca ne fonctionne pas.
Le 12 nov. 08 à 10:23, chryjs a écrit :
denisb a écrit :
Xébiaut a écrit :
J’aimerais rendre variable le choix de l’ordre de tri de la boucle par date, titre, num titre ou tout autre champ, est-ce possible ?
d'abord :
{par num titre, date, id_auteur}
est équivalent à :
{par num titre} {par date} {par id_auteur}
ensuite : #SET{crit_par, 'num titre'}
...
{par #GET{crit_par}}
ne fonctionnera pas :
'num titre' sera traduit par 'numtitre'
car c'est un critère calculé (ce n'est pas un champ de table)
il te faut donc revoir la logique de ton processus de proposition des choix...
Une solution possible est l'inclusion conditionnelle : en fonction du critère de tri tu fais un INCLURE{fond=pardate}{idxxxx} etc. Dans la mesure où il n'y a pas de problème d'inclusion de boucles (genre doublons, recursivité etc)
autre solution : comme la balise est interprétée, il est envisageable d'utiliser le nom de la colonne dans la base mais c'est limite en terme de pérennité/portabilité.
essaye le plugin spip-bonux et sa balise #TRI,
C'est bluffant, vraiment incroyable ce qu'a fait Cédric...
Le 4 mars 09 à 18:13, listes a écrit :
Bonsoir,
je me permets de relancer un sujet ouvert il y a quelques mois, concernant la possibilité de configurer le critère de tri {par ... }.
Je souhaite utiliser une variable #SET{montri} avec 3 valeurs : #SET{montri, date} #SET{montri, titre} #SET{montri, num titre}
Le problème c'est que lors de l'appel de la variable dans mon critère par #GET{montri}}, la valeur "num titre" est remplacée par "numtitre".
J'ai bien pensé à la solution de l'include proposée par denisb, mais je souhaiterais limiter le nombre de fichier (je suis déjà dans un inclure!!!>
Où se passe la modification du contenu de la balise ?
Est-il possible d'éviter que soient supprimés les espaces contenus dans une balise lorsque celle-ci est utilisée dans un critère ?
(j'avais pensé aux étoiles #GET*{montri} mais ca ne fonctionne pas.
Le 12 nov. 08 à 10:23, chryjs a écrit :
denisb a écrit :
Xébiaut a écrit :
J’aimerais rendre variable le choix de l’ordre de tri de la boucle par date, titre, num titre ou tout autre champ, est-ce possible ?
d'abord :
{par num titre, date, id_auteur}
est équivalent à :
{par num titre} {par date} {par id_auteur}
ensuite : #SET{crit_par, 'num titre'}
...
{par #GET{crit_par}}
ne fonctionnera pas :
'num titre' sera traduit par 'numtitre'
car c'est un critère calculé (ce n'est pas un champ de table)
il te faut donc revoir la logique de ton processus de proposition des choix...
Une solution possible est l'inclusion conditionnelle : en fonction du critère de tri tu fais un INCLURE{fond=pardate}{idxxxx} etc. Dans la mesure où il n'y a pas de problème d'inclusion de boucles (genre doublons, recursivité etc)
autre solution : comme la balise est interprétée, il est envisageable d'utiliser le nom de la colonne dans la base mais c'est limite en terme de pérennité/portabilité.
Le 4 mars 2009 18:13, listes <listes@nouveauxterritoires.fr> a écrit :
Bonsoir,
je me permets de relancer un sujet ouvert il y a quelques mois, concernant
la possibilité de configurer le critère de tri {par ... }.
Je souhaite utiliser une variable #SET{montri} avec 3 valeurs : #SET{montri, date} #SET{montri, titre} #SET{montri, num titre}
Le problème c'est que lors de l'appel de la variable dans mon critère par #GET{montri}}, la valeur "num titre" est remplacée par "numtitre".
Peut-être #SET{montri, "num titre"} avec guillemets ou quotes ?
En tout cas j'utilise souvent un #GET ou un #ENV pour mes {par XXX}
essaye le plugin spip-bonux et sa balise #TRI,
C'est bluffant, vraiment incroyable ce qu'a fait Cédric...
Merci
Mais je crains que aussi bien avec {tri ...} qu'avec {par ..}
il ne sera pas possible de passer num titre
La raison est assez simple :
num titre n'est pas un champ de la table, mais est transformé à la compilation par une expression calculée
Alors que lorsque un champ est calculé à l'execution pour être utilisé dans {par ...} ou {tri ...} il est directement passé à mysql.
Du coup num titre ne peut pas être transformé en expression calculée équivalente.
La suppression de l'espace entre num et titre n'est qu'un défaut apparent.
Ce problème ne pourra être résolu que par la création d'un champ #RANG comme prévu par l'un des 170 tickets.
Cédric
Le 4 mars 09 à 18:13, listes a écrit :
Bonsoir,
je me permets de relancer un sujet ouvert il y a quelques mois, concernant la possibilité de configurer le critère de tri {par ... }.
Je souhaite utiliser une variable #SET{montri} avec 3 valeurs : #SET{montri, date} #SET{montri, titre} #SET{montri, num titre}
Le problème c'est que lors de l'appel de la variable dans mon critère par #GET{montri}}, la valeur "num titre" est remplacée par "numtitre".
J'ai bien pensé à la solution de l'include proposée par denisb, mais je souhaiterais limiter le nombre de fichier (je suis déjà dans un inclure!!!>
Où se passe la modification du contenu de la balise ?
Est-il possible d'éviter que soient supprimés les espaces contenus dans une balise lorsque celle-ci est utilisée dans un critère ?
(j'avais pensé aux étoiles #GET*{montri} mais ca ne fonctionne pas.
Le 12 nov. 08 à 10:23, chryjs a écrit :
denisb a écrit :
Xébiaut a écrit :
J’aimerais rendre variable le choix de l’ordre de tri de la boucle par date, titre, num titre ou tout autre champ, est-ce possible ?
d'abord :
{par num titre, date, id_auteur}
est équivalent à :
{par num titre} {par date} {par id_auteur}
ensuite : #SET{crit_par, 'num titre'}
...
{par #GET{crit_par}}
ne fonctionnera pas :
'num titre' sera traduit par 'numtitre'
car c'est un critère calculé (ce n'est pas un champ de table)
il te faut donc revoir la logique de ton processus de proposition des choix...
Une solution possible est l'inclusion conditionnelle : en fonction du critère de tri tu fais un INCLURE{fond=pardate}{idxxxx} etc. Dans la mesure où il n'y a pas de problème d'inclusion de boucles (genre doublons, recursivité etc)
autre solution : comme la balise est interprétée, il est envisageable d'utiliser le nom de la colonne dans la base mais c'est limite en terme de pérennité/portabilité.
La solution que j'ai trouvé est de code en dur {par num titre} dans ma
boucle comme mode de tri par défaut et mettre avant {par #ENV{partri}} comme
ceci
<BOUCLE_A(ARTICLES){id_rubrique}{par #ENV{partri}}{par num titre}>
J'espère que cela aidera.
Cordialement,
Xavier
-----Message d'origine-----
De : cedric.morin@yterium.com [mailto:cedric.morin@yterium.com]
Envoyé : mercredi 4 mars 2009 22:40
À : Pierre Fiches
Cc : spip zone
Objet : Re: [SPIP Zone] Critère PAR modifiable ?
Pierre Fiches a écrit :
essaye le plugin spip-bonux et sa balise #TRI,
C'est bluffant, vraiment incroyable ce qu'a fait Cédric...
Merci
Mais je crains que aussi bien avec {tri ...} qu'avec {par ..}
il ne sera pas possible de passer num titre
La raison est assez simple :
num titre n'est pas un champ de la table, mais est transformé à la
compilation par une expression calculée
Alors que lorsque un champ est calculé à l'execution pour être utilisé
dans {par ...} ou {tri ...} il est directement passé à mysql.
Du coup num titre ne peut pas être transformé en expression calculée
équivalente.
La suppression de l'espace entre num et titre n'est qu'un défaut apparent.
Ce problème ne pourra être résolu que par la création d'un champ #RANG
comme prévu par l'un des 170 tickets.
Cédric
Le 4 mars 09 à 18:13, listes a écrit :
Bonsoir,
je me permets de relancer un sujet ouvert il y a quelques mois,
concernant la possibilité de configurer le critère de tri {par ... }.
Je souhaite utiliser une variable #SET{montri} avec 3 valeurs : #SET{montri, date} #SET{montri, titre} #SET{montri, num titre}
Le problème c'est que lors de l'appel de la variable dans mon critère
par #GET{montri}}, la valeur "num titre" est remplacée par "numtitre".
J'ai bien pensé à la solution de l'include proposée par denisb, mais
je souhaiterais limiter le nombre de fichier (je suis déjà dans un
inclure!!!>
Où se passe la modification du contenu de la balise ?
Est-il possible d'éviter que soient supprimés les espaces contenus
dans une balise lorsque celle-ci est utilisée dans un critère ?
(j'avais pensé aux étoiles #GET*{montri} mais ca ne fonctionne pas.
Le 12 nov. 08 à 10:23, chryjs a écrit :
denisb a écrit :
Xébiaut a écrit :
Jaimerais rendre variable le choix de lordre de tri de la boucle
par date, titre, num titre ou tout autre champ, est-ce possible ?
d'abord :
{par num titre, date, id_auteur}
est équivalent à :
{par num titre} {par date} {par id_auteur}
ensuite : #SET{crit_par, 'num titre'}
...
{par #GET{crit_par}}
ne fonctionnera pas :
'num titre' sera traduit par 'numtitre'
car c'est un critère calculé (ce n'est pas un champ de table)
il te faut donc revoir la logique de ton processus de proposition
des choix...
Une solution possible est l'inclusion conditionnelle : en fonction
du critère de tri tu fais un INCLURE{fond=pardate}{idxxxx} etc. Dans
la mesure où il n'y a pas de problème d'inclusion de boucles (genre
doublons, recursivité etc)
autre solution : comme la balise est interprétée, il est
envisageable d'utiliser le nom de la colonne dans la base mais c'est
limite en terme de pérennité/portabilité.
{par #ENV{tri}}{!par #ENV{_tri}}{par num #ENV{tri_n}}{!par num #ENV{_tri_n}}
En ne donnant une valeur uniquement à une des ces variables seu le par
associté sera traité.
car pour un #ENV{XX} vide, le critere de tri n'est pas pris en compte.
je me permets de relancer un sujet ouvert il y a quelques mois, concernant la possibilité de configurer le critère de tri {par ... }.
Je souhaite utiliser une variable #SET{montri} avec 3 valeurs : #SET{montri, date} #SET{montri, titre} #SET{montri, num titre}
Le problème c'est que lors de l'appel de la variable dans mon critère par #GET{montri}}, la valeur "num titre" est remplacée par "numtitre".
"je me permets de relancer un sujet ouvert il y a quelques mois, concernant la possibilité de configurer le critère de tri {par … }. Je souhaite utiliser une variable #SET{montri} avec 3 valeurs : #SET{montri, date} #SET{montri, titre} #SET{montri, num titre}
Le problème c’est que lors de l’appel de la variable dans mon critère par #GET{montri}}, la valeur « num titre » est remplacée par « numtitre ».
J’ai bien pensé à la solution de l’include proposée par denisb, mais je souhaiterais limiter le nombre de fichier (je suis déjà dans un inclure!!!>
Où se passe la modification du contenu de la balise ?
Est-il possible d’éviter que soient supprimés les espaces contenus dans une balise lorsque celle-ci est utilisée dans un critère ? (j’avais pensé aux étoiles #GET*{montri} mais ca ne fonctionne pas. "
