Программирование на языке Ruby

Сделаем еще одно замечание по поводу методов контроллера. Методы, предназначенные для обработки запросов на получение страницы, обычно идут в паре с шаблонами, имеющими схожее имя. Для получения конечного результата Nitro объединяет метод и шаблон. Мы видели, что Nitro может работать без контроллеров, ограничиваясь только видами. Но верно и обратное. Метод контроллера может генерировать всю страницу вообще без шаблона. Запросы на получение страниц обрабатываются в Nitro как действия (actions). Действие — это комбинация вида и методов контроллера. Внутри себя Nitro динамически создает методы действия, объединяющие то и другое. Но если какой-то компоненты недостает, ничего страшного не случится. Если у действия нет шаблона, результатом становится значение, возвращаемое методом контроллера.

Например, некоторый URL может отвечать на запрос, возвращая лишь название книги. Для этого достаточно такого метода контроллера BookController:

 def sparse(author)
  @context.content_type = 'text/plain'
  book = Book.find_by_author(author)
  book.title
 end

Если метод контроллера возвращает не HTML-документ, то следует изменить заголовок content-type, отравляемый вместе с ответом в результате присваивания @context.content_type=. (Кстати, даже если парный шаблон существует, его можно не использовать, переопределив метод render_text.)

Но откуда метод find или sparse получает аргумент? По умолчанию Nitro следует привычному для Web-приложений паттерну, согласно которому сегменты пути URL отображаются на контроллеры, методы и аргументы. Перезапустите приложение и введите такой URL: http://127.0.0.1:9999/books/find/Hal%20Fulton.

Обратите внимание, что %20 — это кодированное представление пробела в имени автора. Nitro производит декодирование еще до вызова метода find.

В общем случае отображение URL выполняется так: /controller/method/arg1. Дополнительные аргументы можно передать в виде последующих сегментов пути. Впрочем, в Nitro есть механизм настройки маршрутизации, так что вы не обязаны отражать в URL детали реализации.

19.4.3. Nitro и Og

Хотя библиотека объектно-реляционного отображения Og, используемая в паре с Nitro, рассматривалась в другом месте, наше изложение было бы неполным без демонстрации того, как просто добавить к приложению интерфейс с базой данных. Сначала настроим Og в файле run.rb:

 # Прямо перед вызовом Book.new :
 require 'og'

 Og.setup(:store => 'mysql',
  :name => 'demo',
  :user => 'root',
  :destroy => true,
  :port => 3316)

Затем изменим модель Book:

 require 'glue/timestamped'

 class Book
  is Timestamped

  property :title, String
  property :author, String

  def initialize{ values = {} )
  @title, @author = values[:title], values[:author]
  end
 end

От хранения экземпляров Book в переменных класса мы отказались. Вызовы attr_accessor заменены обращением к методу property, который служит нескольким целям. Он тоже создает методы доступа к переменным, но, кроме того, сообщает Og, что этот класс должен обладать устойчивостью. Метод initialize почти не изменяется, но затребовав файл timestamped и поместив в класс маркер is Timestamped, мы автоматически получаем атрибут update_time.

Остальные методы можно удалить, теперь они реализуются библиотекой Og. При перезапуске приложения Nitro создаст для него базу данных MySQL, а в ней — таблицу для хранения объектов Book. Так разрабатываются приложения «на чистом Ruby без SQL».

19.4.4. Решение типичных для Web-приложений задач в Nitro

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

Если вы создаете сайт с одной-двумя страницами, не так уж важно, повторяются ли многократно одна и та же разметка и текст. Но когда страниц больше, обновлять все одинаковые фрагменты вручную становится утомительно и чревато ошибками. Nitro помогает следовать принципу DRY (Don't Repeat Yourself — «Не повторяйся»), предлагая целый ряд способов повторного использования.

Простейший из них — включение файла. Пусть, например, все страницы должны иметь общий хвостовик. Можно было бы поместить его в отдельный файл шаблона и включить во все страницы, как показано ниже:

 <?include href='/footer' ?>

Сам файл footer.xinc мог бы выглядеть, к примеру, так:

 <div id='footer'>Read More Ruby Books</div>

Если в качестве значения атрибута href указан относительный путь, Nitro будет просматривать папки template, определенные для текущего контроллера. Если же путь абсолютный, то просматривается только папка template в корневом каталоге приложения.

Показанный выше способ лучше всего подходит для статического контента. Существует и иной синтаксис включения, позволяющий вставить указанный файл в вызывающий шаблон непосредственно перед компиляцией шаблона:

 <include href='/footer' />

Результат получается таким, как если бы включаемый текст был частью вызывающего шаблона.

Более сложная форма включения контента связана с элементом render:

 render href='/controller/action' />

где href — некий путь в каталоге приложения.

Процедура компиляции при включении частичных видов с помощью <render /> практически не отличается от случая полного вида. В контроллере могут быть методы, соответствующие включаемому файлу; их можно использовать для установки значений переменных экземпляра во включаемом шаблоне.

В Nitro граница между кодом шаблона и кодом на Ruby размыта. Один из примеров мы уже приводили: действие контроллера может быть «размазано» между методом и файлом шаблона, а может целиком входить туда или сюда. Другой пример — элементы Nitro (Nitro Elements), способ инкапсуляции кода и разметки в нестандартном теге, который можно использовать в видах.