Bonnes pratiques: Filtrage d'un tableau

Version imprimable

09/04/2013, 12h41
skizoplouc

Bonnes pratiques: Filtrage d'un tableau

Bonjour,

Je n'ai que très peu de connaissances en javascript/ajax/html5
J'ai repris un projet Symfony ( que je maitrise mieux ^^ ) et horreur, il y a parfois des templates contenant plus de 2000lignes de javascript
Le site est affreusement long ( parfois 1m30 à charger )

La personne s'occupant du projet a fait quelque chose que je trouve fou:
-Récupérer un tableau généré en php.
-puis filtrer celui ci en css: si la ligne contient ceci ou est égale à cela, alors display ou displya:none

Et sachant qu'il y a plusieurs filtres, il y a duplication de pleins de lignes, ce qui fait que le code est illisible et incompréhensible et fait royalement 700lignes pour 4 filtres..

Quelle est la bonne pratique ?
Moi j'aurai mis un call ajax sur un unique bouton " valider " et hop, le traitement est fait en php, moins le lignes, facile à comprendre pour le prochain dev etc..

J'ai beaucoup de mal à reprendre ce code ( et le projet contenant du JS en général.. ) et pour moi, beaucoup de choses sont à re coder..
Ou alors est ce couramment utilisé et je suis un gros nullos qui doit se reconvertir dans la maçonnerie ?
09/04/2013, 13h43
SpaceFrog

A priori le plus long c'est le chargement des lignes ... ??

pour ce qui est du flitrage en lui j'ai déja fait des tests sur de gros tableaux
cf. http://www.developpez.net/forums/d10...eurs-colonnes/

après en effet il faut voir entre un chargement global de toutes les lignes ou un simple appel ajax lequel est au final le plus avantageux ...
Si tu dois filtrer 10 ou 15 fois sur la page, il n'est pas certain qu'au global tu sois gagnant car tu devras peut être charger deux ou trois fois le total des lignes du tableau ...
09/04/2013, 13h47
SylvainPV

Le mieux serait de ne plus générer de tableau HTML avec PHP mais de générer un format de données sérialisées comme JSON. Ensuite tu pourrais générer ton tableau HTML en Javascript en appliquant directement les filtres.

L'avantage est que cela réduirait à la fois la taille de la page, donc le temps de requête, et le temps de rendu du tableau filtré.
09/04/2013, 13h49
TheGwy

C'est un peu dur de te répondre avec si peu d'informations.

Globalement je te dirais que le plus souvent tu gèrera ton filtre côté serveur.

Mais sur certains jeux de donnée plus petits (comprendre non paginés) un filtre côté client est parfaitement envisageable voir même souhaitable car plus réactif pour l'utilisateur final.

Dans tout les cas ce qui est à proscrire absolument c'est la duplication de fonctionnalité : implémenter côté serveur et côté client. Non seulement c'est du temps de dev perdu mais tu amène des risques de décohérence et augmente le coup de maintenance.

Pour ce qui est de ton cas particulier (sac de noeud de + de 2000 lignes) c'est juste très mal codé, que ce soit côté client ou serveur cela aurait été pareil. Ton prédécesseur à juste chié dans la colle avec une mauvaise conception.

Merci pour vos réponses,
C'est en effet hypothétiquement de grosses données paginées.
Sinon, je ne me plains pas vraiment du temps de chargement des lignes, c'est plutôt rapide. Mais du temps pour reprendre du code qui utilise cette méthode, du temps que mon IDE mets pour afficher des fichiers aussi gros ^^
Et je ne comprends pas pourquoi il est intéressant de faire ça, mise à part pour de toutes petites données comme vous me l'avez dit !

Deux messages s'opposent, json + traitement css ou traitement coté serveur ( + envoi en json possible..)

Un petit gros exemple:
Le tableau est affiché dans les lignes précédentes
Lorsque l'on modifie le filtre de statut d'un objet ( un dossier )

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
$("#filtre_statut").change(function() {
	var cell = $(this).val();
	if(cell == "" && $("#filtre_pays").val() == "" && $("#filtre_depart").val() == "" && $("#filtre_valide").val() == "" && $("#filtre_nom").val() == "") {
		$('.ligne').each(function() {
			$(this).css('display', 'table-row');
		});
		pagination();
	} else if(cell == "") {
		$('.ligne').each(function() {
			$(this).css('display', 'none');
		});
		if($("#filtre_pays").val() != "") {
			$('.ligne').find('.pays:contains('+$("#filtre_pays").val()+')').each(function() {
				$(this).parent().css('display', 'table-row');
			});
		}
		if($("#filtre_nom").val() != "") {
			$('.ligne:visible').find('.nom:imissing('+$("#filtre_nom").val()+')').each(function() {
				$(this).parent().css('display', 'none');
			});
		}
		if($("#filtre_depart").val() != "") {
			$('.ligne:visible').find('.depart:missing('+$("#filtre_depart").val()+')').each(function() {
				$(this).parent().css('display', 'none');
			});
		}
		if($("#filtre_valide").val() == "Oui") {
			$('.ligne:visible').each(function() {
				if($(this).attr('id') == "nvalide")
					$(this).css('display', 'none');
			});
		} else if($("#filtre_valide").val() == "Non") {
			$('.ligne:visible').each(function() {
				if($(this).attr('id') == "valide")
					$(this).css('display', 'none');
			});
		}
	} else {
		$('.ligne').each(function() {
			$(this).css('display', 'none');
		});
		$('.ligne').find('.statut:contains('+cell+')').each(function() {
			$(this).parent().css('display', 'table-row');
		});
		if($("#filtre_pays").val() != "") {
			$('.ligne:visible').find('.pays:missing('+$("#filtre_pays").val()+')').each(function() {
				$(this).parent().css('display', 'none');
			});
		}
		if($("#filtre_depart").val() != "") {
			$('.ligne:visible').find('.depart:missing('+$("#filtre_depart").val()+')').each(function() {
				$(this).parent().css('display', 'none');
			});
		}
		if($("#filtre_nom").val() != "") {
			$('.ligne:visible').find('.nom:imissing('+$("#filtre_nom").val()+')').each(function() {
				$(this).parent().css('display', 'none');
			});
		}
		if($("#filtre_valide").val() == "Oui") {
			$('.ligne:visible').each(function() {
				if($(this).attr('id') == "nvalide")
					$(this).css('display', 'none');
			});
		} else if($("#filtre_valide").val() == "Non") {
			$('.ligne:visible').each(function() {
				if($(this).attr('id') == "valide")
					$(this).css('display', 'none');
			});
		}
		$(".pager").css('display', 'none');
	}
});

Dés qu'un filtre est changé, il va vérifier les 3 ou 4 autres filtres pour refiltrer à nouveau le tableau.
Ce code contient proportionnellement plus de tests ( IF ) qu'il y a de filtres.
Et ceci pour chaque filtres !

Alors qu'un traitement coté serveur est à mon sens plus simple, plus lisible et la maintenance est vraiment plus simple, même si elle n'est pas commentée !

edit: En effet, tablesort a l'air bien fichus! Il ne manque plus que les filtres dans un panel à coté et ça serait top ! A voir..

09/04/2013, 14h45
SpaceFrog

il existe des plugin jquery pour gerer l'affichage de tableaux issus d'une BDD

jette un oeil sur datatable ou jqgrid ...
09/04/2013, 20h48
SylvainPV

Si les filtres s'appliquent sur des jeux de données très importants, effectivement aucun intérêt de les faire en JS ; ça nécessiterait de télécharger l'intégralité des données.

Par contre rien n'empêche d'envoyer les données filtrées depuis le serveur en JSON puis de générer le HTML en Javascript. La requête sera plus légère et cela te donne davantage de flexibilité au parsing.
10/04/2013, 11h44
skizoplouc

D'avantage de flexibilité au parsing ? C'est à dire ?

@SpaceFrog : Je pense en effet utiliser un de ces plug in Jquery, ça a l'air assez impressionnant :) Faut juste que je vois comment gérer les filtres sur ce tableau..
10/04/2013, 13h40
SylvainPV

Cela te donne la possibilité d'adapter le rendu de ton tableau selon des états qui ne sont connus que du client et pas du serveur: par exemple l'état d'une checkbox sur la page, ou des infos sur la taille de l'écran, etc... A toi de voir si tu y trouves une utilité.

Si tu utilises un plugin jQuery pour tes tableaux, tu as tout intérêt à également générer les tableaux en JS, pour faire les deux étapes d'un seul coup.