-----Message d’origine-----
@ Christophe Roland <croland@siticom.com> :
De toutes façons, si les numéros sont de la forme 0 1 2 3 4... ou 00 01 02
03 ... 10 11.. 99; le critère de tri {par titre} fonctionnera
parfaitement. On est donc en train de couper les cheveux en 4.--> Oui mais si on veut des tris {par date} s'il n'y a pas de n° ?
Oui oui, voilà, c'est bien ça le but. Au fond c'est bien Anne Possoz qui a
raison : si on veut blinder les tris, il va falloir s'en occuper
sérieusement. L'histoire du {par num...} n'était qu'un petit hack limité.
-- Fil
'lut
Il y a quelques jours, j'ai envoyé un mail sur la liste pour dire qu'il
serait pratique de récuperer automatiquement le nom des fichiers que l'on
met en document joint pour ne pas avoir a saisir les titres à la main.
Dans le même registre, lorque l'on saisie un titre, il faut le faire
document par document et les valider un par un. Quand on a deux ou trois
documents ça va. Mais lorsque l'on a une trentaine de titres à taper, le
travail serait moins long si on avait la possibilité de tous les saisir (en
dépliant tous les documents) et de tous les valider d'un coup.
Voila, pour mes deux petites remarques.
Bonne journée.
Babal.
@ Christophe Roland <croland@siticom.com> :
De toutes façons, si les numéros sont de la forme 0 1 2 3 4... ou 00 01 02
03 ... 10 11.. 99; le critère de tri {par titre} fonctionnera
parfaitement. On est donc en train de couper les cheveux en 4.
Oui, tout à fait d'accord, sauf que {par num ..} évitait d'avoir à saisir
les zéros non significatifs. C'est sûr que ça marche {par titre} avec
supprimer_numeros si on mets bien les 0 non significatifs, mais à ce moment
là autant virer {par num ..}.
Encore que si j'imagine toujours que le fait de rajouter un numéros est une
façon ponctuelle de forcer le tri, que je commence par 1, 2, 3 , quand
j'arrive à 10 il faut que je reprenne les 9 articles avec un zéro non
significatif. Pas cool. Où alors d'office je mais 7 ou 8 zéros non
significatifs, histoire d'être tranquille 
Mais va demander à tes
rédacteurs de faire gaffe à ça : à mon avis, c'est juste bon pour que
l'admin se tape l'uniformisation de ça avant validation.
--> Oui mais si on veut des tris {par date} s'il n'y a pas de n° ?
Oui oui, voilà, c'est bien ça le but. Au fond c'est bien Anne Possoz qui a
raison : si on veut blinder les tris, il va falloir s'en occuper
sérieusement. L'histoire du {par num...} n'était qu'un petit hack limité.
Oui, c'est sûr que ça ne résout pas le problème, mais dans ma réflexion, je
me suis dit que l'histoire des numéros permettait d'écraser un tri
prédéfini. Il me semblait logique de dire : je classe par titre (ou tout
autre balise "texte" d'ailleurs), mais *si* j'ai besoin de contourner le
classement pour une raison quelconque, alors je rajoute des numéros. C'est
donc bien sur cette même balise que celle utilisée pour le tri que tu
interviens. Mon hypothèse n'envisageait pas la possibilité que le fait de
mettre des numéros pouvait instaurer *ponctuellement* un autre critère de
tri que là où il n'y pas de numéros. Je n'ai pas dit que j'avais raison,
mais je cherchais à ne pas trop compliquer le problème. Déjà une correction
dans ce sens serait sympa. Mais là, c'est plus trop de ma compétence ;(
-- Roustoubi
@ Fil <fil@rezo.net> :
> --> Oui mais si on veut des tris {par date} s'il n'y a pas de n° ?
Bon, j'ai rétabli la possibilité de faire {par num titre,date} qui signifie
"trier par num titre, et à l'intérieur d'un même numéro (0 si pas de numéro)
trier par date. Ce n'est pas complet car il faudra gérer aussi {par num
titre, points}, ce qui dans le schéma actuel ne fonctionne pas (on verra ça
pour la 1.5, là on s'occupe exclusivement des bugs et incompatibilités de la
1.4)
Si vous voulez teser, c'est le fichier inc-calcul-squel.php3 qu'il faut
remplacer
http://rezo.net/spip-cvs/inc-calcul-squel.php3?rev=1.84&cvsroot=SPIP&content-type=text/plain
-- Fil
Bon, j'ai rétabli la possibilité de faire {par num titre,date} qui signifie
"trier par num titre, et à l'intérieur d'un même numéro (0 si pas de numéro)
trier par date.
Oui {par num titre,date} et {par num titre,titre} fonctionnent.
Attention cependant, {par num titre} seul renvoie l'erreur suivante :
<BOUCLE_articles>
Erreur dans la requête envoyée à MySQL :
SELECT
articles.id_article,articles.id_rubrique,articles.id_secteur,articles.surtit
re,articles.titre,articles.soustitre,articles.date,articles.date_redac,artic
les.visites,articles.popularite,articles.statut,articles.accepter_forum FROM
spip_articles AS articles WHERE articles.date<NOW() AND
articles.statut='publie' ORDER BY num titre
' > You have an error in your SQL syntax near 'titre' at line 1
</BOUCLE_articles>
J'imagine que ceux qui mettraient un SPIP à jour avec des squelettes qui
utilisent des {par num titre} se poseraient des questions.
En revanche, les rubriques numérotées sont toujours renvoyées après les
non-numérotées, ce qui ne me semble pas logique. Peut-être que c'est moi qui
ne voit pas ça sous le bon angle, mais il n'y a pas 36 façons d'envisager la
chose :
- soit on voit les numéros comme un ajustement ponctuel : si dans une liste
on ne numérote que quelques articles, c'est qu'on veut faire ressortir ces
quelques articles. Or, il est légitime de penser que pour mettre en avant
des articles, il est préférable de les mettre en tête d'une liste plutôt
qu'en fin de liste. Donc, en l'état, ça veut dire que ce sont les articles
sans num qui ressortent et donc qu'il faut numéroter les articles qu'on veux
voir "en dernier" (et on raisonne par le contraire)
- soit on voit ça d'une façon globale, il faut donc que *tous* les articles
de la listes soient numérotés (pas cool mais faisable s'il le fallait)
Vous aurez compris mon opinion là-dessus : la numérotation me parait
contraignante et non ergonomique, mais c'est très pratique parce que c'est
le seul moyen de forcer un tri une fois que les squelettes ont été faits
(quelque soit le critère d'ailleurs). Or quand on fait ses squelettes, on
sait a priori ce qu'on veut obtenir comme classement. Donc la modification
de cet ordre me paraît relever d'une modification ponctuelle (pour le
global, il n'y a qu'a modifier le critère de tri dans les squelettes). Donc
je pense qu'il faut d'abord les rubriques numérotées, puis les
non-numérotées avec leur critère propre (par date par exemple). Mais c'est
promis, quoique vous décidiez, je ne vous embête plus avec ça.
Ce n'est pas complet car il faudra gérer aussi {par num
titre, points}, ce qui dans le schéma actuel ne fonctionne pas (on verra ça
pour la 1.5, là on s'occupe exclusivement des bugs et incompatibilités de la
1.4)
Oui, il faudra même certainement reprendre un certain flou que ça engendre
dans la combinaison des critères. Par exemple, {par num titre,date}{inverse}
renvoie les rubriques triées par date dans l'ordre inverse mais pas celles
par num. C'est peut-être logique par rapport à la programmation, mais il
conviendra d'une façon générale d'éclaircir cette logique pour qu'on ne se
demande pas toujours "qu'est ce que ça va donner si je combine ça et ça ?"
-- Roustoubi
Oui {par num titre,date} et {par num titre,titre} fonctionnent.
OK
Attention cependant, {par num titre} seul renvoie l'erreur suivante :
Ah oui, zut. Excès de confiance ;( Je corrige...
En revanche, les rubriques numérotées sont toujours renvoyées après les
non-numérotées, ce qui ne me semble pas logique. Peut-être que c'est moi qui
Oui, il faudra y penser.
Oui, il faudra même certainement reprendre un certain flou que ça engendre
dans la combinaison des critères. Par exemple, {par num titre,date}{inverse}
renvoie les rubriques triées par date dans l'ordre inverse mais pas celles
par num.
Il faudra en fait, je pense, trier {par date}{inverse} {par num titre,
inverse}, des choses comme ça... cette fois, bien réfléchir avant de
proposer des trucs qui marchouillent mais nous bloqueraient.
-- Fil
Toujours avec mon soucis d'avoir un moyen simple et centralisé de contrôler
la mise en ligne de l'ensemble des éléments d'une rubrique...
Pour les menus rubriques, j'abandonne l'histoire des dates de publication.
Je n'y arrive pas...
Je fais simplement ça : sur les conseils de Fil, j'attribue un mot clé à
chaque rubrique à la racine ("PUBLIER : OUI" ou "PUBLIER : NON") et je fais
le contrôle de ce mot clé. C'est tout.
Maintenant si je peux encore demander un peu d'aide.
J'affiche dans un menu les 5 articles les plus récents de tout le site.
Mais comment exclure ceux qui sont dans un secteur où le mot clé est
"PUBLIER : NON" ?
Si quelqu'un peut me mettre sur la voie (et si c'est possible !), merci
beaucoup.
Dominique Jalu
De tête, dans ta boucle ARTICLES, tu met une boucle (RUBRIQUES) {id_secteur}
qui remonte au secteur de l'article. Dans cette boucle, tu teste si le mot
clé est PUBLIER : NON {id_mot = qq chose} mais je n'ai encore jamais utilisé
les mots clés. Bref. Si le mot clé est PUBLIER : OUI, alors cette boucle ne
va rien renvoyer, donc tu mets
</BOUCLE_... (MOTS)>
#TITRE_ARTICLE
<//B_... (MOTS)>
#TITRE_ARTICLE n'est renvoyé que si la boucle qui teste le mot clé ne
renvoie rien, donc ça devrait être ce que tu veux. J'ai bon ?
-- Roustoubi
T'as bon.
(sauf pour le nombre d'articles à disposer :
j'en voulais 5 et avec cette méthode je peux en avoir 0
mais je vais m'en sortir)
Merci
Dominique Jalu