Discussion :

[lodan]

Bonjour,

Je me pose une question et je ne sais pas si c'est ici que je dois la poser.

J'ai quelques formulaires d'affichage de liste (liste des clients, liste des dossiers,...) et je voudrais pouvoir faire un tri par colonne. L'utilisateur n'ayant qu'à cliquer sur l'entête de colonne. Je n'ai aucune donnée à aller chercher sur le serveur une fois ma page affichée.

La question que je me pose est celle-ci :

Vaut-il mieux faire ce tri en php (côté serveur) ou en javascript (côté client) ?

Tiens je rajoute une question au passage, existe-t-il des scripts fiables dans l'un ou l'autre langage ?

Merci d'avance

[pioule]

Il vaut mieux faire le tri en javascript, en gros il faut alimenter un tableau js et appeler des fonctions de tri dessus quand tu clique sur les entêtes
Tu pourras trouver sur ce lien un petit javascipt qui te fait ça assez bien

[lodan]

Merci, j'ai testé, sûrement pas tout compris parceque je ne sais pas comment il tri, mais c'est n'importe comment.

En cliquant sur l'entête d'une liste de nom, ce n'est pas trié en ordre alphabétique.

J'ai un nom commençant par un T, puis un A, puis un B, puis un S, puis un R.

A moins que ce soit un autre alphabet que le notre.

Merci qu'en même.

[gloubi]

Tiens je rajoute une question au passage, existe-t-il des scripts fiables dans l'un ou l'autre langage ?

En javascript, la réponse est NON ! Certes, tu pourras trouver des scripts qui marchent, mais rien te garantie qu'il marcheront encore à la prochaine version de IE, rien te garantie que l'utilisateur accepte le javascript et rien te garantie que ça soit compatible sur tous les navigateurs.

Pour une utilisation pro, il faut se mettre en tête que JAVASCRIPT, c'est le malin (la mal, satan, belzebuth quoi)...

Si tu veux un truc fiable 100% du temps sur tous les navigateur, tu fais ton script en PHP et tu recharges ta pages à chaque tri.

[Mr N.]

L'inconvénient du javascript (outre les problèmes soulevés par gloubi, que je modererais par le fait que le tri n'est pas une fonctionnalité cruciale pour le fonctionnement d'un site et donc peut ne pas être disponible pour tout le monde), donc l'inconvénient du javascript disais-je, en terme de fonctionnalité, c'est que tu ne pourras pas stocker la préférence de l'utilisateur (moi je veux tout le temps trier par date, moi je veux tout le temps trier par nom, ...) (à moins de s'orienter vers ajax, ce qui n'est pas immédiat).

Après il y a les inconvénients techniques => maintenabilité, portabilité, ...

Mais ça a l'avantage de décharger le serveur et d'apporter un certain confort à l'utilisateur....

[lodan]

En javascript, la réponse est NON ! Certes, tu pourras trouver des scripts qui marchent, mais rien te garantie qu'il marcheront encore à la prochaine version de IE, rien te garantie que l'utilisateur accepte le javascript et rien te garantie que ça soit compatible sur tous les navigateurs.

Pour une utilisation pro, il faut se mettre en tête que JAVASCRIPT, c'est le malin (la mal, satan, belzebuth quoi)...

Si tu veux un truc fiable 100% du temps sur tous les navigateur, tu fais ton script en PHP et tu recharges ta pages à chaque tri.

Je suis dans un Intranet avec FF obligatoire. Je connais PHP mais pas Javascript donc les arguments sur la maintenabilité sont importants pour moi.

Le script qui m'a été fourni par le lien en javascript ne fonctionnant pas, je ne vais sûrement pas vu sa taille essayer de le changer.

Je vais donc partir sur un tri de tableau PHP.

L'usage du tri par l'utilisateur étant rare, le serveur ne devrait pas trop souffrir.

Merci à vous

[Sékiltoyai]

ou alors php.ajax, qui est une excellente alternative, même si l'on a la encore certains inconvénients du javascript et qu'il faut savoir le coder...

[gloubi]

Le problème AJAX a été efleuré

(à moins de s'orienter vers ajax, ce qui n'est pas immédiat).

mais Ajax = même problèmes que le javascript (si ce n'est plus), codage plus compliqué, et comme il disais plus haut :

Je n'ai aucune donnée à aller chercher sur le serveur une fois ma page affichée.

Utiliser AJAX n'est donc en aucun cas une "exelente alternative" ici !

[Mr N.]

gloubi, il ne faut pas sortir les phrases de leur contexte. Je parlais d'ajax dans le cas où on aurait besoin de stocker les preferences utilisateurs.

[gloubi]

Oh, je disais ça pour répondre au post de Sékiltoyai.

J'ai cité ton post pour bien illustrer le fait qu'on ne s'est pas étendu sur le cas AJAX parce justement, on est pas "dans le cas où", et non pas parce qu'on y a pas pensé. La citation illustrait juste ma 1er phrase : "le problème AJAX a déjà été éfleuré".

AJAX est inadapté ici, et je vois bien que ça ne t'as pas échapé. Simplement, si Sékiltoyai avais bien lu (et en particulier l'extrait cité), il n'aurait pas donné de réponse fausse.

[lodan]

Je reviens parce que vous me faite penser à quelque chose en parlant d'ajax.

Certe dans mon cas, je n'ai pas de donnée à aller chercher sur le serveur puisque j'ai déjà tout sur mon formulaire. Mais comme je l'ai dit précédemment, je préfère le PHP que je connais un peu, au javascript avec lequel je ne fais que bricoler.

Si j'utilise PHP, je reviens donc vers le serveur lorsque l'utilisateur clique sur une entête de colonne.

Sur mon serveur, j'ai plutôt intérêt à relire ma base avec un ordre by la colonne choisi ou de faire un tri PHP ?

[gloubi]

1.000.000 de fois le ORDER BY (et non pas ordre by)

[lodan]

C'est juste une faute de frappe, rien de bien dramatique, cela ne vaut pas 1 000 000 de fois.

Par contre order by ou tri php là est réeelement la question

[Mr N.]

gloubi à raison, le order by est nettement préferable à un tri php.
Tout ce que tu peux déléguer à ton sgbd est ça de gagné pour les performances.

[Sékiltoyai]

Oh, je disais ça pour répondre au post de Sékiltoyai.

J'ai cité ton post pour bien illustrer le fait qu'on ne s'est pas étendu sur le cas AJAX parce justement, on est pas "dans le cas où", et non pas parce qu'on y a pas pensé. La citation illustrait juste ma 1er phrase : "le problème AJAX a déjà été éfleuré".

AJAX est inadapté ici, et je vois bien que ça ne t'as pas échapé. Simplement, si Sékiltoyai avais bien lu (et en particulier l'extrait cité), il n'aurait pas donné de réponse fausse.

Je ne parlais pas d'AJAX pour rien, car quitte à aller rechercher les données, autant n'aller rechercher QUE les données, auxquelles a été appliqué le tri, et alléger ainsi le chargement de la page...
Après, je suis conscient que c'est compliqué à coder et à mettre en place, mais je persiste à dire que, même si certains n'ont pas envie d'entendre parler de ce genre de solutions, s'il y a une chose pour lequel le javascript est très très utile, et une fois n'est pas coutume, allège la navigation plutôt que de l'allourdir, c'est bien l'AJAX...

Ensuite, sur le fait de faire travailler le serveur SQL plutôt que le script, disons que ca se discute, car autant il est vrai que les serveurs SQL sont plutôt rapides (mise en cache des requètes, index, diverses optimisations), autant quand on fait tout passer par lui, il faut peut être penser au fait que plus il y a de requètes, plus celles ci sont longues à être éxécutées, et plus aussi il y a d'accès au disque dur. Donc, dans ce cas, les tris php avec un petit sort(), qui par ailleurs est écrit en C donc relativement rapide, sont quelquefois à envisager...

[lodan]

Si c'est le sgbd qui est le plus rapide et compte tenu de l'environnement, je vais creuser du côté d'ajax.

Merci pour la continuité du post.

[Sékiltoyai]

Si c'est le sgbd qui est le plus rapide et compte tenu de l'environnement, je vais creuser du côté d'ajax.

Merci pour la continuité du post.

Bah les deux n'ont pas grand chose à voir :
-Soit tu fais un tri en JS, et tu n'as besoin que d'un code js.
-Soit tu traites le tri du côté du serveur, et là, tu as 2 questions qui se posent à toi, qui sont :
> Le traitement du tri, par le SGBD ou bien par php ?
> Le transfert de données, par rechargement de la page ou bien par AJAX ?
Les deux questions étant parfaitement isolées...