L'utilisation générale du callback est relativement simple. Il suffit de se référer directement à l'aide et aux exemples de msdn. Mais si vous souhaitez vraiment l'utiliser correctement et avec précision, ou si vous souhaitez développer des composants WEB basés sur le mécanisme de rappel, vous devez d'abord avoir une compréhension approfondie du mécanisme d'implémentation du rappel. Dans cet article, Teddy travaillera avec vous pour analyser l'ensemble du mécanisme d'invocation et de rétroaction du rappel. Je pense qu'il sera certainement utile de vous aider à mieux utiliser le rappel.
Callback vs Atlas
Tout d’abord, parlons d’Atlas. De nombreux amis peuvent trouver étrange qu'il y ait déjà Callback, pourquoi avons-nous besoin de publier à nouveau Atlas ? Concernant cette question, je n'ai pas étudié comment l'auteur d'Atlas l'explique. Mais d'après mon expérience personnelle de l'utilisation du rappel et de l'atlas, je pense que le rappel en tant qu'interface est très similaire à la publication, et il doit permettre aux utilisateurs de l'utiliser de la même manière que la publication. Cependant, il faut dire que son mécanisme de type postback n'est pas particulièrement pratique à utiliser et n'est pas facile à étendre. Bien sûr, cela est comparé à d'autres implémentations de framework AJAX. Par conséquent, Microsoft a tiré les leçons de nombreuses implémentations AJAX existantes, telles que Prototype, Backbase et AJAX.NET, et les a combinées avec certaines des fonctions uniques d'ASP.NET 2.0 pour créer un tel framework AJAX qui s'appuie sur les points forts des autres. Il est difficile de quantifier à quel point il est bon de développer des applications AJAX basées sur Atlas, mais ce n'est certainement pas pire que les autres frameworks AJAX, plus le backend de Microsoft et les applications de sites lourds comme live.com Promotion, son impact en vaut certainement la peine. avec impatience.
Cependant, cela ne signifie pas que l'implémentation du rappel est inutile. En tant que programmeurs, nous devons avoir la bonne attitude et utiliser la technologie la plus appropriée dans le bon cas d'utilisation. Aucun framework n'est omnipotent et adapté à n'importe quel environnement d'utilisation ; tout comme tout le monde se demande quelle méthode de développement logiciel est la meilleure, CMMi, RUP, XP, AGILE~~, en fait, il n'y a pas de meilleure, la plus adaptée est la plus adaptée. Ce que nous devons faire le plus, c'est comprendre les principes, les avantages et les inconvénients des différentes solutions, afin de pouvoir utiliser rationnellement les bons outils pour résoudre les problèmes pratiques.
Commencer à partir du script client
Nous savons tous qu'au niveau le plus bas, tout AJAX n'a rien de plus que deux mécanismes d'implémentation : XMLHTTP et IFRAME. Avant que le mot AJAX ne retienne l'attention, en fait, les cadres fonctionnels basés sur ces deux implémentations sous-jacentes, ou les implémentations sans effet de rafraîchissement basées sur ces deux technologies, étaient déjà largement utilisés. Bien sûr, avec le développement actuel, en termes d'utilisation des interfaces, les détails de ces mécanismes sous-jacents sont souvent cachés par le framework, et l'utilisation des interfaces est devenue de plus en plus simple. Les utilisateurs n'ont qu'à appeler ces interfaces simples, et il n'est pas nécessaire de les connaître. comment obtenir l'effet spécifique.
Cependant, puisque nous sommes ici pour analyser le mécanisme d'implémentation du rappel, commençons par un appel de script client d'appel de rappel pour voir comment Microsoft implémente ce mécanisme de rappel.
1. ClientScript.GetCallbackEventReference(...)
Pour déclencher un rappel, bien sûr, un appel doit d'abord être émis dans le script client. Une syntaxe d'appel typique est la suivante :
<script language="javascript" type="text/javascript">
fonction any_script_function (argument, contexte)
{
<%= ClientScript.GetCallbackEventReference(this, "arg", "ReceiveServerData", "context")%>;
}
＜/script＞
ClientScript.GetCallbackEventReference(...) renverra le script de rappel réel en fonction des paramètres transmis. Cette fonction a plusieurs versions surchargées, vous pouvez donc vous référer à MSDN pour connaître la signification de ces paramètres. Prenez les paramètres spécifiques dans l'exemple de code ci-dessus :
- cela signifie que le contrôle serveur qui exécute le rappel est la page actuelle. La page actuelle doit implémenter l'interface ICallbackEventHandler, y compris la chaîne GetCallbackResult() et void RaiseCallbackEvent(eventArgument). deux fonctions d'interface, ce paramètre peut aussi être une référence à un champ WEB. Bien entendu, cet espace doit également implémenter l'interface ICallbackEventHandler ;
- "arg" est la valeur du paramètre eventArgument qui sera passé à RaiseCallbackEvent, qui permet de Une chaîne qui définit le format ;
- "ReceiveServerData" est le nom de la fonction de script client qui traite le contenu renvoyé une fois le rappel réussi. Cette fonction doit exister sur la page où le rappel est exécuté, et cette fonction peut contenir deux paramètres. , par exemple :
<script type="text/javascript">
fonctionReceiveServerData (résultat, contexte)
{}
＜/script＞
Ces deux paramètres sont le résultat des données de retour du rappel et le paramètre de contexte qui est renvoyé inchangé lorsque nous déclenchons le rappel. Bien entendu, ces deux paramètres sont de type chaîne.
- Il n'est pas nécessaire d'expliquer le "contexte". N'oubliez pas que ce paramètre sera transmis intact à la fonction de traitement des données de retour spécifiée. La documentation officielle de MSDN indique que le contexte peut généralement être utilisé pour transmettre le code de script qui doit être appelé dans la fonction de traitement des données de retour du client, mais en fait, vous pouvez tout transmettre. Considérez-le comme un rappel de déclenchement du client. au canal de transfert de paramètres entre les segments de réception qui traitent les données renvoyées.