- PVSM.RU - https://www.pvsm.ru -
Espresso это быстрый и лёгкий в использовании Ruby фреймворк.
Ознакомится можно тут [2].
Создавать приложения на Espresso легко и просто,
если эти приложения также легки и просты.
Но когда проект составляет несколько десятоков контроллеров, моделей, спеков итд.
и продолжает расти, без автоматизации не обойтись.
Именно для этого и был создан Enginery [1]
Установка [3] | Генерация Проекта [4] | Контролеры [5] | Actions [6] |Спеки [7] | Модели [8] | Миграции [9]
$ gem in enginery
+ $ rbenv rehash если используете rbenv
$ enginery generate:project ProjectName
Понятно но громоздко. Можно сократить до:
$ enginery g:p ProjectName
Намного лучше но также можно сократить до:
$ enginery g ProjectName
То есть если после «g» ничего не добавить, Enginery просто создаст проект.
Все команды выше создадут папку «ProjectName/» с готовым к использованию приложением внутри.
Можно также создать приложение в текущей папке, для этого просто пропускаем имя проекта, сокращая команду до:
$ enginery g
Единственное условие — текущая папка должна быть пустой.
Если проект нуждается в базе данных, добавляем orm: опцию:
$ enginery g orm:SomeORM
Поддерживаемые ORM: ActiveRecord, DataMapper, Sequel.
$ enginery g orm:ActiveRecord # or $ enginery g orm:DataMapper # or $ enginery g orm:Sequel
Имя ORM можно сократить:
# ActiveRecord $ enginery g orm:ar # DataMapper $ enginery g orm:dm # Sequel $ enginery g orm:sq
Для удобства, orm: можно сократить до o:
$ enginery g o:ar
По умолчанию проект будет использовать ERB engine.
Чтобы это изменить добавляем опцию engine:
$ enginery g engine:Haml # or $ enginery g engine:Slim # etc.
Важно — имя движка нужно передать целиком с соблюдением регистра.
Для удобства, engine: можно сократить до e:
$ enginery g e:Slim
Базовая структура приложения:
- base/
| - models/
| - views/
| - controllers/
| - helpers/
| - specs/
| - migrations/
| - boot.rb
| - config.rb
` - database.rb
- config/
| - config.yml
` - database.yml
- public/
| - assets/
| - app.css
` - app.js
- tmp/
- var/
| - db/
| - log/
` - pid/
- Rakefile
- Gemfile
- app.rb
- config.ru
оглавление [10]↑
Для генерации контролеров используем g:controller или сокращённый вариант — g:c
$ enginery g:c Foo
Созданные таким образом контролеры будут использовать настройки проекта.
То есть если создать проект который использует Haml, все контролеры будут использовать Haml
Если нужно создать контролер который использует собственные настройки просто передаём эти настройки при генерации контролера:
$ enginery g:c Bar e:Slim
Таким образом Foo контролер будет использовать Haml engine тогда как Bar будет использовать Slim.
По умолчанию контролеры будут обслуживать URL созданный из имени контролера:
Foo — /foo
FooBar — /foo_bar
Foo::Bar — /foo/bar
итд.
Чтобы это изменить нужно передать опцию route:
$ enginery g:c Foo route:/
теперь Foo будет обслуживать "/" URL.
Для удобства, route: можно сократить до r:
$ enginery g:c Foo r:/some-url
Если нужно создать несколько контролеров, передаём имена одной строкой, разделённые пробелом:
$ enginery g:c Foo Bar Baz
Если контролер находится внутри пространства имён, передаём имя вместе с пространством:
$ enginery g:c Forum::Posts
$ cat base/controllers/forum/posts_controller.rb
module Forum
class Posts < E
end
end
оглавление [10]↑
При генерации контролера также генерируется index action который будет обслуживать корневой адрес контролера.
Но обычно этого не достаточно.
Чтобы создать новые action-ы используем g:route или просто g:r
$ enginery g:r Page edit
где Page имя контролера а edit имя action-а.
Созданные таким образом action-ы будут использовать настройки контролера.
Чтобы создать action с собственными настройками передаём их при генерации action-а:
$ enginery g:r Page read e:Haml
Таким образом edit action созданный ранее будет использовать ERB engine а read — Haml.
Можно также создать несколько action-ов одной командой, разделив имена пробелом:
$ enginery g:r Foo a b c
оглавление [10]↑
Спеки создаются автоматически при генерации action-ов.
$ enginery g:r Page edit
кроме action-а это команда создаст файл «base/specs/page/edit_spec.rb». Открываем и добавляем юнит-тесты.
Enginery использует связку Specular [11] / Sonar [12] для тестирования и говорит добро пожаловать коммитерам которые хотят добавить поддержку других тест-фреймворков.
Чтобы протестировать все контролеры используем $ rake test или просто $ rake
Чтобы протестировать Foo контролер используем $ rake test:Foo
Чтобы протестировать bar action Foo контролера используем $ rake test:Foo#bar
Если контролер находится внутри пространства имён, передаём имя вместе с пространством не взирая на "::"
$ rake test:Forum::Posts
оглавление [10]↑
Для генерации моделей используем g:model или просто g:m
$ enginery g:m Foo
При генерации моделей используются настройки проекта.
Приложение использующее ActiveRecord:
$ enginery g:m Foo $ cat base/models/foo.rb class Foo < ActiveRecord::Base end
Приложение использующее DataMapper:
$ enginery g:m Foo $ cat base/models/foo.rb class Foo include DataMapper::Resource property :id, Serial end
Приложение использующее Sequel:
$ enginery g:m Foo $ cat base/models/foo.rb class Foo < Sequel::Model end
Если нужно создать несколько моделей, передаём имена одной строкой, разделённые пробелом:
$ enginery g:m Foo Bar Baz
Если модель находится внутри пространства имён, передаём имя вместе с пространством:
$ enginery g:m Forum::Post
создаст «base/models/forum/post.rb» файл.
оглавление [10]↑
Миграции призваны контролировать/регулировать структуру баз данных.
С их помощью можно создавать/изменять целые таблицы или отдельные столбцы.
Но большая их прелесть в том что они сами знают как «откатиться» назад.
При генерации моделей также создаётся файл миграции призванный инициализировать модель, то есть создать соответствующую таблицу в базе данных.
$ enginery g:m Page
кроме модели это команда создаст «base/migrations/[n].[timestamp].initializing-Page-model.rb» файл,
где [n] это порядковый номер миграции а [timestamp] время создания.
Чтобы инициализировать Page модель нужно выполнить «up» инструкции:
$ enginery migrate:up 1
где 1 это порядковый номер миграции.
В нашем случае это создаст таблицу для Page модели.
Чтобы «откатить» изменения нужно выполнить «down» инструкции:
$ enginery migrate:down 1
Автоматически созданная миграция удобна для инициализации модели, но не более.
Чтобы сделать её более полезной, задаём имена столбцов при генерации модели:
$ enginery g:m Page column:name column:about:text
Теперь миграция создаст таблицу с двумя столбцами.
Удобно но не практично потому что обычно заказчик выдаёт свои грандиозные идеи уже после инициализации модели.
Тогда мы просто создаём новую миграцию которая создаст новые или изменит существующие столбцы.
Добавляем новый столбец:
$ enginery migration add-colors model:Page column:colors --- Page model - generating "add-colors" migration --- Serial Number: 2
создана миграция с порядковым номером 2.
Чтобы привести её в действие выполняем «up» инструкции:
$ enginery migrate:up 2
это создаст новый VARCHAR столбец с именем colors.
Если на второй день грандиозная идея оказалась просто идеей, «откатится» назад можно выполнив «down» инструкции:
$ enginery migrate:down 2
и столбец с именем colors будет удалён.
Если нужно изменить тип столбца, используем update_column:column_name:new_type
$ enginery m change-colors-to-text model:Page update_column:colors:text --- Page model - generating "change-colors-to-text" migration --- Serial Number: 3
создана миграция с порядковым номером 3.
При выполнении «up» инструкции, тип столбца «colors» изменится с String на Text.
При выполнении «down» инструкции, тип столбца «colors» изменится обратно с Text на String.
Если нужно переименовать столбец, используем rename_column:column_name:new_name
$ enginery m rename_colors_to_color model:Page rename_column:colors:color --- Page model - generating "rename_colors_to_color" migration --- Serial Number: 4
создана миграция с порядковым номером 4.
При выполнении «up» инструкции, «colors» будет переименован в «color».
При выполнении «down» инструкции, «color» будет переименован обратно в «colors».
Когда нужно выполнить несколько миграций используем диапазон(N-M) или список(N M).
$ enginery migrate:up 2-5
будут выполнены миграции с 2 по 5 включительно.
$ enginery migrate:up 2 4 6
будут выполнены миграции с 2, 4 и 6.
Важно отметить что порядок выполнения определяется автоматически и зависит от направления миграции.
Пример: диапазон 2-5 при «up» направлении: 2 > 3 > 4 > 5
Пример: диапазон 2-5 при «down» направлении: 5 > 4 > 3 > 2
Пример: список 2 6 4 при «up» направлении: 2 > 4 > 6
Пример: список 2 6 4 при «down» направлении: 6 > 4 > 2
Автор: slivu
Источник [13]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/ruby/29079
Ссылки в тексте:
[1] Image: https://github.com/espresso/enginery
[2] тут: http://habrahabr.ru/post/139872/
[3] Установка: #install
[4] Генерация Проекта: #projects
[5] Контролеры: #controllers
[6] Actions: #actions
[7] Спеки: #specs
[8] Модели: #models
[9] Миграции: #migrations
[10] оглавление: #top
[11] Specular: https://github.com/slivu/specular
[12] Sonar: https://github.com/slivu/sonar
[13] Источник: http://habrahabr.ru/post/172255/
Нажмите здесь для печати.