Rails 3.1 Ресурсы: в чем преимущество таблиц стилей для каждого контроллера?

Question

Просто возиться с Rails 3.1, которая разделяет таблицы стилей через контроллеры.

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

Итак, что мне не хватает? Что такое "классные вещи": ​​таблицы стилей для каждого контроллера?

Answer 1

Я нахожу обсуждение очень интересным, оно напоминает мне старые времена, когда люди подозревали, что объектная ориентация имеет какую-то ценность.Для меня есть много общего:

Слева от объекта-ориентации, справа от мира HTML:

• класс - файл CSS на контроллер
• метод - селектор, например, с #id
• суперкласс - импорт, например, в файлы инфраструктуры компаса (@import "compass/utilities/tables/scaffolding";)

Мы научились при работе с веб-приложениями использовать все файлыдля всех представлений и используйте разные id s для разных представлений, чтобы обозначить, что они должны отображаться по-разному.Используя таблицу стилей для каждого контроллера и добавляя в ресурсы возможность включить эту таблицу стилей (только) для правильного контроллера, вы можете использовать те же #id с другими правилами, чтобы вы могли обмениваться макетами, которые будут отображаться затемпо-разному.

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

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

Answer 2

То, что он существует в строительных лесах, не означает, что он обязательно полезен - в лучшем случае IMO очень нишевый, возможно, если у вас есть какой-то очень целевой CSS для контроллеров.

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

Answer 3

Из объяснения, которое я слышал, упростить организацию ресурсов

по сути, все они в итоге объединяются и загружаются, так что на самом деле это просто для организации.

Answer 4

Несмотря на то, что таблицы стилей на контроллер имеют потенциальную ценность в зависимости от создаваемого вами приложения, оно, конечно, не подходит для каждого приложения. Имейте в виду, что поведение «все таблицы стилей скомпилированы вместе» является просто значением по умолчанию - вы можете изменить основной файл манифеста таблицы стилей, чтобы включить в него то, что вам нужно, или иметь много разных манифестов, чтобы разные скомпилированные файлы работали. Проверьте Railscast на конвейере активов , если вам нужна дополнительная информация.

Answer 5

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

В работе эти файлы не имеют значения, потому что все они собираются вместе.В старые добрые времена у вас было несколько запросов и, следовательно, снижение производительности.

Проблема возникает, когда вы хотите максимально использовать каскад и оптимизировать правила для всего сайта, такие как подход OOCSS.

Я предпочитаю структурировать свой CSS вокруг общего файла сброса, файла макета и оттуда работать, накапливать и реорганизовывать на ходу.

Распределение вещей по многим файлам все время выводит их из-под носа и может (ИМХО) привести к менее дисциплинированному подходу к структурированию вашего CSS.