vsuhachev

Никак.
Не надо писать сайты на perl, тем более, что

Никогда раньше с перлом дела не имела.

Вообще эту логику нужно запихнуть в модель.

Если у вас дерево категорий могу порекомендовать гем awesome_nested_set. Он организует работу с деревом.

Authlogic - если нужна гибкость.
Но мне кажется, вы просто поняли, что такое девайс. Он не решает ни одну из задач, что вы привели, он занимается аутентификацией.
CanCan (или уже CanCanCan для 4 рельс) занимается авторизацией, но не занимается ролями
Роли можно сделать самому (если все просто), например, как предлагает канкан - https://github.com/ryanb/cancan/wiki/Role-Based-Au...
или использовать разные гемы railscasts.com/episodes/188-declarative-authorizat...

если ваш, так называемый, backoffic и клиент - нечто большее, чем права доступа по ролям, то вообще не понимаю, что это, и каким боком к девайсу.

Аутентификация и авторизация - настолько популярная тема, что вы точно не сделаете ничего качественно нового

То есть разделы динамические например категории из базы?
Тогда как по другому, если ещё хотите иногда менять картинку то хранить путь к картинке в базе.

А если всё фиксировано например сделать отдельный layout для определённого контроллера где прописать другую фоновую картинку а в контроллере использовать этот layout

class CategoriesController < ApplicationController
  layout 'имя лайаута из папки layout'
end

Тем более, что модель всё равно вы уже подгружаете значит лишнего запроса не будет.

Если фоновые картинки менять не будут то можно заранее их положить в app/assets/images
чтоб у картинок были имена модели или категории.
А если будут меняться часто или категории создаются динамически из админки например - не вижу другого выхода как хранить путь в базе и заливая задавать его и иметь в моделе.

mount_uploader :background, BackgroundUploader

Осторожно! Не традиционный взгляд на вопрос.

Любой сайт работает по схеме "HTTP-запрос - HTTP-ответ".
Какая технология будет отвечать на запросы в целом не очень важно, а если для конкретных запросов это станет важно, ее можно заменить.

Нужно продумать, как будет работать приложение с т.з. бизнеса и с т.з пользователя.
Получите, условно, кучу запросов (url'ов с параметрами) и ответов (экранов, страниц), сгруппированных по функциям или как-то еще.

Затем ищите ответственных людей и даете им на проработку и реализацию те или иные части проекта.

Они сами выберут подходящую технологию. Вам зачем об этом думать?
Оценивайте все с позиций денег, времени и качества.

Что-то может обсчитывать Руби, другой функционал может быть сделан на PHP, потому что его можно сделать за 2 дня. Что-то вообще будет отдаваться как статика.

Главное - это хороший проект (персонажи, сценарии, экраны, ТЗ) и люди на участках, будь это один человек или десять.

has_many преобразуется в набор методов. Вы можете попробовать удалить их, но их довольно много. Да и вообще это грязный патчинг, лучше таким не заниматься.

Расскажите о контексте задачи. Возможно можно решить вашу проблему много проще.

Главный вопрос — это зачем Вам нужны статические типы в Вашем приложении. Я пишу на TypeScript и мне, например, очень не нравится то, что приходится на каждый чих изменения модели данных добавлять поле в модель или ставить тип any, причем указывать это явно. И даже хуже. Если какой-нибудь метод в качестве параметра принимает массив, в котором могут быть разные типы, то необходимо явно его кастовать к типу any[].
Я соггласен, что компиляция — это хорошо. Статическая типизация — тоже хорошо. Однако мое сугубое ИМХО, что к скриптовым языкам нужно относиться со скриптовым мышлением.
Возможно, если в том же WebStorm 7.0 значительно улучшилась поддержка TypeScript, мое негодование будет меньшим, либо сойдет на нет.
Однако, TypeScript предлагает писать в стиле того же шарпа без такого же инструмента, как решарпер.
Минус в сторону TypeScript и плюс в CoffeeScript — меньший объем кода, символов и тд.

Личное мнение, основанное исключительно на ощущениях — CoffeeScript няшечка, TypeScript монструозен.
Если писать на том же AngularJS, ИМХО TypeScript бессмысленен. Хотя при большом желании можно и это достаточно успешно делать.

Как советовал человек выше — посмотрите livescript, на мой беглый взгляд он даже больше няша, чем Coffee. Однако сразу оговорю, что ни строчки кода на LiveScript я не писал, впечатление сугубо от внешнего вида и его возможностей.

Парсил тут