L'écriture (TABLE1 table2) sert surtout à accéder à des champs de table2 par des balises #XXX dans la boucle (à condition que #XXX ne soit pas défini aussi pour TABLE1).
Mais de toute manière ça ne marche pas non plus...
A bientôt
Simon
Teddy Payet a écrit :
Ça ne serait pas plutôt quelque chose de ce genre :
<BOUCLE_articles_agenda(ARTICLES evenements){par evenements.date_debut}{0,10}{doublons}>
La jointure faut l'indiquer dans les parenthèses aussi me semble-t-il...
Le 31 mars 10 à 05:29, Simon Camerlo a écrit :
Personne n'a de réponse ?
C'est bien dommage, ce genre de jointure est pourtant très utile dans l'affichage d'un agenda...
A bientôt
Simon
Simon Camerlo a écrit :
Bonjour,
La boucle suivante renvoie une erreur de compilation sur le critère de jointure.
L'écriture (TABLE1 table2) sert surtout à accéder à des champs de table2 par des balises #XXX dans la boucle (à condition que #XXX ne soit pas défini aussi pour TABLE1).
Mais de toute manière ça ne marche pas non plus...
A bientôt
Simon
Teddy Payet a écrit :
Ça ne serait pas plutôt quelque chose de ce genre :
<BOUCLE_articles_agenda(ARTICLES evenements){par evenements.date_debut}{0,10}{doublons}>
La jointure faut l'indiquer dans les parenthèses aussi me semble-t-il...
Le 31 mars 10 à 05:29, Simon Camerlo a écrit :
Personne n'a de réponse ?
C'est bien dommage, ce genre de jointure est pourtant très utile dans l'affichage d'un agenda...
A bientôt
Simon
Simon Camerlo a écrit :
Bonjour,
La boucle suivante renvoie une erreur de compilation sur le critère de jointure.
Ça ne serait pas plutôt quelque chose de ce genre :
<BOUCLE_articles_agenda(ARTICLES evenements){par
evenements.date_debut}{0,10}{doublons}>
il ne peut pas y avoir de jointure depuis la table spip_articles vers
la table spip_evenements.
rien dans la table spip_articles (aucun champ) ne pointe 'directement'
(ou indirectement en passant par une 'table de jointure dédiée') sur la
table spip_evenements.
à l'inverse, si l'on part de EVENEMENTS comme table principale
(<BOUCLE_e(EVENEMENTS){...}>) alors, *dans ce sens là* on peut établir
une jointure sur spip_articles puisque spip_evenements possède bien un
champ id_article.
ainsi :
<BOUCLE_aa(EVENEMENTS){par date_debut}{0,10}{doublons}>
(#ID_RUBRIQUE) #ID_ARTICLE-#LESAUTEURS - #TITRE<br />
</BOUCLE_aa>
m'affichera bien :
- l'id_rubrique de l'article (unique) lié à chaque évènement ;
- l'id_article de l'article (unique) lié à chaque évènement ;
- le nom/lien de l'auteur de l'article (unique) lié à chaque évènement ;
- le titre de *l'évènement* (*pas* de l'article)
! attention !
si l'on veut récupérer des éléments (champs) de la table spip_articles,
par exemple #CHAPO, alors *il faut* préciser le nom de la table que l'on
veut joindre à la table principale.
dans notre cas, il faut écrire :
<BOUCLE_aa(EVENEMENTS articles){par date_debut}{0,10}{doublons}>
pour pouvoir accéder à : #CHAPO, #PS, #SURTITRE, #SOUSTITRE...
bref, à tous les champs *non homonymes* de spip_articles.
pour en revenir à la question de Simon, il n'y a d'autre solution
que de passer par 2 boucles imbriquées (et sans doute jouer avec #TOTAL_BOUCLE et |unique).
Ça ne serait pas plutôt quelque chose de ce genre :
<BOUCLE_articles_agenda(ARTICLES evenements){par
evenements.date_debut}{0,10}{doublons}>
il ne peut pas y avoir de jointure depuis la table spip_articles vers
la table spip_evenements.
rien dans la table spip_articles (aucun champ) ne pointe 'directement'
(ou indirectement en passant par une 'table de jointure dédiée') sur la
table spip_evenements.
(...)
C'est bête que la recherche de concordance sur les id_* ne se fasse pas dans ce sens...
Comme on a déjà :
- soit l'id_x est présent dans la table principale => jointure
- soit la table table1_table2 (ou table2_liens ?) existe => jointure
J'ai pensé qu'en dernier recours spip regarderait la concordance dans l'autre sens : si l'id_x est présent dans la table 2, alors on joint.
C'est mathématiquement possible puisque le lien est défini, le tout est de le rechercher, ce que le compilateur ne fait donc pas, j'ai appris un truc...
! attention !
si l'on veut récupérer des éléments (champs) de la table spip_articles,
par exemple #CHAPO, alors *il faut* préciser le nom de la table que l'on
veut joindre à la table principale.
dans notre cas, il faut écrire :
<BOUCLE_aa(EVENEMENTS articles){par date_debut}{0,10}{doublons}>
pour pouvoir accéder à : #CHAPO, #PS, #SURTITRE, #SOUSTITRE...
bref, à tous les champs *non homonymes* de spip_articles.
oui, ça je le précisais aussi.
pour en revenir à la question de Simon, il n'y a d'autre solution
que de passer par 2 boucles imbriquées (et sans doute jouer avec #TOTAL_BOUCLE et |unique).
Je suis passé par deux boucles successives avec des #ARRAY, moins gourmand que des boucles imbriquées, mais bon, ça complique l'écriture.
Ça ne serait pas plutôt quelque chose de ce genre :
<BOUCLE_articles_agenda(ARTICLES evenements){par
evenements.date_debut}{0,10}{doublons}>
il ne peut pas y avoir de jointure depuis la table spip_articles vers
la table spip_evenements.
rien dans la table spip_articles (aucun champ) ne pointe 'directement'
(ou indirectement en passant par une 'table de jointure dédiée') sur la
table spip_evenements.
(...)
C'est bête que la recherche de concordance sur les id_* ne se fasse pas dans ce sens...
Comme on a déjà :
- soit l'id_x est présent dans la table principale => jointure
- soit la table table1_table2 (ou table2_liens ?) existe => jointure
J'ai pensé qu'en dernier recours spip regarderait la concordance dans l'autre sens : si l'id_x est présent dans la table 2, alors on joint.
C'est mathématiquement possible puisque le lien est défini, le tout est de le rechercher, ce que le compilateur ne fait donc pas, j'ai appris un truc...
ce serait possible, mais attention, c'est une jointure 1=>N donc cela va produire potentiellement N resultats pour 1 article, sauf a utiliser un groub_by.
a écrit : Oui, c’est le but. Ou alors on peut aussi les filtrer avec |unique, mais dans certains cas c’est beaucoup plus optimal que de passer par plusieurs boucles, par exemple : je veux tous les articles liés à des événements se déroulant la semaine prochaine classés par date de début, je comptais faire : <BOUCLE_semaine(ARTICLES){evenements.date_debut <= #GET{dimanche}}{evenements.date_fin >= #GET{lundi}}{par evenements.date_debut}> [(#TITRE|unique) ] </BOUCLE_semaine> Sans oublier les éventuels autres critères à ajouter à cette boucle, mais comme la jointure bloque, je suis passé par les contorsions évoquées plus haut. A bientôt Simon
Pardon, c'est :
[(#SET{lundi,#GET{dimanche}|agenda_jourdecal{-8,Y-m-d 99:99}})]
sinon tu n'auras les événements qu'à partir de lundi à 99h99, ce qui en laisse ma fois peu.
A bientôt
Simon
Simon Camerlo a écrit :
Alors, c'est un peu un truc de ninja dans mon cas, mais ça marche et c'est 100% spip + agenda :