Die allgemeine Verwendung von Rückrufen ist relativ einfach. Es reicht aus, direkt auf die Hilfe und Beispiele von msdn zu verweisen. Wenn Sie es jedoch wirklich gut und genau verwenden oder einige WEB-Komponenten basierend auf dem Rückrufmechanismus entwickeln möchten, müssen Sie zunächst den Rückrufimplementierungsmechanismus genau verstehen. In diesem Artikel wird Teddy mit Ihnen zusammenarbeiten, um den gesamten Aufruf- und Feedbackmechanismus des Rückrufs zu analysieren. Ich bin davon überzeugt, dass er Ihnen dabei helfen wird, den Rückruf besser zu nutzen.
Rückruf vs. Atlas
Lassen Sie uns zunächst über Atlas sprechen. Viele Freunde finden es vielleicht seltsam, dass es bereits Callback gibt. Warum müssen wir Atlas erneut veröffentlichen? Zu diesem Thema habe ich nicht untersucht, wie der Autor von Atlas es erklärt. Aufgrund meiner persönlichen Erfahrung mit der Verwendung von Callback und Atlas habe ich jedoch das Gefühl, dass Callback als Schnittstelle Postback sehr ähnlich ist und dass Benutzer es ähnlich wie Postback verwenden können. Allerdings ist der Postback-ähnliche Mechanismus im Vergleich zu anderen AJAX-Framework-Implementierungen nicht besonders benutzerfreundlich und nicht einfach zu erweitern. Daher hat Microsoft aus vielen bestehenden AJAX-Implementierungen wie Prototype, Backbase und AJAX.NET gelernt und diese mit einigen der einzigartigen Funktionen von ASP.NET 2.0 kombiniert, um ein solches AJAX-Framework zu erstellen, das auf den Stärken anderer basiert. Es ist schwer zu quantifizieren, wie gut es ist, AJAX-Anwendungen auf Basis von Atlas zu entwickeln, aber es ist definitiv nicht schlechter als andere AJAX-Frameworks, plus das Backend von Microsoft und die Anwendungen von Schwergewichtsseiten wie live.com Promotion, seine Wirkung ist es auf jeden Fall wert Ich freue mich darauf.
Dies bedeutet jedoch nicht, dass die Callback-Implementierung nutzlos ist. Als Programmierer müssen wir die richtige Einstellung haben und die korrekteste Technologie im richtigen Anwendungsfall verwenden. Kein Framework ist allmächtig und für jede Anwendungsumgebung geeignet; so wie jeder darüber debattiert, welche Softwareentwicklungsmethode die beste ist, CMMi, RUP, XP, AGILE~~, tatsächlich gibt es keine beste, die am besten geeignete ist in Ordnung Was wir vor allem tun sollten, ist, die Prinzipien, Vor- und Nachteile verschiedener Lösungen zu verstehen, damit wir die richtigen Werkzeuge rational einsetzen können, um praktische Probleme zu lösen.
Beginnen Sie mit dem Client-Skript.
Wir alle wissen, dass AJAX auf der untersten Ebene nur über zwei Implementierungsmechanismen verfügt: XMLHTTP und IFRAME. Bevor das Wort AJAX große Aufmerksamkeit erlangte, waren funktionale Frameworks, die auf diesen beiden zugrunde liegenden Implementierungen basierten, oder Implementierungen ohne Aktualisierungseffekt, die auf diesen beiden Technologien basierten, bereits weit verbreitet. Natürlich werden bei der heutigen Entwicklung in Bezug auf die Verwendung von Schnittstellen die Details dieser zugrunde liegenden Mechanismen häufig vom Framework ausgeblendet, und die Verwendung von Schnittstellen ist immer einfacher geworden. Benutzer müssen diese einfachen Schnittstellen nur aufrufen und müssen es nicht wissen wie man den spezifischen Effekt erzielt.
Da wir jedoch hier sind, um den Callback-Implementierungsmechanismus zu analysieren, beginnen wir mit einem Callback-Call-Client-Skriptaufruf, um zu sehen, wie Microsoft diesen Callback-Mechanismus implementiert.
1. ClientScript.GetCallbackEventReference(...)
Um einen Rückruf auszulösen, muss natürlich zunächst ein Aufruf im Client-Skript abgesetzt werden. Eine typische Aufrufsyntax lautet wie folgt:
<script language="javascript" type="text/javascript">
Funktion any_script_function(arg, context)
{
<%= ClientScript.GetCallbackEventReference(this, "arg", "ReceiveServerData", "context")%>;
}
＜/script＞
ClientScript.GetCallbackEventReference(...) gibt das eigentliche Rückrufskript gemäß den übergebenen Parametern zurück. Für diese Funktion gibt es mehrere überladene Versionen. Die Bedeutung dieser Parameter können Sie daher MSDN entnehmen. Nehmen Sie die spezifischen Parameter im obigen Beispielcode:
– Dies bedeutet, dass das Serversteuerelement, das den Rückruf ausführt, die aktuelle Seite ist. Die aktuelle Seite muss die ICallbackEventHandler-Schnittstelle implementieren, einschließlich der Zeichenfolge GetCallbackResult() und void RaiseCallbackEvent(eventArgument). Bei zwei Schnittstellenfunktionen kann dieser Parameter auch ein Verweis auf ein WEB-Steuerelement sein. Natürlich muss dieser Bereich auch die ICallbackEventHandler-Schnittstelle implementieren.
„Argument“ ist der Wert des Parameters eventArgument, der an RaiseCallbackEvent übergeben wird Eine Zeichenfolge, die das Format definiert;
- „ReceiveServerData“ ist der Name der Client-Skriptfunktion, die den zurückgegebenen Inhalt nach erfolgreichem Rückruf verarbeitet. Diese Funktion muss auf der Seite vorhanden sein, auf der der Rückruf ausgeführt wird, und diese Funktion kann zwei Parameter enthalten , zum Beispiel:
<script type="text/javascript">
functionReceiveServerData(result, context)
{}
＜/script＞
Diese beiden Parameter sind das Rückgabedatenergebnis des Rückrufs und der Kontextparameter, der unverändert zurückgegeben wird, wenn wir den Rückruf auslösen. Natürlich sind diese beiden Parameter vom Typ String.
- Es ist nicht erforderlich, „Kontext“ zu erklären. Denken Sie jedoch daran, dass dieser Parameter intakt an die angegebene Rückgabedatenverarbeitungsfunktion übergeben wird. In der offiziellen Dokumentation von MSDN heißt es, dass der Kontext im Allgemeinen zum Übergeben von Skriptcode verwendet werden kann, der in der Rückgabedatenverarbeitungsfunktion des Clients aufgerufen werden muss. Tatsächlich können Sie es sich jedoch als Trigger-Rückruf vom Client vorstellen an den Parameterübertragungskanal zwischen den Empfangssegmenten, die die zurückgegebenen Daten verarbeiten.