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/html\r\n\r\n"

out << <<-EOF

sdrawkcaB txeT

Вы перед этим сказали: #{last_time}


#{reverse_ramblings(get_ramblings(stuff))}

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, можно использовать автономно (не делая библиотеку основой приложения). Тогда предыдущий пример оказался бы несколько проще для восприятия.

В сообществе пользователей Ruby одним из самых широко известных каркасов для Web является Ruby on Rails (или просто Rails ). Его автор Дэвид Хайнемайер Хансон (David Heinemeier Hansson).

В каркасе Rails широко используются динамические свойства Ruby. У него также есть собственная философия, направленная на быструю разработку Web-приложений.

Rails хорошо известен и прекрасно документирован. В этой книге мы рассмотрим его лишь поверхностно.

Каркас Rails построен на основе паттерна Модель-Вид-Контроллер (Model-View-Controller — MVC). Каждое приложение естественно разбивается на модели (моделирующие предметную область), виды (с помощью которых информация представляется пользователю и организуется возможность взаимодействия) и контроллеры (играющие роль арбитров между моделями и видами).

В основу поведения Rails как каркаса положены определенные принципы. Один из них — «принцип минимизации кода»: не пишите код для связывания одного с другим, если такое связывание можно организовать автоматически.

С ним также связан принцип «примата соглашений над конфигурацией». Придерживаясь ряда заранее оговоренных стилей кодирования и именования, можно обойтись почти без конфигурирования (и приблизиться к идеальной среде с «нулевым конфигурированием»).

Rails прекрасно справляется с автоматизацией не слишком сложных задач. Если это имеет смысл, он сам генерирует код, избавляя программиста от необходимости писать его вручную.

Web-приложения часто хранят данные в базе, и Rails обеспечивает бесшовную интеграцию с базой данных. У Web-каркасов наблюдается тенденция проявлять «склонность» к какому-то конкретному объектно-реляционному отображению (object-relational mapper, ORM), и Rails — не исключение. Стандартным для Rails является отображение ActiveRecord, которое мы рассматривали в главе 10.

Базы данных описываются в файле config/database.yaml— одном из немногих необходимых конфигурационных файлов (конечно же, в формате YAML). В нем перечислены три разных базы данных: для разработки, для тестирования и для промышленной эксплуатации. На первый взгляд, это перебор, но в действительности такая схема оказывается очень удобной.

Rails генерирует для вас пустые модели и контроллеры. В ходе редактирования моделей вы определяете связи между таблицами базы данных с помощью таких методов, как has_manyи belongs_to(на самом деле их гораздо больше). Поскольку между моделями и таблицами есть соответствие, то написанный вами код заодно определяет и связи между самими моделями. Для контроля данных служат такие методы, как validates_presence_of(проверяет, что данные присутствуют) и validates_uniqueness_of(проверяет, что данные уникальны).

В результате создания приложения Rails командой вида rails appnameвы получаете каталог appnameс такой структурой:

арр

controllers

helpers

models

views

config

db

doc

lib

log

public

script

test

vendor

Большая часть кода находится в каталоге арр. Как видите, сама его структура следует паттерну MVC.

Схемы баз данных находятся в каталоге db. Инкрементные файлы миграции тоже попадут сюда.

В Rails есть концепция «обстраивания» (scaffolding), которая очень упрощает жизнь. Если ввести команду script/generate scaffold Product( Product— имя модели), то для таблицы Products(обратите внимание на множественное число) будет сгенерирована функциональность «создать-обновить-удалить».

Можно обстроиться и не генерируя никакой код, достаточно вызвать внутри контроллера Productметод scaffold:

class ProductController < ActiveRecord::Base

scaffold :product

end

Здесь мы достигаем той же цели, но не записываем никакой код на диск. Оба способа допустимы. Конечно, в результате обстраивания создаются страницы ввода/обновления, которые вполне функциональны, но не слишком красивы; почти всегда вы захотите заменить их чем-то более симпатичным. Тем не менее такая техника взаимодействия с базой данных полезна, особенно на этапе разработки.

В старых версиях Rails расхождение между ActiveRecord и базой данных было более существенным. Недавно появившаяся концепция миграции делает управление базой данных проще. То же касается и уже существующих в базе данных таблиц, работать с которыми было трудно; сейчас можно создать файл schema.rb, в котором будет перечислены все существующие таблицы (см. также rake tasks db:schema:loadи db:schema:dump).

В Rails встроена серьезная поддержка тестирования. Обратите внимание на каталог test, который создается для каждого нового приложения. Он заполняется по мере развития приложения; вы можете (и должны) добавлять тесты по ходу создания новой функциональности.

По принятому в Rails соглашению, автономные тесты служат для тестирования моделей, а функциональные — для тестирования контроллеров. Этим объясняется наличие подкаталогов unitи functionalв каталоге test. (Вне контекста Ruby on Rails эти термины используются несколько иначе.)