Чтение онлайн

ЖАНРЫ

Программирование на языке Ruby
Шрифт:

Тем самым производится связывание списка

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>

@details

 </body>

</html>

Об IOWA можно было бы рассказывать еще долго. Для получения дополнительной информации зайдите на домашнюю страницу IOWA или на страницу проекта IOWA на сайте RubyForge .

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 решает эту проблему путем создания загружаемых модулей, которые, по существу, становятся частью сервера. Они загружаются динамически по мере необходимости и становятся общими для всех зависящих от них сценариев. Одним из таких модулей является

mod_ruby
(имеется в архиве RAA).

Модуль

mod_ruby
реализует несколько директив Apache, в частности:

• 

RubyRequire
определяет одну или несколько потребных библиотек;

• 

RubyHandler
определяет обработчик для объекта Ruby;

• 

RubyPassEnv
определяет имена переменных окружения, передаваемых сценариям;

• 

RubySetEnv
устанавливает переменные окружения;

• 

RubyTimeOut
задает величину тайм-аута для Ruby-сценариев;

• 

RubySafeLevel
задает уровень безопасности $SAFE;

• 

RubyKanjiCode
устанавливает кодировку символов для Ruby.

В состав пакета входят также классы и модули Ruby для взаимодействия с Apache. Модуль

Apache
(здесь слово «модуль» употребляется в смысле, принятом в Ruby) включает несколько функций, например
server_version
и
unescape_url
; там же определены классы
Request
и
Table
.

Поделиться с друзьями: