Je n'arrête pas d'entendre ces mots ' rappel et postback ".
Quelle est la différence entre deux ?
Le postback est-il très spécifique aux pages ASP.NET ?
Un postback se produit lorsque les données (l'ensemble de la page) de la page sont envoyées du client vers le serveur, c'est-à-dire que l'utilisateur a besoin d'un postback. les données sont renvoyées au serveur et ainsi la page est rafraîchie (redessinée)... pensez à cela comme ' envoyer au serveur la page entière (asp.net) pleine de données '.
D'un autre côté, un callback est aussi un type particulier de postback mais il ne s'agit que d'un aller-retour rapide vers le serveur pour obtenir un petit ensemble de données (normalement), et la page n'est donc pas rafraîchie, contrairement à ce qui se passe avec le postback... considérez cela comme ' appeler le serveur, et recevoir un peu de retour des données '.
Avec Asp.Net, le ViewState n'est pas rafraîchi lorsqu'un callback est invoqué contrairement à un postback.
La raison pour laquelle la page entière est affichée avec ASP.Net est qu'ASP.Net enferme la page entière dans un fichier de type <form> avec un méthode de poste Ainsi, lorsqu'on clique sur un bouton d'envoi dans la page, le formulaire est envoyé au serveur avec tous les champs qu'il contient... en fait, toute la page elle-même.
Si vous utilisez FireBug (pour Firefox), vous pouvez en fait voir les rappels invoqués au serveur dans le champ Console . De cette façon, vous verrez ce que données spécifiques est envoyé au serveur ( Request ) et aussi les données que le serveur vous a renvoyées ( Response ).
L'image ci-dessous illustre les cycles de vie des pages d'un postback et d'un callback dans un site Web basé sur ASP.NET :
(source : <a href="http://edndoc.esri.com/arcobjects/9.2/NET_Server_Doc/developer/ADF/graphics%5Cpage_lifecycle.png" rel="noreferrer">esri.com </a>)
En fait, un rappel est un terme de programmation plus général désignant une fonction qui doit être exécutée après l'achèvement d'une autre fonction.
C'est lorsqu'un pointeur vers une fonction est passé à une autre fonction, qui l'invoquera plus tard
Un postback se produit lorsqu'une demande est envoyée du client au serveur pour la même page que celle que l'utilisateur est en train de consulter. Lorsqu'un postback se produit, la page entière est rafraîchie et vous pouvez voir la progression typique sur la barre de progression au bas du navigateur.
Un callback, généralement utilisé avec AJAX, se produit lorsqu'une requête est envoyée du client au serveur pour laquelle la page n'est pas rafraîchie, seule une partie de celle-ci est mise à jour sans qu'aucun scintillement ne se produise sur le navigateur.
Une grande partie de cette discussion est un langage de charabia ASP.NET....
La réponse est OUI. Postback est un "terme" spécifique à ASP.NET de Microsoft. Mais n'oubliez pas que les fournisseurs comme Microsoft enveloppent leurs PROPRES versions de ces processus autour de leurs propres implémentations, ce qui nous rend tous confus quant à ce qui se passe VRAIMENT dans le monde Http/Html.
Leur version de POSTBACK est essentiellement une demande HTTP POST traditionnelle renvoyée au serveur d'origine. Mais dans ASP.NET, ils le font en collant une gigantesque balise HTML FORM (avec un attribut de méthode POST) autour de la page Web entière plutôt que des contrôles de formulaire traditionnels dans une partie minuscule d'une page Web. Ils le font parce qu'ils utilisent la spécification HTTP pour maintenir l'"état" de leur page et de ses contrôles, et pour s'assurer que la page entière, même le balisage traditionnel des champs non formels, revienne intacte.
Malheureusement, cela envoie une quantité ÉNORME de données inutiles sur le fil, de sorte que leur VIEWSTATE et sa sœur POSTBACK dans la page ont fini par être considérés par beaucoup comme un gaspillage de bande passante et une façon peu soignée de mettre en œuvre l'état de la page Web. Je peux vous montrer que la plupart des navigateurs et des sites web modernes, s'ils sont conçus en utilisant des feuilles de style en cascade (CSS) pouvant être mises en cache et un balisage HTML cohérent, renverront l'état de la page de manière tout à fait naturelle en utilisant le cache HTML natif du navigateur.
CALLBACK n'est que du JavaScript. Ce sont juste des trucs de cirque ECMASCRIPT que ASP.NET stocke dans ce qu'ils appellent leur API AJAX dans de gigantesques bibliothèques JavaScript que votre navigateur télécharge depuis le serveur, et que les développeurs ASP.NET intègrent sans le savoir dans leurs pages web pour déclencher des changements dans une page web sans POSTBACK complet. L'API ASP.NET pour AJAX crée simplement tout ce Javascript massif qui se trouve du côté client et qui est déclenché dans le navigateur lorsque l'utilisateur modifie quelque chose, passe sur quelque chose ou clique sur quelque chose dans le navigateur, déclenchant ainsi des événements JavaScript traditionnels du DOM du navigateur, qui renvoient ensuite une charge géante de JSON ou d'autres données au serveur pour qu'il les traite. Ces données sont ensuite renvoyées et acceptées par les bibliothèques et objets Javascipted en mémoire dans le navigateur, et modifient certaines parties de la page Web et du balisage de l'utilisateur.
On dit qu'environ 5 à 10 % des utilisateurs et des navigateurs ont désactivé le Javascript, de sorte que tous ces JSON et AJAX se planteraient et brûleraient pour ces personnes, c'est-à-dire que le CALLBACK ne fonctionnerait pas.
C'est ce qui se passe dans les coulisses. Une grande partie est exagérée, si vous voulez mon avis. Et c'est pourquoi les modèles de contrôle Web dans ASP.NET ont été critiqués dans le passé.
Si vous abandonniez ASP.NET pour une seconde, vous pourriez écrire vous-même un simple champ FORM dans une page Web HTML avec une simple zone de texte et un bouton, appuyer dessus et le regarder envoyer un message au serveur, exactement comme le ferait une page ASP.NET, mais plus rapidement et plus simplement. C'est ce qu'est le véritable POSTBACK. Le navigateur envoie naturellement au serveur l'en-tête HTTP POST nécessaire pour le faire, mais il met en cache le HTML dans le reste de la page, de sorte qu'il s'affiche rapidement tout seul.
Pour le CALLBACK, vous pourriez simplement ajouter un simple code Javascript/ECMAScript à cette même page HTML où, lorsque l'utilisateur passe sur un texte ou un bouton, clique ou modifie un champ de formulaire, la page Web n'envoie pas de POST, mais dans les coulisses, Javascript envoie quelque chose au serveur. La façon dont vous gérez cela via votre propre JavaScript, JSON ou des bibliothèques est une autre affaire. Mais ce n'est pas magique. Pour les personnes qui n'ont pas de Javascipt ou dont le Javascript est désactivé, vous devriez concevoir des pages sans CALLBACK et mettre en cache tous les changements qui reviennent lorsque les contrôles des champs de formulaire ou les hyperliens sont cliqués. C'est une raison de reconsidérer les routines de rappel, bien que la plupart des agents utilisateurs modernes soient maintenant configurés pour les routines de sites Web ECMAScripts.
C'est ce qui rend les gens confus : ....... Ces implémentations de fournisseurs de requêtes HTTP très basiques et les astuces de Javascripts se superposent à un langage qui n'est pas clair. Cela amène ensuite les gens à construire des applications web monstrueuses qui font toutes ces choses inutiles qu'un codage très simple pourrait résoudre.
J'utilise et recommande toujours ASP.NET. Il a parcouru un long chemin et c'est un excellent système. Mais il serait utile que plus de gens comprennent les bases de ce qu'ils font avant de les utiliser, car ces frameworks peuvent être personnalisés et simplifiés pour les améliorer si vous voyez ce qui se passe vraiment sous le capot.
Je suis d'accord avec la réponse de Dreas, mais j'aimerais ajouter quelques points. Postback est un terme qui a été introduit très récemment par la programmation ASP.NET comme l'a expliqué Dreas, alors que callback est plus générique et a été utilisé bien avant que le développement web n'existe. En fait, j'ai entendu parler de callback pour la première fois à l'époque où j'ai commencé à programmer en C (peut-être que le terme existait avant, je ne sais pas) et cela signifie simplement un pointeur vers une fonction et ce pointeur vers une fonction (nommée A) est transmis à une autre fonction (nommée B) qui invoquera A plus tard. Gestionnaire de connexion Yahoo UI et d'autres cadres Ajax, mais je crois que le terme a été utilisé pour la première fois à l'époque du C.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
