bogachenkov
Для профессиональных целей, мне было необходимо динамически создать страницу и заполнить её.
После просмотра различных форумов, для себя я решил, что для этого неплохо подходит JavaScript и 2 его функции:
- window.open(«Адресс страницы», Имя_окна [, Параметры_окна]) — создает новое окно браузера , аналогично команде «Новое окно» в меню браузера. Обычно это не вкладка, а именно новое окно, но в некоторых браузерах можно настроить то или иное поведение явным образом. Если вместо адреса страницы — пустая строка, то в окно будет загружен пустой ресурс about:blank. В любом случае, загрузка осуществляется асинхронно. Создается пустое окно, загрузка ресурса в которое начнется уже после завершения исполнения текущего блока кода.
- document.write(аргумент1[, аргумент2[, аргумент3[, . ]]]) — метод, выводящий на страницу переданные ему аргументы. Аргументов может быть любое количество, и они могут быть любых типов, при выводе они преобразуются в строки. Также существует функция document.writeln, которая аналогична document.write, но добавляет в конце своего вывода перевод строки.
В итоге, простейший пример с их исспользованием принимает следующий вид:
var win1 // Объявляем переменную для нового окна.
alert(«Сейчас откроется новое окно.»); // Предупреждаем пугливого пользователя.
win1 = window.open («», «Scriptic», «resizable=1, width=300, height=150»);
// Присваиваем переменной win1 новое пустое окно размерами 300х150
win1.document.open (); // Открываем его.
// Заполняем только что созданный документ.
window.focus(); // Переводим фокус.
// Укажем, что наш скрипт запускается при загрузке страницы.
По неизвестным причинам, FireFox напрочь отказывается открывать новое окно. Возможно, причина в реализации FireFox на Linux-системах, но блокировка открытия нового окна не снимается.
Для справки приведу параметры, используемые при создании нового окна:
Параметры, касающиеся элементов управления окна, могут быть жестко установлены в конфигурации браузера. В этом случае их указание в параметрах open() не даст нужного эффекта.
left/top — Расстояние от левой/верхней границы окна операционной системы до границы нового окна. Новое окно не может быть создано за границами экрана height/width -Высота/ширина в пикселях внутренности нового окна, включая полосы прокрутки, если они есть. Минимальное значение: 100 menubar — Если этот параметр установлен в yes, то в новом окне будет меню. Toolbar — Если этот параметр установлен в yes, то в новом окне будет навигация (кнопки назад, вперед и т.п.) и панель вкладок location — Если этот параметр установлен в yes, то в новом окне будет адресная строка directories — Если этот параметр установлен в yes, то в новом окне будут закладки/избранное status — Если этот параметр установлен в yes, то в новом окне будет строка состояния resizable — Если этот параметр установлен в yes, то пользователь сможет изменить размеры нового окна. Рекомендуется всегда устанавливать этот параметр. Scrollbars — Если этот параметр установлен в yes, то новое окно при необходимости сможет показывать полосы прокрутки
Как можно было увидеть, всё довольно таки просто. 🙂
Динамическое обновление веб-страницы
Никого уже не удивишь концепцией динамического HTML, почти все сайты давно в той или иной мере используют javascript для того, чтобы сделать страницы интерактивными. А с появлением технологии AJAX стало возможным асинхронно генерировать запросы к серверу, чтобы изменять старые данные на сервере или получать новые. Но как именно обновлять структуру страницы? Кто должен генерировать новый html — сервер или javascript? А может, все вместе?
Посмотрим, как можно ответить на эти вопросы.
Для начала, я опишу жизненный цикл страницы. Сразу скажу, что я не собираюсь описывать этот процесс досконально, здесь требуется только понимание основной логики процесса.
Любое веб-приложение можно логически поделить на две составляющие — на клиентскую часть и серверную часть. К клиентской части относятся сам браузер и скрипты, которые он выполняет, к серверной — набор скриптов, которые генерируют ответ на любой запрос пользователя.
Жизнь любой страницы начинается с запроса от клиента к серверу. Ответом будет код страницы, содержащий, помимо структуры и стилей, логику клиентской части.
После получения страницы с сервера, браузер отображает её и запускает на выполнение приложенные к ней скрипты.
Клиентская часть реагирует на различные события — например, на клик по некоторому элементу, перемещение мыши или на истечение таймера. Для того, чтобы получить какие-то данные с сервера(или отправить что-то на него), используются дополнительные, обычно асинхронные, запросы.
Пикантность начинается, когда необходимо в какой-то момент перерисовать некоторые компоненты на странице. Для того, чтобы обновить структуру страницы, скрипту клиента необходимо знать, что необходимо убрать, что и куда необходимо добавить, что на что заменить. Вот тут-то и появляются разные варианты, как организовать такие обновления.
Ближе к сути
Для удобства объяснения рассмотрим вариант обновления простой страницы с лентой новостей и, скажем, счетчиком подписчиков. Мы хотим, чтобы браузер регулярно проверял обновления ленты, добавляя новости по мере их появления. А еще мы хотим, чтобы каждый посетитель видел динамику роста популярности нашего сайта — пусть счетчик подписчиков тоже регулярно обновляется.
Тело нашей страницы может выглядеть, например, так:
Вариант 1 — дублирование
Основная идея — логику отображения знает и клиентская, и серверная часть. В таком случае, ответы на регулярные запросы со стороны клиента могут содержать исключительно данные — изменения в модели, и выглядеть, например, так:
При получении такого ответа клиентская часть «оборачивает» данные в html-теги, добавляет необходимые тексты и обновляет структуру страницы.
Серверу же знания об отображении нужны только для того, чтобы сгенерировать изначальную версию страницы.
- Требуется продублировать код — он будет и в клиентской части, и в серверной;
- Клиентская часть должна знать, как именно поступать с каждой порцией данных от сервера — иногда нужно заменить html элемента, иногда добавить новые данные к уже существующему коду;
Вариант 2 — всемогущий сервер и «толстые» ответы
Основная идея — логику отображения знает только сервер, клиентская часть получает уже готовый html-код элементов. Здесь ответ сервера выглядит так:
Замечу, что пересылается здесь весь html каждого компонента на странице. Реализуется же такой способ просто — сервер генерирует страницу по кускам, клиент при получении ответа заменяет тела отдельных элементов.
- Многократная генерация одного и того же кода, особенно неэффективно при небольших изменениях;
- Огромный объем трафика, особенно на больших страницах;
Вариант 2а — всемогущий сервер и «тонкие» ответы
Можно попытаться исправить главный недостаток предыдущего варианта. Сервер может не отправлять весь html компонента, а присылать только «дельту» — изменения, которые необходимо внести. Наш ответ тогда может стать таким:
Теперь клиент определяет элемент, который будет изменять, и то, как он его будет изменять, непосредственно из ответа сервера.
- Все еще достаточно большой объем сетевого трафика;
- Клиент должен отправить серверу текущее состояние каждой компоненты, закодированное некоторым образом, чтобы сервер понял, относительно чего считать дельту;
- Сложность вычисления и записи дельты в случае нетривиальных изменений;
- Общее усложнение и клиентской, и серверной части;
Вариант 3 — всемогущий javascript
Можно переложить всю ответственность за генерацию html на клиента. В таком случае сервер будет только предоставлять данные, необходимые для отображения. Ответы, как и в первом варианте, будут содержать только данные:
Так в чем же существенное отличие от первого варианта? А заключается оно в том, что сервер не выполняет первоначальную генерацию страницы, её сборка осуществляется уже браузером клиента. Вариант этот только выглядит странным, он может пригодиться, если необходимо уменьшить нагрузку на сервер.
- Малый объем трафика — передаются только необходимые данные;
- Уменьшение нагрузки на сервер;
- Высокая нагрузка на компьютер пользователя;
- Возможна избыточность — часть знаний клиентской части об отображении может так и остаться невостребованной, если какие-то события не наступят;
Заключение
Каждый из рассмотренных методов имеет право на жизнь, и может быть использован в проектах разной сложности. Лично я во встреченных мною проектах чаще всего видел первый вариант, несмотря на нарушение им моего любимого принципа DRY — Don`t repeat yourself.
А какие принципы вы используете при разработке динамических страниц?