Если компьютерный зал скоро закроется или вам не терпится встретиться с девушкой, перейдите сразу к четвертому естественному абзацу.
Описанные ниже сценарии включают в себя сценарии на стороне сервера и сценарии на стороне клиента. Сценарии на стороне сервера относятся к части сценария, который выполняется на сервере. Например, общий Response.Write, очевидно, выполняется на стороне сервера. сценарии можно писать с использованием языков VBScript и JScript, в этой статье используются все VBScript и Jscript.
Клиентские сценарии также можно рассматривать как включающие два языка: VBScript и JavaScript, которые представляют собой языки сценариев, которые выполняются в клиентском браузере. Например, когда мы посещаем веб-страницу и появляется окно сообщения, это делается с помощью клиентских сценариев (предупреждение, msgbox и т. д.), и очевидно, что серверные сценарии не могут этого сделать. Существует еще одно большое различие между сценариями на стороне клиента и сценариями на стороне сервера (в таких браузерах, как IE и Firefox). Оно заключается в том, что сценарии на стороне клиента могут получать доступ к объектной модели документа (DOM) и манипулировать объектами на странице (например, например, изменение заголовка страницы, изменение атрибута InnerHTML элемента div и т. д.).
Во-первых, давайте посмотрим на процесс выполнения страницы ASP.
1. IIS находит файл ASP и отправляет его на обработку механизму ASP (обычно ASP.DLL).
2. Механизм открывает файл ASP и находит содержимое между <% и %> и, конечно же, содержимое между <script runAt=server> и соответствующим </script>. Это содержимое называется блоками сценария. Механизм анализирует только содержимое блока сценария, а остальной контент игнорируется и вставляется между блоками сценария как бессмысленные символы. Необходимо объяснить, что на самом деле анализируемый контент — это нечто большее. Серверные включаемые файлы класса <!--#include ***--> также включаются и обрабатываются движком. Если вы читали много программ, вы также знаете, что некоторые объекты <object>, атрибуты runAt которых помечены как Server, также будут обрабатываться. Мы не будем обсуждать их здесь подробно.
3. Движок выполняет сценарии в блоке сценариев. Эти серверные сценарии выполняются целиком. То есть можно написать следующий код:
<%
Дим я
Для я = от 1 до 5
%> Привет, мир!
<% Следующий %>
Механизм не анализирует эти блоки скриптов по отдельности, что приводит к синтаксическим ошибкам в обоих блоках скриптов. Итак, мы приходим к следующему выводу: не весь несерверный код скрипта будет отправлен клиенту. Возможно, этот несерверный код скрипта ограничен блоком скрипта. Сервер точно не будет беспокоиться о выполнении клиентских скриптов, но может выводить разные клиентские скрипты через серверные скрипты.
4. Наконец, движок генерирует текстовый поток или результат выполнения скрипта, который можно рассматривать как строку, представляющую собой код веб-страницы, отправленный в клиентский браузер. Браузер клиента отображает страницу. В это время исходный код (исходный файл) страницы не содержит серверного сценария, но содержит результат выполнения серверного сценария (это очевидно).
<% … %> и <script runat=server>…</script>
Все это серверные сценарии, которые обрабатываются и выполняются одновременно. Они действуют как единое целое.
<% … %> и <script Language=…>…</script>
Первый — это скрипт на стороне сервера, а второй — скрипт на стороне клиента. Первое выполняется первым, а второе — позже.
На самом деле это не обязательно так. Два сценария могут выполняться одновременно, но пробелы все равно разные: первый выполняется на сервере, а второй — на сервере. клиентский браузер. Первое логически должно быть выполнено раньше, чем второе. В то же время мы также пришли к выводу: во время выполнения одной и той же страницы клиентский сценарий в любом случае не может связаться с серверным сценарием. То есть клиент просматривает вашу гостевую книгу и отправляет данные. новые сообщения или любое значение, полученное сценарием на стороне клиента, не могут быть обработаны в одном и том же ответе сервера.
О вызовах компонентов
Обратите внимание, что сценарии на стороне сервера и сценарии на стороне клиента являются сценариями. Естественно, вы можете создавать компоненты xmlhttp, компоненты ADODB.Connection и т. д., но их нельзя размещать где-либо.
Если xmlhttp используется для сканирования веб-страниц (например, коллекции) с сервера, он должен быть создан в серверном скрипте. Если он используется для ajax клиента для доступа к серверной странице в фоновом режиме без обновления, он запускается. на клиенте, и естественно на клиенте Создается в конце.
Компонент ADODB.Connection используется для доступа к базе данных. Вообще говоря, он создается на стороне сервера. Ведь именно серверная программа asp запускает данные базы данных, но если ваша база данных действительно подключена на стороне клиента. стороне (например, http://bbs.bccn.net/thread-224966-1-2.html), то ее необходимо создать в клиентском скрипте.
Короче говоря, вещи противоречивые и каждая сторона имеет свои особенности. Разные вещи имеют разные противоречия; одно и то же имеет разные противоречия в разных процессах и стадиях развития; разные противоречия в одном и том же и два разных аспекта одного и того же противоречия имеют свои особенности (неясные можно опустить). смотрю…). Этот принцип требует от нас придерживаться принципа конкретного анализа конкретных проблем и под руководством принципа всеобщности противоречий конкретно анализировать особенность противоречий и находить правильный метод их разрешения. Мы против использования одного метода для разрешения противоречий разных вещей. Вот что значит открыть ключом замок и спеть любую песню, под которую ты пойдешь, в любой горе.
Серверные сценарии VBScript используют метод Server.CreateObject(className) для создания объектов, а клиентские сценарии VBScript используют метод CreateObject(className) для создания объектов.
Типичные ошибки
<%
ФункцияTSize(b)
'Это моя пользовательская функция
TSize=Китай
конечная функция
%>
<a href=javascript:<%TSize('Variable')%> >Нажмите здесь, чтобы использовать определенную мной функцию</a>
(http://bbs.bccn.net/thread-225244-1-1.html)
Анализ ошибок:
Запутанная разница между сценариями на стороне сервера и сценариями на стороне клиента. Во время фактического выполнения мы обнаружим, что клиент вообще не получает никакого кода, такого как TSize, поскольку TSize — это серверная программа, которая обрабатывается движком (обратите внимание, что обработка функций движком предназначена исключительно для серверного сценария). звонки и не будут отправлены обратно клиенту) пропадает и не может работать на клиенте. Это означает, что клиентские сценарии не могут напрямую вызывать функции серверных сценариев.
Фактически, в этой программе есть синтаксическая ошибка. Когда механизм обрабатывает это содержимое, он сначала находит содержимое между <% и %>, то есть <%TSize('variable')%>. Очевидно, что это содержимое не соответствует требованиям. с синтаксическими правилами VBScript. Что ж, если вы измените его на <%=TSize(variable)%>, в серверном скрипте не будет синтаксических ошибок. В это время функция TSize может возвращать значение China обычным образом, поэтому атрибут href получен. клиент пишется так: javascript: Китай, не имеет исковой силы.
Влияние серверных сценариев на клиентские сценарии
Как упоминалось ранее, серверные сценарии логически выполняются раньше клиентских, поэтому возможен такой код:
<%
Дим я
Для я = от 1 до 5
Response.Write <тип сценария=текст/javascript> _
& alert('Привет, мир! & i & ')</script>
Следующий
%>
Что касается выполнения Response.Redirect и javascript
Обратите внимание, что следующий код написан неверно:
<%
Response.Redirect index.asp
Response.Write <тип сценария=текст/javascript> _
& alert('Неверный пароль!')</script>
%>
Это распространенная ошибка. Авторы часто думают, что написание кода таким образом приведет к тому, что клиент выдаст сообщение об ошибке пароля и затем перенаправит на index.asp. На самом деле этого не может произойти, даже если порядок двух строк. код поменяется, этого не будет. Достичь такого эффекта возможно.
Причина связана с тем, как сервер обрабатывает две строки кода. Эти две строки кода не могут работать одновременно.
Response.Write — это отправка клиенту фрагмента текста. Содержимым этого текста может быть скрипт. Затем браузер клиента может выполнить скрипт после его получения.
Response.Redirect отправляет клиенту HTTP-заголовок (что такое HTTP-заголовок? Скажем так, например, запись в файлы cookie клиента — это информация HTTP-заголовка, а информация HTTP-заголовка отправляется обратно клиенту перед браузером тела HTTP). , поэтому иногда мы получаем ошибку при изменении файлов cookie после отключения буферизации сервера, поскольку тело уже начало передачу, а HTTP-заголовки не могут быть отправлены. Информация.), содержимое информации сообщает клиентскому браузеру, что он должен перейти на страницу для просмотра. Обратите внимание, что эта информация о перенаправлении вступает в силу немедленно, что означает, что эта информация о перенаправлении является эксклюзивной, когда буфер включен, независимо от того. был ли использован Response. .Write записывает объем содержимого в буфер. После вызова Response.Redirect буфер будет очищен, и эта инструкция заголовка будет отправлена в клиентский браузер. Если мы динамически отслеживаем выполнение программы, мы также обнаружим, что после вызова Response.Redirect программа перестает выполняться, поэтому обратите внимание, что серверная программа должна закрыть соединение для передачи данных и другие операции перед вызовом Response.Redirect.
Так как же следует изменить приведенный выше пример? Если вы не хотите изменять index.asp для добавления приглашения сценария, вы можете выполнить инструкцию перенаправления только в клиентском сценарии, например:
<%
Response.Write <тип сценария=текст/javascript> _
& alert('!');location.href='index.asp'</script>
%>
Контактная информация
Если у вас есть замечания и предложения, особенно ошибки и недостатки в статье, или если вы хотите добавить в статью новый материал, вы можете связаться со мной через форум программирования. Конечно, вы также можете задавать вопросы после этого поста.
Стоит отметить, что если у вас есть вопросы об алгоритмах и структурах данных, например, вы не понимаете, почему ваша программа неверна или запросили исходный код определенного алгоритма, вы можете не получить своевременный ответ, используя эту контактную информацию. Спросите, пожалуйста, на форуме программирования.
-------------------------------------------------- ----------------------------------
авторское право
Авторские права (c) 2008 г., кратный 1902 г.
Разрешается копировать, распространять и/или изменять этот документ в соответствии с условиями лицензии GNU Free Documentation License версии 1.2 или любой более поздней версии, опубликованной Free Software Foundation.