Rails 3.1资产：每个控制器样式表有什么优势？

Question

只是搞乱Rails 3.1，它通过控制器分离样式表。

我认为这有好处，但我很难确定它们是什么。似乎我必须在每个样式表中包含scss变量/ mixins，找到我想要编辑的元素需要更多的时间，而且我的几个样式无论如何都适合特定的控制器。

那么，我错过了什么？什么是“酷的东西”：每个控制器样式表？

Answer 1

仅仅因为它存在于脚手架中并不意味着它必然有用 - IMO充其量只是非常小众，也许如果你有一些非常有针对性的控制器CSS。

我认为每个控制器样式表的一般用法很少见，但我很想听到其他意见。

Answer 2

我发现讨论非常有趣，它让我想起过去人们怀疑面向对象有任何价值的日子。对我来说有很多相似之处：

在面向对象的左侧术语中，在HTML世界的右侧：

• class - 每个控制器的CSS文件
• 方法 - 选择器，例如#id
• 超类 - 导入到例如罗盘框架文件（@import "compass/utilities/tables/scaffolding";）

我们在进行Web应用程序时接受培训，以便为所有视图使用所有文件，并对不同视图使用不同的id来表示它们应以不同方式呈现。通过使用每个控制器的样式表，并向权限添加包含该样式表（仅）用于右侧控制器的选项，您可以使用具有不同规则的相同#id，因此您可以共享将成为的布局然后以不同的方式呈现。

一个简单的例子可能是每个控制器样式表表示背景颜色，因此通过调用来自不同控制器的操作，背景颜色显示您正在使用的上下文。 （我不是说这对用户来说是一个聪明的想法或好处，但在技术上是可行的。）

所以我认为这种额外的技术本身就有价值，但我们必须学习它有什么用处。

Answer 3

根据我所听到的解释，它可以更轻松地组织资源

基本上它们都会在最后得到组合并加载在一起，所以真的，这只是为了组织。

Answer 4

这将取决于您正在优化的内容。默认方法允许您对样式进行分区，并将它们放在与当前作用域（控制器）匹配的文件中。这与The Rails做事方式一致。

在制作中，这些文件并不重要，因为它们都捆绑在一起。在过去的好时光中，你会遇到多个请求，从而影响性能。

当您想要最大限度地使用级联并优化整个站点的规则（例如OOCSS方法）时，就会出现问题。

我更喜欢围绕一个常见的重置文件，布局文件和工作来构建我的CSS，然后构建和重构。

将事物分散在许多文件中会让事情一直在你的鼻子底下，并且可能（恕我直言）会导致构建CSS的程度较低的方法。

Answer 5

虽然每个控制器的样式表具有基于您正在构建的应用程序的潜在价值，但它当然不适合每个应用程序。请记住，“所有样式表一起编译”的行为只是一个默认行为 - 您可以更改主样式表清单文件以包含您想要的内容，或者有许多不同的清单来生成不同的编译文件。如果您正在寻找更多信息，请查看the Railscast on the asset pipeline。