[spip-dev] nouveau critère {par alpha titre}

Dev
1

bonjour,

une demande fréquente est de pouvoir sortir une liste
des titres d'article (par exemple) triée par ordre
alphabétique *indépendament* de la présence ou non
des préfixes numérotés.

actuellement le critère {par num titre} sort :

Abracadabra
Ciel mon mari !
02. Au secours !
08. Du bo, du bon, du bonnet.
99. À la claire fontaine

quand le critère {par titre}, lui affiche :

02. Au secours !
08. Du bo, du bon, du bonnet.
99. À la claire fontaine
Abracadabra
Ciel mon mari !

le nouveau critère {par alpha titre}, lui, sortirait :

99. À la claire fontaine
Abracadabra
02. Au secours !
Ciel mon mari !
08. Du bo, du bon, du bonnet.

on pourrait, dans ecrire/public/criteres.php,
modifier la fonction critere_parinverse_dist()
en lui donnant :

// par alpha champ(, suite)
} else if (preg_match(",^alpha (.*)$,m",$par, $m)) {
   $texte = "TRIM(LEADING '0' FROM(REPLACE(" . $boucle->id_table . '.' .
             trim($m[1]) . ", CONCAT(0+" . $boucle->id_table . '.' .
             trim($m[1]) . ", '. '), '')))";
   $suite = calculer_liste($tri, array(), $boucles, $boucle->id_parent);
   if ($suite !== "''")
     $texte = "\" . ((\$x = $suite) ? ('$texte' . \$x) : '0')" . " . \"";
   $as = 'alpha' .($boucle->order ? count($boucle->order) : "");
   $boucle->select[] = $texte . " AS $as";
   $order = "'$as'";

testé en 2.1 [14503] et 2.0.9 [14503]

2

je prefererai qu'on sorte pour de bon ces fichus numéros dans un champ #RANG séparé, ce qui permettrait in fine que le {par titre} fonctionne dans tous les cas, plutot que de rajouter une nouvelle verrue pour palier aux défauts de la première.

Cédric

3

+1

Committo,Ergo:Sum

4

Committo,Ergo:sum a écrit :

+1

oui.
j'ai déjà oublié ma proposition...

5

Pas contre un #rang, mais pour jouer l'avocat du diable:
- comment je fais, alors, pour classer des articles et des rubriques dans une même liste (ce que je fais quotidiennement et sans douleur en utilisant les numéros de titres)?

ARNO*

6

S'lt

Une amorce de plugin rang est sur la zone, il reste beaucoup de taff
et pas mal concernant l'intégration à l'espace privé actuel.
Maieul à deja fait des suggestions à tester pour ce point là.

Pas contre un #rang, mais pour jouer l'avocat du diable:
- comment je fais, alors, pour classer des articles et des rubriques dans
une même liste (ce que je fais quotidiennement et sans douleur en utilisant
les numéros de titres)?

Je ne vois pas comment tu aurais plus ou moins de douleur avec un
champ supplémentaire rang dans les tables articles et rubriques. De ce
que j'ai pu voir sur contrib faire ce que tu dis relève de base de la
douleur.

yakakoder

Km

7

a écrit : Pour ma part je dirais plutôt qu’un champ rang aiderait à enfin pouvoir faire un tri mélangé, ce que je n’ai jamais réussi à faire à cause de l’absence de balise "#NUM TITRE " : <BOUCLE_rub(RUBRIQUES){par rang}> <BOUCLE_art_avant(ARTICLES){par rang}{rang<#RANG}> #TITRE
</BOUCLE_art_avant> #TITRE
#SET{dernier_rang,#RANG} </BOUCLE_rub> <BOUCLE_art_apres(ARTICLES){par rang}{rang>=#GET{dernier_rang}}> #TITRE
</BOUCLE_art_apres> A bientôt Simon

8

Ah mais si, la balise #RANG existe déjà et retourne «#NUM TITRE» justement :
http://trac.rezo.net/trac/spip/browser/spip/ecrire/public/balises.php#L443

9

Matthieu Marcillaud a écrit :

Ah mais si, la balise #RANG existe déjà et retourne «#NUM TITRE» justement :
http://trac.rezo.net/trac/spip/browser/spip/ecrire/public/balises.php#L443

certes certes...

mais pour avoir un tri par ordre alphabétique *indépendament*
de la présence *ou non* d'un préfixe numéroté...

hein ? hein ?

10

Matthieu Marcillaud a écrit :

Pour ma part je dirais plutôt qu'un champ rang aiderait à enfin pouvoir
faire un tri mélangé, ce que je n'ai jamais réussi à faire à cause de
l'absence de balise "#NUM TITRE " :

Ah mais si, la balise #RANG existe déjà et retourne «#NUM TITRE» justement :
http://trac.rezo.net/trac/spip/browser/spip/ecrire/public/balises.php#L443

En effet, je ne l'avais pas vue.
Mais il faut dire que c'est récent, non encore documenté sur spip.net, et pas encore dans les versions non SVN...

A part ça, elle permet de solutionner le problème mais ça serait quand-même plus propre de stocker le rang à part pour pouvoir, entre-autre faire des tris dessus lors de jointures :
<BOUCLE_art(ARTICLES){par rubriques.rang, titre}>
    #TTIRE <br />
</BOUCLE_art>

A bientôt
    Simon

11

Je me permets de répéter ma proposition évoquée dans un fil précédent sur
le même thème :

Vu que le rang est relatif au contenant et au contenu (un même article
n'a pas le même rang suivant dans quelle liste sémantique il apparaît,
par exemple), une idée serait une table spip_rangs qui associe
contenants et contenus (avec bien sûr le rang du contenu), donc avec
pour champs :
- type du référent / contenant / motquivabien (rubrique, mot-clé, etc.)
- son id
- type de l'item / élément contenu (idem, typiquement article)
- son id
- rang de l'item dans le contenant

Ensuite en termes d'interface, plusieurs solutions (mais c'est déjà de
l'ordre du détail) :
- Soit une saisie rang dans l'édition du contenant (rubrique ou mot-clé
notamment) : dans l'interface d'ajout on propose un champ de formulaire
"rang" où les gens mettent un rang relatif (genre 100, 200, etc.). Idem
quand l'ajout se fait depuis l'élément contenu (par exemple ajout de
mot-clé à un objet).
- Soit une interface de type "monter/descendre" dans la zone d'édition
du contenant.

Mais vraiment la partie importante pour moi c'est de voir que le rang
concerne la _paire_ contenant/contenu et non pas juste le contenu, sinon
on se tire d'emblée une balle dans le pied.

12

davux a écrit :

Mais vraiment la partie importante pour moi c'est de voir que le rang concerne la _paire_ contenant/contenu et non pas juste le contenu

tout à fait d'accord avec ça.

mais le problème de ce genre de truc (rang), c'est 'intercaler'.
éviter de retomber dans la bidouille des numérotations 0001, 0154,...

le passage en intervallaire ('entre' qui et qui ?) est, de ce point
de vue, une solution hyper efficace (je dirais).

13

S'lt

Mais vraiment la partie importante pour moi c'est de voir que le rang
concerne la _paire_ contenant/contenu et non pas juste le contenu

tout à fait d'accord avec ça.

mais le problème de ce genre de truc (rang), c'est 'intercaler'.
éviter de retomber dans la bidouille des numérotations 0001, 0154,...

le passage en intervallaire ('entre' qui et qui ?) est, de ce point
de vue, une solution hyper efficace (je dirais).

Le sql intervallaire est pas mal du tout mais faut blinder les
requêtes SQL car se gèrant par paires, donc si pas de transaction le
risque d'avoir un arbre foutu existe. Mais il y a des alternatives
comme codé entre autre dans FT.

Pour ma part je ne dirais pas que le problème soit le choix de
l'implémentation,
-* un champ séparé comme démarré par le plugin rang,
-* une solution intervallaire initiée avec sql_arbo,
-* ou une solution d'appariement contenant/contenu

Elles ont toutes avantages et inconvénients.

Là où ça coince ce sont les couches supérieures pour
- greffer ces mécaniques dans les comportements standard de SPIP
(pipeline, define, *_dist, ...)
- une logique de présentation/ergonomie/... (dans quelle page on
range, comment, glisser/deposer, champ à remplir, logique vis à vis de
l'objet traité, ....)

C'est pour ma part ce dernier point qui est gênant car finalement
faire un rang c'est facile mais proposer une logique de rangement
cohérente en est une autre.

Km