Zend FR

Logiquement les fonctions ob_.... et flush sont là pour ca, je cherche encore, pour le moment j'ai rien de génial

Je confond avec flush qui permet de forcer l'envoie du contenu du buffer au navigateur : http://www.manuelphp.com/php/function.flush.php

Cependant je me demande si mon souci (flush() ne fonctionne pas chez moi) ne viens pas du fait que le serveur web est sous windows...

Si je fais ca :

public function preDispatch(Zend_Controller_Request_Abstract $request){
    echo "Debut loading";flush();
}

j'ai bien la sortie avant le rendu final de la vue, par contre je comptais utiliser postDispatch pour cacher le fameux div mais postDispatch est executé bien avant le rendu final, en fait il est executé juste après preDispatch.

Il me faudrait trouver une méthode du controleur principal de Zend qui serait executée le plus tard possible pour ne pas que le message soit effacé trop tot.

Pour ta méthode de listeners sur les liens, c'est trop lourd à mettre en place sur mon projet je ne peux pas.

TiTerm a écrit:

Flush fonctionne même sous windows...

La doc PHP dit que sous Windows ca merde souvent...

Dernière modification par vallica (22-02-2008 13:56:48)

je verrai a la rigueur une fonction JS qui au (onload / debut de ton body) lance affiche ton div, et le masque en fin de page, c'est de l'interactif, je ne vois pas en quoi PHP peut t'aider pour cela.

Ca pourrait t'aider à comprendre un peu mieux le déroulement du MVC avec le zf...

Bonjour,

Une solution barbare que j'utilise souvent quand je sais qu'une page risque de prendre du temps à s'afficher.

J'appelle une page ou il n'y a aucun traitement, juste une page en fait qui dis de patienter. Dans cette page je fais un ob_start() et un ob_flush() et tout de suite apres mon ob_flush, je fais un header('Location:ma-page-longue.php') avec pareil, un ob_start et un ob_flush() a la fin. Du coup, pendant que mon fichier ma-page-longue.php réfléchi, la page pour patienter reste à l'écran.

C'est un peu bourrin mais ca a toujours marché

C'est difficile, en fait tout est contenu dans l'objet de réponse.
L'objet de réponse est un conteneur d'en-tête et de corps, il est vidé à la fin du processus MVC par le FrontController (par défaut), de manière à s'assurer que justement, les en-têtes comme le corps de la réponse (complète) soient rendus en une seule passe, ce qui optimise les échanges entre les buffers PHP <-> Apache <-> TCP.

Si tu echo à un moment, tu risque de troubler la réponse qui ne pourra plus se rendre car les en-têtes auront déja été envoyés. Et si c'est après le dispatching, alors les buffers vont capturer ce echo.

La demi-solution consisterait à passer par 2 dispatching, un premier light avec un message please wait envoyé, et le lourd après, mais en espérant que le lourd ne génère pas d'en-têtes (ce qui n'est pas sûr du tout), sinon ca va foirer.

Il n'existe pas vraiment de solution viable dans 100% des cas, sans avoir un client actif (AJAX).
C'est le protocole HTTP qui repose sur ce principe : une fois qu'on envoie un corps de réponse, alors les en-têtes de celle-ci sont envoyés et ne peuvent plus être régénérés.

Tu peux passer par des codes 3xx (comme un Location qui génère un 302 par défaut), mais ca n'est sémantiquement pas correct, ça voudrait dire que chaque page a changé d'adresse, les moteurs de recherche risquent de ne pas apprécier.