Общее использование обратного вызова относительно просто. Достаточно напрямую обратиться к справке и примерам msdn. Но если вы действительно хотите использовать его хорошо и точно или хотите разработать некоторые WEB-компоненты на основе механизма обратного вызова, то вам необходимо сначала иметь глубокое понимание механизма реализации обратного вызова. В этой статье Тедди вместе с вами проанализирует весь механизм вызова и обратной связи по обратному вызову. Я считаю, что это принесет определенную пользу, чтобы помочь вам лучше использовать обратный вызов.
Обратный вызов против Atlas
Сначала давайте поговорим об Atlas. Многим друзьям может показаться странным, что уже есть Callback, зачем нам снова выпускать Атлас? Что касается этого вопроса, я не исследовал, как его объясняет автор Атласа. Но из моего личного опыта использования обратного вызова и атласа я чувствую, что обратный вызов как интерфейс очень похож на обратную передачу, и он должен позволять пользователям использовать его аналогично обратной передаче. Однако следует сказать, что его механизм, подобный обратной передаче, не особенно удобен в использовании и его нелегко расширить. Конечно, это по сравнению с другими реализациями платформы AJAX. Поэтому Microsoft извлекла уроки из многих существующих реализаций AJAX, таких как Prototype, Backbase и AJAX.NET, и объединила их с некоторыми уникальными функциями ASP.NET 2.0, чтобы создать такую структуру AJAX, которая опирается на сильные стороны других. Трудно дать количественную оценку, насколько хорошо разрабатывать AJAX-приложения на базе Atlas, но это точно не хуже, чем у других AJAX-фреймворков, плюс бэкенд Microsoft и приложения таких тяжеловесных сайтов, как live.com. Продвижение, его влияние, безусловно, стоит с нетерпением жду.
Однако это не означает, что реализация обратного вызова бесполезна. Нам, как программистам, необходимо иметь правильный настрой и использовать наиболее правильную технологию в правильном варианте использования. Никакая среда не является всемогущей и подходящей для любой среды использования; точно так же, как все спорят о том, какой метод разработки программного обеспечения лучше: CMMi, RUP, XP, AGILE~~, на самом деле лучшего не существует, наиболее подходящий — самый подходящий. Больше всего нам следует понять принципы, преимущества и недостатки различных решений, чтобы мы могли рационально использовать правильные инструменты для решения практических проблем.
Начнем с клиентского сценария.
Все мы знаем, что на нижнем уровне любой AJAX имеет не более чем два механизма реализации: XMLHTTP и IFRAME. Фактически, до того, как слово AJAX привлекло широкое внимание, функциональные структуры, основанные на этих двух базовых реализациях, или реализации эффектов без обновления, основанные на этих двух технологиях, уже широко использовались. Конечно, с сегодняшним развитием, с точки зрения использования интерфейсов, детали этих базовых механизмов часто скрыты структурой, и использование интерфейсов становится все более простым. Пользователям нужно только вызывать эти простые интерфейсы, и об этом не нужно знать. как добиться конкретного эффекта.
Однако, поскольку мы здесь для анализа механизма реализации обратного вызова, давайте начнем с вызова клиентского сценария обратного вызова, чтобы увидеть, как Microsoft реализует этот механизм обратного вызова.
1. ClientScript.GetCallbackEventReference(...)
Чтобы вызвать обратный вызов, сначала, конечно, необходимо выполнить вызов в клиентском скрипте. Типичный синтаксис вызова следующий:
<script Language="javascript" type="text/javascript">
функция Any_script_function (arg, контекст)
{
<%= ClientScript.GetCallbackEventReference(this, "arg", "ReceiveServerData", "context")%>;
}
＜/script＞
ClientScript.GetCallbackEventReference(...) вернет фактический сценарий обратного вызова в соответствии с переданными параметрами. Эта функция имеет несколько перегруженных версий, поэтому вы можете обратиться к MSDN за значением этих параметров. Возьмите конкретные параметры из приведенного выше примера кода:
— это означает, что серверный элемент управления, выполняющий обратный вызов, является текущей страницей. Текущая страница должна реализовать интерфейс ICallbackEventHandler, включая строку GetCallbackResult() и void RaiseCallbackEvent(eventArgument). две функции интерфейса, этот параметр также может быть ссылкой на WEB-элемент управления. Конечно, это пространство также должно реализовывать интерфейс ICallbackEventHandler
— «arg» — это значение параметра eventArgument, который будет передан в RaiseCallbackEvent, что позволяет людям Строка, определяющая формат;
— «ReceiveServerData» — это имя функции клиентского скрипта, которая обрабатывает возвращаемое содержимое после успешного обратного вызова. Эта функция должна существовать на странице, где выполняется обратный вызов, и эта функция может содержать два параметра. , например:
<script type="text/javascript">
функцияReceiveServerData (результат, контекст)
{}
＜/script＞
Эти два параметра представляют собой возвращаемые данные обратного вызова и параметр контекста, который возвращается без изменений при запуске обратного вызова. Конечно, эти два параметра имеют строковый тип.
— Нет необходимости объяснять «контекст». Просто помните, что этот параметр будет передан в указанной функции обработки возвращаемых данных в неизмененном виде. В официальной документации MSDN говорится, что контекст обычно можно использовать для передачи кода сценария, который необходимо вызвать в функции обработки возвращаемых данных клиента, но на самом деле вы можете передать что угодно, как обратный вызов триггера от клиента, просто перейдите. в канал передачи параметров между приемными сегментами, обрабатывающими возвращаемые данные.