Discussion :

[ma5t3r]

Bonjour à tous,

Je suis confronté à un problème de fluidité dans mon IHM sur une application PHP.
Je fais des appels ajax et je me demande s'il n'y a pas une autre façon de procéder pour récupérer les données plus dynamiquement.

La fonction (côté serveur) PHP qui traite l'information met un certain temps pour retourner la totalité des données demandées (plusieurs centaines d'objets en fait, plusieurs milliers des fois).
Ca fonctionne correctement mais je me demande s'il est possible de renvoyer les informations une à une afin de ne pas "figer" (img loader) ma page PHP et laisser la main au client.

J'affiche un loader (qui peut durer plusieurs secondes (de 10 à 30 env)) mais j'aimerais pouvoir insérer les données retournées une à une dans ma page et ainsi ne pas bloquer l'utilisateur.

Est-ce qu'il y aurait une façon de faire pour que mon jQuery récupère les informations une à une afin de les intégrer dans le DOM ?

Merci de vos suggestions.

[psychadelic]

ben, faut simplement morceler la quantité d'information par appels successifs, c'est d'ailleurs la base en architecture n-tiers.

ca veux dire que par exemple pour une qte de 100,
ton premier appel ajax en demande les 20 premiers,
puis un second appel demande les 20 suivants,
etc , jusqu’à épuisement
au niveau php c'est pas trop complique,
mais au niveau JQuery c'est un peu plus subtil et faut pas se mélanger, car ç’a devient une boucle d'appels asynchrones,
alors cela demande une gestion par promesses, ou alors il y a l'astuce de passer par la fonction setTimeout, mais c'est pas forcément fiable.

[ma5t3r]

Merci psychadelic,

je comprends bien ce que tu dis mais rien ne me force à ne présenter que 20 ou 30 ou 1000 informations sur ma page.
Je ne veux pas d'un système de "pagination".

Il existe un objet XMLHttpRequestUpload que j'utilise pour l'upload de fichiers, le système me permet de modifier une barre de progression en temps réel dans mon IHM.
C'est un objet JS qui ne me permet pas de gérer un autre flux que le transfert de fichier.

Il doit bien exister un objet qui permette de faire la même chose pour un flux json.

Un truc qui me permettrait de faire un boucle du style

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
while ...
   echo json_encode($objet);
...end while

qui je puisse lire avec mon JS

D'ailleurs, je n'ai jamais testé cette façon de faire, si ça se trouve, ça peut marcher

[psychadelic]

Non, tu n'a pas compris ce que je t'ai proposé, cela n'a rien à voir avec un système de pagination.

Je ne connaiss pas cette fct XMLHttpRequestUpload qui fait peut_être un job identique à ce que je te proposais.

Mais ce que je te proposais c'est d'afficher les données 20 par 20 jusqu’à épuisement, en te permetant aussi de mettre une barre de progression tant que la totalité ne soit chargée.

Et qui n'a vraiment rien a voir avec une pagination puisque les requettes par "20 elements" sont envoyées les unes à la suite des autres quand la précédente est faite, et c'est pour cette raison que je t'ai parlé des promesses en javascript https://developer.mozilla.org/en-US/...bjects/Promise
et qui seules* permettent de pouvoir synchroniser les appels successifs et éviter qu'ils ne se chevauchent en rajoutant en concurrence les donnés à afficher.

* =>(sauf avec l'astuce de l'utilisation d'un setTimeout, mais qui n'est pas forcément fiable comme je l'ai écrit avant)

? quand je parle d'appels asynchrone, est-ce que tu en connais les principes ?

[ma5t3r]

Des promesses, toujours des promesses !!

Je ne connaissais pas, je vais regarder de ce côté, merci pour le lien.
Désolé, je n'avais pas bien compris les explications dans ta réponse.

Oui, je connais les principes de l'asynchronicité, je ne pourrais pas en faire un cours mais je sais pourquoi et comment utiliser AJAJ, oops AJAX.

[psychadelic]

Je pense pas que la fonction XMLHttpRequestUpload puisse être utile pour ce que tu veux faire, parce que tes données sont envoyé par un appel php, et que php c'est tout sauf un langage paremettant de gérer des appels asynchrone.
Si en plus le php fait une requette sur un server SQL, ont est encore plus en Synchrone Only : le php ne peut répondre que lorsque la totalité des données qu'il a demandé par sa requête SQL est achevée.

Ce qui te ramène obligatoirement à morceler les appels PHP, et donc à ma solution.

[ma5t3r]

Je dirais même que je suis sûr que l'objet XMLHttpRequestUpload ne me servirait à rien.
C'était juste pour démontrer l'existence d'un objet qui encapsule un mécanisme qui correspond à ce que je recherchais.

Bah oui, tu avais raison. Merci.
Je vais orienter mes recherches de ce côté là.

Comme je bosse seul, je n'ai plus trop l'occasion de discuter le bout de gras avec d'autres développeurs. A part developpez.net mais c'est pas pareil, l'interactivité que procure une vraie discussion s'en trouve quelque peu diminuée.
Je vais réussir à mettre ce truc en place. Ca fait 25 ans que je code, je n'ai jamais été bloqué au point d'abandonner un projet ou une fonctionnalité à cause d'un manque de solutions.

Merci de ton aide.

Je ne considère pas encore ce sujet comme résolu. Je reviendrai y mettre une réponse définitive le cas échéant pour ceux qui pourraient être interessés.

Merci encore de ton orientation.

Des promesses, toujours des promesses !

[psychadelic]

Moi aussi je suis un loup solitaire...

J'ai commencé à me servir des promesses pour gérer l’enchaînement, le parallélisme, etc... d' animations pour des transitions de parties de page sur un site one page.

Le async et await n'étant pas toujours présent, il y a quelqes ruses à connaitre, surtout pour gérer une récursivité.

Je dois avoir des bout de code pour de tests ; quelque part