drag&drop: enregistrement/exploitation

17 réponses

Auteur	Message
tony \| Membre Inscrit le : 20/02/2006	# Le 10/01/2008 à 23:59 Bonjour à tous, Ma question ne concerne pas la création d'un drag and drop en javascript, ça c'est ok mais de la meilleure façon d'enregistrer les données dans une table sql et de les exploiter par la suite. J'aimerais bien avoir des retours d'expériences sur la meilleure façon (point de vu pratique, logique et optimisation) à adopter pour traiter en php/sql le resultat d'un drag and drop dans le cas où un utilisateur peut gerer le contenu des éléments d'un menu (en modifiant l'ordre et en ajoutant/supprimant des modules). En esperant avoir été suffisament clair, je vous remercie de l'aide précieuse que vous m'apporterez Tony
zimounet \| Quentin Membre Inscrit le : 22/03/2006	# Le 11/01/2008 à 12:30 je te suggère, si ce n'est pas déjà fait, de te pencher sur des "surcouches" (framework) JS tel que Jquery... Ou encore la lib extJS (qui fonctionne avec jquery, prototype, yahoo UI...) Tu gagnera tu temps, de l'argent et de la performance. Ah, c'est balot madame Chombier!
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 11/01/2008 à 13:07 Zim > je crois que ce n'était pas l'objet de la question. Tony > tout dépend des élements que tu tries. J'aurais tendance à dire qu'un champ 'ordre' suffit. Ce que j'ai fais dernièrement pour un simple tri d'éléments déjà connus, ayant chacun un ID propre : * Je stocke l'ordre de départ dans un array() serialisé * Je stocke l'ordre de fin dans un autre array() que je serialise * J'envoi tout ça à un script PHP en Ajax * Je boucle sur le nouvel array et regarde si la clef courante existait et avait la même valeur dans l'ancien array(), si ce n'est pas le cas, je change la valeur de l'ordre en SQL, sinon je ne touche a rien car ça veut dire que ce tri n'a pas été impacté. * Au final j'économis des centaines de requetes. $old_list = array_keys($old_ser); $new_list = array_keys($new_ser); for ($i=0; $i < sizeof($old_list); $i++) { // if list at current position is different that the old one, update ! if ($old_lists[$i] != $new_lists[$i]) { set_position($new_lists[$i]), ($i+1)); } } Shopping Time Network - Founder / CTO
tony \| Tony Membre Inscrit le : 20/02/2006	# Le 11/01/2008 à 15:15 Ca fait plaisir d'avoir de tes nouvelles Julien ;) Ce que tu me proposes, si je comprend bien c'est comment enregistrer à chaque action sur le menu en drag and drop. Ca ok, je comptais pas le fair en ajax mais avec un bouton submit à la fin des modifs. Ensuite, tu enregistres comment l'ordre dans ton champ ordre ? Genre avec un séparateur ? 4\|2\|1\|3 ? Enfin, la partie dans laquelle je suis plus dans le flou c'est comment exploiter le resultat pour afficher dans l'ordre les éléments différents de maniere optimisé. Peut être que le plus simple finalement est à partir de mon champ "ordre" formatté avec un separateur je fasse un explode puis une boucle dans l'ordre pour afficher les éléménts ? Tony
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 11/01/2008 à 15:55 Hello, d'après ce que j'ai compris du post de Julgates (et je fais de meme, sans l'Ajax) : le champ "ordre" est une colonne dans la base de données, chaque élément a donc un "numero de position", et il te suffit d'ajouter un "ORDER BY position" dans la requete SQL de récupération des données. daevel : infogérance et conseil \|\| moi
tony \| Tony Membre Inscrit le : 20/02/2006	# Le 11/01/2008 à 16:04 Hmmm mais s'il y a beaucoup de champs et beaucoup d'utilisateurs ca va faire un max d'enregistrements. La méthode que j'expose n'est elle pas plus optimisée? Tony
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 11/01/2008 à 16:58 béh à moins que j'ai mal compris le problème de départ, cela n'ajoute qu'un seul champ... pour chaque entrée dans ta table. Et de manière générale, le "ORDER BY" coté SQL est beaucoup plus rapide qu'un éventuel "tri" à la sauce PHP. daevel : infogérance et conseil \|\| moi
Julgates \| Julien Administrateur Inscrit le : 09/03/2005	# Le 11/01/2008 à 17:12 Tony > on s'appelle quand tu veux, mais c'est moi qui part au ski demain ;-) pour le champ tu le met à hauteur de ton élément et non pas de ton conteneur. Exemple si tes éléments sont des billets de blog, pour chaque billet tu as le champ 'ordre' qui vaudra de 1 à X. ensuite, comme le dit Bool, un simple ORDER BY te suffit à l'affichage. Pour le passer en Ajax tu peux utiliser du JSON, c'est sympa et natif en PHP maintenant (json_decode). Ajax ou _POST classique, ça marchera tout pareil ;-) D'ailleurs je le fais en AJAX après clic sur un bouton submit Shopping Time Network - Founder / CTO
tony \| Tony Membre Inscrit le : 20/02/2006	# Le 11/01/2008 à 17:40 Julgates > JSON ca à l'air pas mal, mais je suis encore en php4. Bon ski ! Bool a dit : béh à moins que j'ai mal compris le problème de départ, cela n'ajoute qu'un seul champ... pour chaque entrée dans ta table. Et de manière générale, le "ORDER BY" coté SQL est beaucoup plus rapide qu'un éventuel "tri" à la sauce PHP. En fait les éléments ne sont pas spécifiques à l'utilisateur, ce sont des modules qu'ils peuvent ajouter ou non, donc impossible de fonctionner comme cela, à moins de créer un enregistrement par module ce qui serait plutot inutile. J'utilise déjà la méthode du ORDER BY pour classer les rubriques/catégories qu'ils créé eux mêmes et qu'ils classent en drag and drop. (Message édité le 11-01-2008 à 17h57 par tony) Tony
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 11/01/2008 à 18:26 Je ne comprends toujours pas où est le soucis : je suppose que tu as déjà une table faisant le lien entre tes "utilisateurs" et tes "modules", et qui a donc seulement deux champs : id_utilisateur et id_module. Et ici, il te suffit d'ajouter le fameux champ qui te servira dans le "order by". Qu'est ce qui ne colle pas dans cet exemple ? Surtout que visiblement tu utilises déjà la même chose pour des rubriques et catégories non ? daevel : infogérance et conseil \|\| moi
tony \| Tony Membre Inscrit le : 20/02/2006	# Le 11/01/2008 à 23:28 Ce n'est pour l'instant qu'une réflexion. En fait, je veux permettre aux utilisateurs d'integrer des modules qui sont dans une table. Ils sont communs pour tous. Donc, je ne peux pas mettre un champ ordre dans cette table. Il y aura par exemple 10 modules dans cette table qu'ils pourront ajouter dans leur menu. Le but c'est qu'ils puissent les intégrer dans l'ordre qu'ils souhaitent. La seule solution est donc selon moi dans une autre table d'avoir le login dans un champ et l'ordre des id de la table modules avec des séparateurs. Mais je ne sais pas comment intégrer en plus les rubriques/catégories qui sont elles régies via un ordre et traités en ORDER BY. Tony
Zalex14 \| Alexandre Modérateur Inscrit le : 09/05/2005	# Le 11/01/2008 à 23:40 bah dans une autre table Moi non plus je ne vois pas le problème. A la louche il te faut : user user_modules (pour savoir savoir quels modules sont sélectionnés pour chaque user) user_modules_categorieOrder (pour joindre à chaque modules d'un user l'ordre des catégories) et à coté une table modules et une table modules_categories pour les libellés. Pour obtenir les modules et l'ordre des catégories d'un user : user->user_modules->user_modules_categorieOrder order by id_module asc, categorieOrder asc enfin, un truc du style. A moins que j'ai pas compris ta demande. Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.
tony \| Tony Membre Inscrit le : 20/02/2006	# Le 12/01/2008 à 12:50 Ce que je cherche c'est justement à ne pas avoir à créer un enregistrement pour chaque module qu'utilise un utilisateur (ta table "user_modules") ! Merci en tout cas pour ces réponses. Tony
zimounet \| Quentin Membre Inscrit le : 22/03/2006	# Le 12/01/2008 à 13:44 Ne sous estime pas Mysql... Apres, tu peux tenter, ce que tu as proposé... un champ avec iduser un autre avec ordre et qqchose du gere: 1@2@9@4 Pour l'ordre... un p'tit split et un traitement php... Mais bon apres tu enleve toute logique de structuration des données, et tu te coupe de certaines possibilitées d'évolution. Ah, c'est balot madame Chombier!
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 12/01/2008 à 19:28 Même idée que Zalex, fait une table avec l'id de tes modules, l'id de ton user, et l'ordre ... Une requete simpliste avec une jointure (pour relier tes modules à l'id du module), et un petit WHERE idUser=X ORDER BY ordre. En terme de maintenance et de structure, c'est nettement mieux qu'un explode/split. A toi de faire ton choix ;)
tony \| Tony Membre Inscrit le : 20/02/2006	# Le 12/01/2008 à 23:16 Je voulais éviter de trop surcharger sql mais je crois que je vais procéder comme cela oui. De toute façon tout sera en cache. Tony
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 13/01/2008 à 00:57 Une base de données c'est fait pour gèrer les données, les classer, les rapprocher, les trier ; et ça fait son boulot terriblement bien. Comme dit au dessus, ne sous estime pas MySQL, qui fera certainement cela beaucoup plus vite que PHP ; et ton serveur en sera certainement moins chargé (mais ça n'empêche évidement pas d'utiliser un cache de données). daevel : infogérance et conseil \|\| moi
tonguide \| Jeremy Modérateur Inscrit le : 09/05/2005	# Le 13/01/2008 à 13:21 Si vraiment ça te dérange, tu mets toutes les configurations du site en cache (j'imagine que c'est pour e-monsite). Tu peux utiliser un serialize par exemple, ça demande d'etre mis à jour régulièrement, donc tu peux faire ça pour les gros points de présentation (module/menu/couleur etc.) en gros, ce qui bouge que rarement. Comme ça, tu as tes tables pour faciliter les modifications (une structure plus clean) et ensuite, une table contenant un résumé des données serialisé. Donc tu ne devras faire qu'une requete SQL et un unserialize pour avoir la totalité des configs de ton blog. Tu fais un petit bench des deux, et tu vois celui qui est le moins gourmand (si tu as 50 configs, ça peut valoir le coup, si tu as 2/3 configs ça sert peut-etre pas à grand chose).

Auteur

Message

Inscrit le : 20/02/2006

# Le 10/01/2008 à 23:59

Bonjour à tous,

Ma question ne concerne pas la création d'un drag and drop en javascript, ça c'est ok mais de la meilleure façon d'enregistrer les données dans une table sql et de les exploiter par la suite.

J'aimerais bien avoir des retours d'expériences sur la meilleure façon (point de vu pratique, logique et optimisation) à adopter pour traiter en php/sql le resultat d'un drag and drop dans le cas où un utilisateur peut gerer le contenu des éléments d'un menu (en modifiant l'ordre et en ajoutant/supprimant des modules).

En esperant avoir été suffisament clair, je vous remercie de l'aide précieuse que vous m'apporterez

Tony

zimounet | Quentin
Membre

Inscrit le : 22/03/2006

# Le 11/01/2008 à 12:30

je te suggère, si ce n'est pas déjà fait, de te pencher sur des "surcouches" (framework) JS tel que Jquery...

Ou encore la lib extJS (qui fonctionne avec jquery, prototype, yahoo UI...)

Tu gagnera tu temps, de l'argent et de la performance.

Ah, c'est balot madame Chombier!

Julgates | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 11/01/2008 à 13:07

Zim > je crois que ce n'était pas l'objet de la question.

Tony > tout dépend des élements que tu tries.

J'aurais tendance à dire qu'un champ 'ordre' suffit.

Ce que j'ai fais dernièrement pour un simple tri d'éléments déjà connus, ayant chacun un ID propre :

* Je stocke l'ordre de départ dans un array() serialisé
* Je stocke l'ordre de fin dans un autre array() que je serialise
* J'envoi tout ça à un script PHP en Ajax
* Je boucle sur le nouvel array et regarde si la clef courante existait et avait la même valeur dans l'ancien array(), si ce n'est pas le cas, je change la valeur de l'ordre en SQL, sinon je ne touche a rien car ça veut dire que ce tri n'a pas été impacté.
* Au final j'économis des centaines de requetes.





  $old_list = array_keys($old_ser);

  $new_list = array_keys($new_ser);

  for ($i=0; $i < sizeof($old_list); $i++) {

    // if list at current position is different that the old one, update !

    if ($old_lists[$i] != $new_lists[$i]) {

      set_position($new_lists[$i]), ($i+1));

    }

  }

Shopping Time Network - Founder / CTO

tony | Tony
Membre

Inscrit le : 20/02/2006

# Le 11/01/2008 à 15:15

Ca fait plaisir d'avoir de tes nouvelles Julien ;)

Ce que tu me proposes, si je comprend bien c'est comment enregistrer à chaque action sur le menu en drag and drop. Ca ok, je comptais pas le fair en ajax mais avec un bouton submit à la fin des modifs.

Ensuite, tu enregistres comment l'ordre dans ton champ ordre ? Genre avec un séparateur ? 4|2|1|3 ?

Enfin, la partie dans laquelle je suis plus dans le flou c'est comment exploiter le resultat pour afficher dans l'ordre les éléments différents de maniere optimisé.

Peut être que le plus simple finalement est à partir de mon champ "ordre" formatté avec un separateur je fasse un explode puis une boucle dans l'ordre pour afficher les éléménts ?

Tony

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 11/01/2008 à 15:55

Hello,

d'après ce que j'ai compris du post de Julgates (et je fais de meme, sans l'Ajax) : le champ "ordre" est une colonne dans la base de données, chaque élément a donc un "numero de position", et il te suffit d'ajouter un "ORDER BY position" dans la requete SQL de récupération des données.

daevel : infogérance et conseil || moi

tony | Tony
Membre

Inscrit le : 20/02/2006

# Le 11/01/2008 à 16:04

Hmmm mais s'il y a beaucoup de champs et beaucoup d'utilisateurs ca va faire un max d'enregistrements. La méthode que j'expose n'est elle pas plus optimisée?

Tony

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 11/01/2008 à 16:58

béh à moins que j'ai mal compris le problème de départ, cela n'ajoute qu'un seul champ... pour chaque entrée dans ta table.

Et de manière générale, le "ORDER BY" coté SQL est beaucoup plus rapide qu'un éventuel "tri" à la sauce PHP.

daevel : infogérance et conseil || moi

Julgates | Julien
Administrateur

Inscrit le : 09/03/2005

# Le 11/01/2008 à 17:12

Tony > on s'appelle quand tu veux, mais c'est moi qui part au ski demain ;-)

pour le champ tu le met à hauteur de ton élément et non pas de ton conteneur.

Exemple si tes éléments sont des billets de blog, pour chaque billet tu as le champ 'ordre' qui vaudra de 1 à X.

ensuite, comme le dit Bool, un simple ORDER BY te suffit à l'affichage.

Pour le passer en Ajax tu peux utiliser du JSON, c'est sympa et natif en PHP maintenant (json_decode).

Ajax ou _POST classique, ça marchera tout pareil ;-)

D'ailleurs je le fais en AJAX après clic sur un bouton submit

Shopping Time Network - Founder / CTO

tony | Tony
Membre

Inscrit le : 20/02/2006

# Le 11/01/2008 à 17:40

Julgates > JSON ca à l'air pas mal, mais je suis encore en php4.
Bon ski !

Bool a dit :
béh à moins que j'ai mal compris le problème de départ, cela n'ajoute qu'un seul champ... pour chaque entrée dans ta table.

Et de manière générale, le "ORDER BY" coté SQL est beaucoup plus rapide qu'un éventuel "tri" à la sauce PHP.

En fait les éléments ne sont pas spécifiques à l'utilisateur, ce sont des modules qu'ils peuvent ajouter ou non, donc impossible de fonctionner comme cela, à moins de créer un enregistrement par module ce qui serait plutot inutile.

J'utilise déjà la méthode du ORDER BY pour classer les rubriques/catégories qu'ils créé eux mêmes et qu'ils classent en drag and drop.

(Message édité le 11-01-2008 à 17h57 par tony)

Tony

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 11/01/2008 à 18:26

Je ne comprends toujours pas où est le soucis : je suppose que tu as déjà une table faisant le lien entre tes "utilisateurs" et tes "modules", et qui a donc seulement deux champs : id_utilisateur et id_module. Et ici, il te suffit d'ajouter le fameux champ qui te servira dans le "order by".

Qu'est ce qui ne colle pas dans cet exemple ? Surtout que visiblement tu utilises déjà la même chose pour des rubriques et catégories non ?

daevel : infogérance et conseil || moi

tony | Tony
Membre

Inscrit le : 20/02/2006

# Le 11/01/2008 à 23:28

Ce n'est pour l'instant qu'une réflexion.
En fait, je veux permettre aux utilisateurs d'integrer des modules qui sont dans une table. Ils sont communs pour tous. Donc, je ne peux pas mettre un champ ordre dans cette table.
Il y aura par exemple 10 modules dans cette table qu'ils pourront ajouter dans leur menu. Le but c'est qu'ils puissent les intégrer dans l'ordre qu'ils souhaitent.
La seule solution est donc selon moi dans une autre table d'avoir le login dans un champ et l'ordre des id de la table modules avec des séparateurs. Mais je ne sais pas comment intégrer en plus les rubriques/catégories qui sont elles régies via un ordre et traités en ORDER BY.

Tony

Zalex14 | Alexandre
Modérateur

Inscrit le : 09/05/2005

# Le 11/01/2008 à 23:40

bah dans une autre table
Moi non plus je ne vois pas le problème.

A la louche il te faut :
user
user_modules (pour savoir savoir quels modules sont sélectionnés pour chaque user)
user_modules_categorieOrder (pour joindre à chaque modules d'un user l'ordre des catégories)
et à coté une table modules et une table modules_categories pour les libellés.

Pour obtenir les modules et l'ordre des catégories d'un user : user->user_modules->user_modules_categorieOrder order by id_module asc, categorieOrder asc

enfin, un truc du style. A moins que j'ai pas compris ta demande.

Mieux vaut s'attendre au prévisible que d'être surpris par l'inattendu.

tony | Tony
Membre

Inscrit le : 20/02/2006

# Le 12/01/2008 à 12:50

Ce que je cherche c'est justement à ne pas avoir à créer un enregistrement pour chaque module qu'utilise un utilisateur (ta table "user_modules") !

Merci en tout cas pour ces réponses.

Tony

zimounet | Quentin
Membre

Inscrit le : 22/03/2006

# Le 12/01/2008 à 13:44

Ne sous estime pas Mysql...

Apres, tu peux tenter, ce que tu as proposé... un champ avec iduser un autre avec ordre et qqchose du gere: 1@2@9@4

Pour l'ordre...

un p'tit split et un traitement php...

Mais bon apres tu enleve toute logique de structuration des données, et tu te coupe de certaines possibilitées d'évolution.

Ah, c'est balot madame Chombier!

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 12/01/2008 à 19:28

Même idée que Zalex, fait une table avec l'id de tes modules, l'id de ton user, et l'ordre ...

Une requete simpliste avec une jointure (pour relier tes modules à l'id du module), et un petit WHERE idUser=X ORDER BY ordre.

En terme de maintenance et de structure, c'est nettement mieux qu'un explode/split.

A toi de faire ton choix ;)

tony | Tony
Membre

Inscrit le : 20/02/2006

# Le 12/01/2008 à 23:16

Je voulais éviter de trop surcharger sql mais je crois que je vais procéder comme cela oui. De toute façon tout sera en cache.

Tony

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 13/01/2008 à 00:57

Une base de données c'est fait pour gèrer les données, les classer, les rapprocher, les trier ; et ça fait son boulot terriblement bien.
Comme dit au dessus, ne sous estime pas MySQL, qui fera certainement cela beaucoup plus vite que PHP ; et ton serveur en sera certainement moins chargé (mais ça n'empêche évidement pas d'utiliser un cache de données).

daevel : infogérance et conseil || moi

tonguide | Jeremy
Modérateur

Inscrit le : 09/05/2005

# Le 13/01/2008 à 13:21

Si vraiment ça te dérange, tu mets toutes les configurations du site en cache (j'imagine que c'est pour e-monsite). Tu peux utiliser un serialize par exemple, ça demande d'etre mis à jour régulièrement, donc tu peux faire ça pour les gros points de présentation (module/menu/couleur etc.) en gros, ce qui bouge que rarement.

Comme ça, tu as tes tables pour faciliter les modifications (une structure plus clean) et ensuite, une table contenant un résumé des données serialisé. Donc tu ne devras faire qu'une requete SQL et un unserialize pour avoir la totalité des configs de ton blog. Tu fais un petit bench des deux, et tu vois celui qui est le moins gourmand (si tu as 50 configs, ça peut valoir le coup, si tu as 2/3 configs ça sert peut-etre pas à grand chose).

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.