Хэл Фултон - Программирование на языке Ruby
lastacc = CGI::Cookie.new("kabhi",
"lastaccess=#{Time.now.to_s}")
cgi = CGI.new("html3")
if cgi.cookies.size < 1
cgi.out("cookie" => lastacc) do
"Hit refresh for a lovely cookie"
end
else
cgi.out("cookie" => lastacc) do
cgi.html do
"Hi, you were last here at: "+
"#{cgi.cookies['kabhi'].join.split(' = ')[1]}"
end
end
end
Здесь создается кук "kabhi", ключ которого "lastaccess" содержит текущее время. Если у браузера уже был такой кук, то выводится его значение. Куки хранятся в хэше, который является переменной экземпляра в классе CGI. Каждый кук может содержать несколько пар ключ-значение, поэтому при доступе к куку по имени вы получаете массив.
19.1.4. Сеансы пользователей
Куки — это хорошо, если вам нужно сохранить простые данные и вы не прочь возложить на браузер заботу об их хранении. Но часто предъявляются более жесткие требования. Что если нужно сохранить много данных и вы не хотите гонять их «взад-вперед» при каждом запросе? К тому же данные могут быть секретными, так что доверять их хранение браузеру нежелательно.
В таких случаях можно воспользоваться классом CGI::Session. Он аналогичен классу CGI::Cookie в том смысле, что значения хранятся в структуре, напоминающей хэш.
require "cgi"
require "cgi/session"
cgi = CGI.new("html4")
sess = CGI::Session.new(cgi, "session_key" => "a_test",
"prefix" => "rubysess.")
lastaccess = sess["lastaccess"].to_s
sess["lastaccess"] = Time.now
if cgi['bgcolor'][0] =~ /[a-z]/
sess["bgcolor"] = cgi['bgcolor']
end
cgi.out do
cgi.html do
cgi.body ("bgcolor" => sess["bgcolor"]) do
"Фон этой страницы" +
"изменяется в зависимости от значения 'bgcolor'," +
"хранящегося в сеансе каждого пользователя." +
"Время последнего доступа: #{lastaccess}"
end
end
end
Если обратиться к URL /thatscript.cgi?bgcolor=red, то фоновый цвет страницы у данного пользователя станет красным и останется таким до тех пор, пока он не обратится к такому же URL, но с другим значением параметра "bgcolor". При создании объекта CGI::Session указываются объект CGI и набор параметров в хэше. Необязательный параметр session_key определяет ключ, с помощью которого браузер будет идентифицировать себя при каждом запросе. Сеансовые данные хранятся во временном файле, своем для каждого сеанса, а параметр prefix задает строку, с которой должно начинаться имя файла, чтобы проще было опознать все такие файлы в файловой системе сервера.
Классу CGI::Session пока недостает многих возможностей, в частности умения хранить объекты, отличные от String, организации общего хранилища сеансовых данных для нескольких серверов и пр. К счастью, уже готов подключаемый механизм database_manager, так что некоторые из этих функций нетрудно добавить. Если вы придумаете что-нибудь интересное в отношении класса CGI::Session, не забудьте поделиться с сообществом.
19.2. FastCGI
Чаще всего CGI критикуют за то, что при каждом запросе создается новый процесс, и это заметно снижает производительность. Невозможность сохранять в памяти объекты между последовательными запросами также не украшает дизайн системы. Для разрешения этих проблем была создана технология FastCGI.
По сути дела, FastCGI — это определение и программная реализация протокола. Обычно она реализуется в надстройки над Web-сервером, например модуля в случае сервера Apache. FastCGI позволяет работающему внутри процесса компоненту перехватывать HTTP-запросы и направлять их через сокет другому процессу, работающему в течение длительного времени. По сравнению с традиционным порождением новых процессов это существенно ускоряет работу. Кроме того, программист получает возможность оставить данные в памяти и найти их там при обработке следующего запроса.
Серверы, адаптированные для работы с FastCGI, реализованы на многих языках, в том числе на Ruby. Эли Грин (Eli Green) написал целиком на Ruby модуль (он есть в архиве RAA), который реализует протокол FastCGI и упрощает разработку FastCGI-программ.
Не вдаваясь в детали реализации, мы представили в листинге 19.1 пример приложения. Как видите, он повторяет функциональность предыдущего примера.
Листинг 19.1. Пример FastCGIrequire "fastcgi"
require "cgi"
last_time = ""
def get_ramblings(instream)
# He слишком красивый способ извлечь значение из первой пары
# имя-значение. CGI сделал бы это за нас.
data = ""
if instream != nil
data = instream.split("&")[0].split(" = ")[1] || ""
end
return CGI.unescape(data)
end
def reverse_ramblings(ramblings)
if ramblings == nil then return "" end
chunks = ramblings.split(/s+/)
chunks.reverse.join(" ")
end
server = FastCGI::TCP.new('localhost', 9000)
begin
server.each_request do |request|
stuff = request.in.read
out = request.out
out << "Content-type: text/htmlrnrn"
out << <<-EOF
<html>
<head><titlе>Отражатель текста</title></head>
<h1>sdrawkcaB txeT</h1>
<i>Вы перед этим сказали: #{last_time}</i><BR>
<b>#{reverse_ramblings(get_ramblings(stuff))}</b>
<form method="POST" action="/fast/serv.rb">
<textarea name="ramblings">
</textarea>
<input type="submit" name="submit">
</form>
</body></html>
EOF
last_time = get_ramblings(stuff)
request.finish
end
ensure
server.close
end
Сразу же бросается в глаза (если вы читали предыдущий раздел) то, что в FastCGI приходится вручную делать кое-какие вещи, которые были не нужны при работе с библиотекой CGI. Во-первых, «зашивание» в код экранированного HTML-кода. Во-вторых, метод get_ramblings, который сам разбирает входные данные и возвращает нужное значение. Кстати, этот код будет работать только для POST-запросов — еще одно удобство, утраченное с отказом от библиотеки CGI.
Но вместе с тем у FastCGI есть и достоинства. Мы не проводили замеров, но — как следует из самого названия — FastCGI быстрее CGI. Вместо накладных расходов на создание нового процесса мы просто открываем соединение с портом 9000 на локальной машине (FastCGI::TCP.new('localhost', 9000)). Кроме того, в переменной last_time хранится часть состояния сеанса — вещь, невозможная в традиционной технологии CGI.
Отметим также, что эти библиотеки можно до определенного предела «смешивать». Вспомогательные функции из cgi.rb, например метод CGI.escapeHTML, можно использовать автономно (не делая библиотеку основой приложения). Тогда предыдущий пример оказался бы несколько проще для восприятия.
19.3. Ruby on Rails
В сообществе пользователей Ruby одним из самых широко известных каркасов для Web является Ruby on Rails (или просто Rails). Его автор Дэвид Хайнемайер Хансон (David Heinemeier Hansson).
В каркасе Rails широко используются динамические свойства Ruby. У него также есть собственная философия, направленная на быструю разработку Web-приложений.
Rails хорошо известен и прекрасно документирован. В этой книге мы рассмотрим его лишь поверхностно.
19.3.1. Принципы и техника
Каркас Rails построен на основе паттерна Модель-Вид-Контроллер (Model-View-Controller — MVC). Каждое приложение естественно разбивается на модели (моделирующие предметную область), виды (с помощью которых информация представляется пользователю и организуется возможность взаимодействия) и контроллеры (играющие роль арбитров между моделями и видами).
В основу поведения Rails как каркаса положены определенные принципы. Один из них — «принцип минимизации кода»: не пишите код для связывания одного с другим, если такое связывание можно организовать автоматически.
С ним также связан принцип «примата соглашений над конфигурацией». Придерживаясь ряда заранее оговоренных стилей кодирования и именования, можно обойтись почти без конфигурирования (и приблизиться к идеальной среде с «нулевым конфигурированием»).
Rails прекрасно справляется с автоматизацией не слишком сложных задач. Если это имеет смысл, он сам генерирует код, избавляя программиста от необходимости писать его вручную.
Web-приложения часто хранят данные в базе, и Rails обеспечивает бесшовную интеграцию с базой данных. У Web-каркасов наблюдается тенденция проявлять «склонность» к какому-то конкретному объектно-реляционному отображению (object-relational mapper, ORM), и Rails — не исключение. Стандартным для Rails является отображение ActiveRecord, которое мы рассматривали в главе 10.
