[spip-dev] Bug ? (V1.7.1)

J'ai la boucle suivante qui fonctionne correctement :

<BOUCLE_TOP5(ARTICLES){tout}{par popularite}{inverse}{0,5}>
   [#PUCE<A href="#URL_ARTICLE">(#TITRE|supprimer_numero)</A><br>]
</BOUCLE_TOP5>

Mantenant j'ai créé un mot-clé appelé "invisible" pour inhiber certains article de mon TOP5 (article contact, présentation, etc.)

J'ai donc la boucle :

<BOUCLE_TOP5(ARTICLES){tout}{par popularite}{inverse}{0,5}{id_mot!=37}>
   [#PUCE<A href="#URL_ARTICLE">(#TITRE|supprimer_numero)</A><br>]
</BOUCLE_TOP5>

Et en fait, j'ai la QUASI certitude qu'il m'enlève aussi tous les articles qui n'ont AUCUN mot-clé associé.

Un smurtz dans la requête SQL ?

Quelqu'un peut-il me confirmer ?

Fred Q. a écrit :

J'ai la boucle suivante qui fonctionne correctement :

<BOUCLE_TOP5(ARTICLES){tout}{par popularite}{inverse}{0,5}>
  [#PUCE<A href="#URL_ARTICLE">(#TITRE|supprimer_numero)</A><br>]
</BOUCLE_TOP5>

Mantenant j'ai créé un mot-clé appelé "invisible" pour inhiber certains article de mon TOP5 (article contact, présentation, etc.)

J'ai donc la boucle :

<BOUCLE_TOP5(ARTICLES){tout}{par popularite}{inverse}{0,5}{id_mot!=37}>
  [#PUCE<A href="#URL_ARTICLE">(#TITRE|supprimer_numero)</A><br>]
</BOUCLE_TOP5>

Ce n'est pas la bonne méthode.
Voici comment faire :

<BOUCLE_invisible(ARTICLES){tout}{id_mot=37}{doublons}
</BOUCLE_invisible>

<BOUCLE_TOP5(ARTICLES){tout}{par popularite}{inverse}{0,5}{doublons}>
  [#PUCE<A href="#URL_ARTICLE">(#TITRE|supprimer_numero)</A><br>]
</BOUCLE_TOP5>

Olivier Mansour wrote:

Fred Q. a écrit :

J'ai la boucle suivante qui fonctionne correctement :

<BOUCLE_TOP5(ARTICLES){tout}{par popularite}{inverse}{0,5}>
  [#PUCE<A href="#URL_ARTICLE">(#TITRE|supprimer_numero)</A><br>]
</BOUCLE_TOP5>

Mantenant j'ai créé un mot-clé appelé "invisible" pour inhiber certains article de mon TOP5 (article contact, présentation, etc.)

J'ai donc la boucle :

<BOUCLE_TOP5(ARTICLES){tout}{par popularite}{inverse}{0,5}{id_mot!=37}>
  [#PUCE<A href="#URL_ARTICLE">(#TITRE|supprimer_numero)</A><br>]
</BOUCLE_TOP5>

Ce n'est pas la bonne méthode.
Voici comment faire :

<BOUCLE_invisible(ARTICLES){tout}{id_mot=37}{doublons}
</BOUCLE_invisible>

<BOUCLE_TOP5(ARTICLES){tout}{par popularite}{inverse}{0,5}{doublons}>
[#PUCE<A href="#URL_ARTICLE">(#TITRE|supprimer_numero)</A><br>]
</BOUCLE_TOP5>

Arf oui pourquoi pas ! Mais c'est un peu compliqué comme méthode.
Et alors pourquoi le language m'autorise t'il à faire un {id_mot!=37} ?

M'enfin merci pour le tuyau gars :slight_smile:

J'suis moyennement d'accord.
  Cette méthode résoud peut être le problème, mais elle n'est pas du
tout naturelle.

  Par contre, comment exprimer simplement la différence entre
«les articles ayant un mot clé autre que le 37» (ce que ça fait) et
«les articles n'ayant pas le mot clé 37» (ce que Fred Q veux)

  Il faudrait une construction du genre {!id_mot=37} ?

  À moins qu'on considère que le fonctionnement actuel est erroné et
qu'on décide de le change pour le fonctionnement voulu par Fred Q ?

À+, Pif.

PS : je n'ai pas (encore) vérifié si cette erreur est réelle. Tout ce
que je dis est donc conditionné par la confirmation du fonctionnement
pressenti par Fred Q.

À+, Pif.

Et alors pourquoi le language m'autorise t'il à faire un {id_mot!=37} ?

{id_mot CECI-CELA} signifie "l'article a un mot-clé qui vérifie CECI-CELA",
donc ton critère dit "l'article a un mot-clé dont l'id_mot est différent de
37". C'est pas totalement intuitif, mais c'est logique.

-- Fil

  Il faudrait une construction du genre {!id_mot=37} ?

Le problème c'est qu'à la base c'est de la jointure SQL.

-- Fil

En sybase, ça s'écrit
where not exists (select 1 where ... and id_mot=37)

  En mysql, ça n'existe pas directement, mais la doc explique comment
exprimer ça par un left join.

  Mais avant de plonger dans la doc, faudrait savoir si on considère que
le fonctionnement actuel est à garder et/ou s'il faut introduire un
{!condition} (et si oui, comment le généraliser :expressionless: )

À+, Pif.

Christian Lefebvre wrote:

Fil wrote:

Et alors pourquoi le language m'autorise t'il à faire un {id_mot!=37} ?

{id_mot CECI-CELA} signifie "l'article a un mot-clé qui vérifie CECI-CELA",
donc ton critère dit "l'article a un mot-clé dont l'id_mot est différent de
37". C'est pas totalement intuitif, mais c'est logique.

Ca se défend.
De logique purement algorithmique j'ai naturellement opté pour la mauvaise, mais pour un utilisateur lambda, je ne me rend pas compte :frowning:

Ya un soucis sur ce point. Le JOIN n'est accessible qu'à partir de
MySQL v4, et n'est pas dispo sur les v3.

Euh, non, je fais des join avec MySQL depuis des années sans
soucis ...

-Nicolas

Fred Q. wrote:

Ya un soucis sur ce point. Le JOIN n'est accessible qu'à partir de MySQL v4, et n'est pas dispo sur les v3. Et la plupart des hébergeurs tournent encore en v3 !

D'où la necessité de faire deux requête dans ce cas.

Et d'ailleurs c'est pas d'un JOIN mais d'un UNION dont je parlais :wink:

Nicolas Hoizey wrote:

Ya un soucis sur ce point. Le JOIN n'est accessible qu'à partir de
MySQL v4, et n'est pas dispo sur les v3.

Euh, non, je fais des join avec MySQL depuis des années sans
soucis ...

Oui oui autant pour moi, je parlais de UNION

  En mysql, ça n'existe pas directement, mais la doc explique comment
exprimer ça par un left join.

Je croyais qu'on devait simplifier les requêtes :slight_smile:

D'autant que si on veut que SPIP soit encore plus simple à installer, on a
tout intérêt à autoriser l'usage de sqlite, qui sera standard dans php5, et
qui permet de créer la base de données sous forme d'un fichier dans le
répertoire local... Là du coup l'intallation serait immédiate.
http://www.zend.com/manual/ref.sqlite.php

  Mais avant de plonger dans la doc, faudrait savoir si on considère que
le fonctionnement actuel est à garder et/ou s'il faut introduire un
{!condition} (et si oui, comment le généraliser :expressionless: )

Bof. Mieux vaut documenter ça proprement, et habituer les gens à suivre les
"bonnes pratiques".

-- Fil

> En mysql, ça n'existe pas directement, mais la doc explique comment
> exprimer ça par un left join.
Je croyais qu'on devait simplifier les requêtes :slight_smile:

Ouaip, c'est clair que ça va pas vraiement dans ce sens là ...

D'autant que si on veut que SPIP soit encore plus simple à installer, on a
tout intérêt à autoriser l'usage de sqlite, qui sera standard dans php5,

woula, rien que ça :expressionless:

> Mais avant de plonger dans la doc, faudrait savoir si on considère que
> le fonctionnement actuel est à garder et/ou s'il faut introduire un
> {!condition} (et si oui, comment le généraliser :expressionless: )
Bof. Mieux vaut documenter ça proprement, et habituer les gens à suivre les
"bonnes pratiques".

  Ça me va, mais doit y avoir des cas un peu plus tordu (genre
{doublons} déjà utilisé par ailleurs) où la bidouille de la boucle vide
doit foirer.

À+, Pif.

Christian Lefebvre wrote:

  Ça me va, mais doit y avoir des cas un peu plus tordu (genre
{doublons} déjà utilisé par ailleurs) où la bidouille de la boucle vide
doit foirer.

Surtout sur une page sommaire (comme mon cas justement)

Fred Q. <gouarfig <at> hotmail.com> writes:

Christian Lefebvre wrote:

> Ça me va, mais doit y avoir des cas un peu plus tordu (genre
> {doublons} déjà utilisé par ailleurs) où la bidouille de la boucle vide
> doit foirer.
>

Surtout sur une page sommaire (comme mon cas justement)

Bonjour,
j'ai justement un exemple où ça marche pas super.
J'ai une page "base documentaire" ou je veux d'abord afficher les nouveautés
de ma base documentaire, puis lister tous les articles présents y compris les
doublons, le tout en n'affichant pas les éléments "hors base docu"
(correspondant au mot "invisible").

Je comprends donc qu'on fait 3 boucles :
1 - la boucle vide, avec le critère {doublons}
2 - la boucle nouveautés avec le critère {doublons}, filtré par date
3 - la boucle articles de la base ... mais si je mets le critère {doublons},
il m'enlève les nouveautés... et si je ne le mets pas, il me met aussi les
articles hors base...

Comment faire, les gars ??
Merci
Jérémie

Bonjour

Une solution consisterait à mémoriser dans une variable php pour t'en reservir ensuite.
C'est ce que je fais quand je suis confronté à ce genre d'obstacles.
Je m'en sert aussi quand j'ai plusieurs fois la même boucle à afficher, ainsi, si je modifie la première boucle, je n'ai pas besoin de toucher à l'autre qui aurait été identique.
Parfois j'utilise <INCLURE> de Spip... ça dépend.

Amicalement
Grégoire