Main.iwa
после определения класса добавим раздел определения связей:
<?
dessert_list {
item = dessert_item
list = desserts
} ?>
Тем самым производится связывание списка dessert_list
в шаблоне. На каждой итерации элемент списка заполняется из переменной dessert_item
, а данные в целом поступают от метода компонента desserts
.
19.6.3. Передача управления компоненту
Бывает полезно разнести логику приложения по нескольким классам компонентов. Мы видели, как можно отобразить URL на компоненты. Имеется также способ передать управление, не изменяя базового пути в URL.
Добавим в файл Main.iwa
метод для обработки щелчка по ссылке в меню десертов:
def dessert_choice
new_page = page_named( 'DessertChoice')
new_page.choice = @dessert_item
yield new_page
end
Также изменим цикл формирования списка десертов в Main.html
:
<ul oid='dessert_list'>
<li><a oid= 'dessert_choice'>@dessert_item</a></li>
</ul>
Тут происходит немало интересного; атрибут oid
элемента ul
управляет формированием цикла, а такой же атрибут элемента а создает специальную ссылку на только что добавленный метод dessert_choice
. Для довершения дела странице передается еще и текст ссылки (хотя и несколько загадочным способом). Метод dessert_choice
сам по себе короткий, в нем вызывается метод page_named
для создания экземпляра еще одного класса компонента DessertChoice
. Для передачи выбранного десерта вызывается метод choice=
. Затем yield
передает управление новому компоненту.
Новый компонент также определяется с помощью пары файлов с расширениями .iwa
и .html
. Вот код класса:
class DessertChoice < Iowa::Component
attr_accessor :choice
def details
'Детали #{@choice} нужно было брать из базы данных.'
end
end
А в файле DessertChoice.html
хранится разметка:
<html>
<head><title>Выбранный вами десерт</title></head>
<body>
<h1>Десерт!</h1>
<p>@details</p>
</body>
</html>
Об IOWA можно было бы рассказывать еще долго. Для получения дополнительной информации зайдите на домашнюю страницу IOWA (http://enigo.com/proiects/iowa/) или на страницу проекта IOWA на сайте RubyForge (http://rubyforge.org/projects/iowa).
19.7. Ruby и Web-сервер
На сегодняшний день одним из самых популярных Web-серверов является Apache. Если вы работаете с ним, то должны знать о модуле mod_ruby
, который описывается в разделе 19.7.1.
Еще одна полезная возможность на стороне сервера — встроенный Ruby; эту технологию поддерживают инструменты erb
(рассматриваемый ниже) и eruby
. Они позволяют встраивать код на Ruby в текст страницы (обычно HTML или XML), вследствие чего данные можно вставлять динамически. Данный подход описывается в разделе 19.7.2.
Некоторые разработчики реализовали Web-серверы, написанные целиком на Ruby. Естественно возникает вопрос: зачем писать новый Web-сервер, когда их уже и так существует немало — взять хотя бы тот же Apache?
Во-первых, есть ситуации, когда желательно иметь специализированный Web-сервер, например ради нестандартного способа обработки страниц, когда можно пожертвовать функциональностью ради скорости, или для автоматической трансляции специальной разметки в HTML.
Во-вторых, может возникнуть желание поэкспериментировать с поведением сервера и его взаимодействием с внешним кодом, например с CGI-программами. Возможно, у вас есть какие-то идеи относительно создания сервера приложений и среды разработки на стороне сервера. А все мы знаем, что Ruby прекрасно подходит для экспериментов.
В-третьих, иногда бывает разумно встроить Web-сервер в другое приложение. К этой возможности прибегают разработчики, желающие предоставить функциональность программной системы внешнему миру; протокол HTTP прост и четко определен, а Web-браузеры в качестве клиентов есть повсюду. Этот прием можно даже использовать для удаленной отладки, если система часто обновляет свое внутреннее состояние и делает его доступным встроенному серверу.
И последняя причина заключается в том, что небольшой автономный Web-сервер может упростить развертывание и конфигурирование. Например, перезапустить сервер для приложения Rails гораздо проще, если в этом качестве выступает WEBrick, а не Apache.
Имея все это в виду, посмотрим, что Ruby предлагает в плане Web-серверов. В прошлом было по крайней мере четыре таких сервера, но летом 2006 года остались два наиболее значимых: WEBrick и Mongrel. Они описаны в разделах 19.7.3 и 19.7.4 соответственно.
19.7.1. Модуль mod_ruby
Обычно, если CGI-сценарий пишется на интерпретируемом языке, то при каждом запросе загружается новый экземпляр интерпретатора. Это дорого обходится с точки зрения потребления ресурсов сервера и времени выполнения.
Сервер Apache решает эту проблему путем создания загружаемых модулей, которые, по существу, становятся частью сервера. Они загружаются динамически по мере необходимости и становятся общими