dynamic_assets 0.3.0 → 0.3.1
Sign up to get free protection for your applications and to get access to all the features.
- data/README.rdoc +62 -33
- data/lib/dynamic_assets/core_extensions.rb +12 -0
- data/lib/dynamic_assets/reference.rb +4 -1
- metadata +5 -5
data/README.rdoc
CHANGED
@@ -82,6 +82,7 @@ dynamically is useful enough that multiple people have thought of implementing i
|
|
82
82
|
- app:
|
83
83
|
- reset
|
84
84
|
- application
|
85
|
+
- sidebar
|
85
86
|
- admin
|
86
87
|
- reset
|
87
88
|
- application
|
@@ -104,9 +105,20 @@ dynamically is useful enough that multiple people have thought of implementing i
|
|
104
105
|
<%= javascript_asset_tag :base %>
|
105
106
|
|
106
107
|
wherever you want your script tags to appear. The symbol argument to each
|
107
|
-
helper is the name of the group you defined in assets.yml.
|
108
|
-
|
109
|
-
like the cowboy in <i>Mulholland Dr.</i
|
108
|
+
helper is the name of the group you defined in assets.yml. Each helper will
|
109
|
+
generate one tag if the assets are combined or multiple tags if they're
|
110
|
+
not, much like the cowboy in <i>Mulholland Dr.</i>. For example, if your
|
111
|
+
assets.yml says to combine asset groups, stylesheet_asset_tag(:base) will
|
112
|
+
insert this one tag into your page:
|
113
|
+
|
114
|
+
<link href="/assets/stylesheets/base_v2.css?1302901941" media="screen" rel="stylesheet" type="text/css" />
|
115
|
+
|
116
|
+
but if your assets.yml says not to combine them, stylesheet_asset_tag(:base)
|
117
|
+
will insert one tag per CSS file:
|
118
|
+
|
119
|
+
<link href="/assets/stylesheets/reset.css?1302901941" media="screen" rel="stylesheet" type="text/css" />
|
120
|
+
<link href="/assets/stylesheets/application.css?1302901941" media="screen" rel="stylesheet" type="text/css" />
|
121
|
+
<link href="/assets/stylesheets/sidebar.css?1302901900" media="screen" rel="stylesheet" type="text/css" />
|
110
122
|
|
111
123
|
|
112
124
|
== Variables for ERB
|
@@ -132,18 +144,18 @@ Now in app/assets/stylesheets/application.css.erb you could do this:
|
|
132
144
|
}
|
133
145
|
|
134
146
|
|
135
|
-
== Static
|
147
|
+
== Static Image URLs Embedded in CSS
|
136
148
|
|
137
|
-
|
138
|
-
|
139
|
-
|
149
|
+
Suppose you install a JavaScript plugin that comes with a stylesheet and
|
150
|
+
some images. The stylesheet, thing.css, may reference one of its images
|
151
|
+
like this:
|
140
152
|
|
141
153
|
div.thing {
|
142
154
|
background: url(fancy_background.png);
|
143
155
|
}
|
144
156
|
|
145
157
|
Browsers will find the image by looking in the same URL path as the
|
146
|
-
stylesheet, so in a typical Rails environment, you might add these
|
158
|
+
stylesheet, so in a typical Rails environment, you might add these
|
147
159
|
files to your app as public/stylesheets/thing.css and
|
148
160
|
public/stylesheets/fancy_background.png.
|
149
161
|
|
@@ -156,6 +168,15 @@ and the processor will make sure the embedded URL is turned into a fully
|
|
156
168
|
qualified one that will allow the browser to find
|
157
169
|
/stylesheets/thing/fancy_background.png.
|
158
170
|
|
171
|
+
Or, if you prefer to keep your third-party images cleanly separated from
|
172
|
+
your own, you could put them in a subdirectory:
|
173
|
+
|
174
|
+
app/assets/stylesheets/third-party/thing.css
|
175
|
+
public/stylesheets/third-party/thing/fancy_background.png
|
176
|
+
|
177
|
+
DynamicAssets expects the images that belong to an asset to be in a
|
178
|
+
parallel directory structure under public/stylesheets.
|
179
|
+
|
159
180
|
== CSS Media Types
|
160
181
|
|
161
182
|
If you have different CSS files for printing than for the screen, create
|
@@ -164,37 +185,44 @@ separate groups in your assets.yml. Then include both groups in your layout:
|
|
164
185
|
<%= stylesheet_asset_tag :app %>
|
165
186
|
<%= stylesheet_asset_tag :app_printing, :media => "print" %>
|
166
187
|
|
188
|
+
If no :media attribute is supplied, stylesheet_asset_tag will use "screen".
|
189
|
+
|
190
|
+
|
167
191
|
== Performance
|
168
192
|
|
169
193
|
In production, assets can typically be cached aggressively. Like Rails,
|
170
194
|
dynamic_assets adds a URL parameter to the asset path that will change
|
171
195
|
if any of the underlying assets is modified, forcing clients to reload
|
172
|
-
the asset.
|
196
|
+
the asset. With action caching and/or an external cache like Varnish or
|
197
|
+
a CDN, dynamic assets are quite speedy because you generate them rarely.
|
173
198
|
|
174
|
-
But
|
175
|
-
sweet spot for my dev
|
176
|
-
minify or cache them (
|
199
|
+
But during development they can be annoying <em>if</em> you set your
|
200
|
+
environment to maximum slowness. The sweet spot for my dev configuration
|
201
|
+
is to combine assets but not to minify or cache them (as shown in the
|
202
|
+
assets.yml above). Here's why:
|
177
203
|
|
178
|
-
===
|
204
|
+
=== Set assets not to be minified in development, usually
|
179
205
|
|
180
|
-
I usually leave minification off in development, because it
|
181
|
-
overhead to each asset request, and it makes
|
182
|
-
need to debug them (like with Firebug). In production, caching
|
183
|
-
the overhead
|
184
|
-
unless you're some
|
206
|
+
I usually leave minification off in development, because it can add some
|
207
|
+
overhead to each asset request, and it makes the assets difficult to read
|
208
|
+
if you need to debug them (like with Firebug). In production, caching
|
209
|
+
virtually eliminates the overhead on all requests after the first one, but
|
210
|
+
you typically won't cache your assets in development, unless you're some
|
211
|
+
sort of nut.
|
185
212
|
|
186
213
|
=== Set assets to be combined, even in development and especially in test
|
187
214
|
|
188
|
-
By default Rails reloads all classes with each new request
|
189
|
-
|
190
|
-
|
191
|
-
|
192
|
-
|
193
|
-
|
194
|
-
|
195
|
-
|
196
|
-
|
197
|
-
|
215
|
+
By default, in development, Rails reloads all classes with each new request.
|
216
|
+
(This is controlled by the cache_classes config parameter.) So if you're not
|
217
|
+
combining all of your assets, a single page load will result in an additional
|
218
|
+
request to your app <em>for each asset</em>, which may result in a dozen
|
219
|
+
requests to your dev server for each page, and each of those dozen requests
|
220
|
+
will reload all of your classes. Combining assets in dev reduces the number
|
221
|
+
of requests, shrinking your page load time. And unlike minification, using
|
222
|
+
combined assets in dev is usually not a problem, even when you're debugging
|
223
|
+
them, because the concatenated files are still quite readable. The one
|
224
|
+
exception is that combined files can make it difficult to find out which
|
225
|
+
asset file includes the problem you're hunting down.
|
198
226
|
|
199
227
|
<em>Note that one advantage of using DynamicAssets</em> instead of a
|
200
228
|
deploy-time task is that you can get more exposure to your processed JavaScript.
|
@@ -205,18 +233,19 @@ more code, tacked on from another file.)
|
|
205
233
|
|
206
234
|
Call me silly, but I prefer to find out about that kind of error before I
|
207
235
|
deploy my app, and with DynamicAssets I can easily set my test environment to
|
208
|
-
combine and minify, so
|
236
|
+
combine and minify, so full-stack testing will expose the problem.
|
209
237
|
|
210
|
-
===
|
238
|
+
=== To eliminate the biggest bottleneck, turn off class caching in development (but...)
|
211
239
|
|
212
|
-
If you don't mind
|
213
|
-
bit of Ruby code, you could edit your config/environments/development.rb
|
240
|
+
If (big if) you don't mind restarting your server every time you change a
|
241
|
+
bit of Ruby code, you <em>could</em> edit your config/environments/development.rb
|
214
242
|
to do this
|
215
243
|
|
216
244
|
config.cache_classes = true
|
217
245
|
|
218
246
|
which would eliminate the biggest chunk of overhead in dev, class-reloading
|
219
|
-
on every request.
|
247
|
+
on every request. And if you're doing that, you might as well set your asset
|
248
|
+
files to be cached, too, in your assets.yml.
|
220
249
|
|
221
250
|
|
222
251
|
== Copyright
|
@@ -43,7 +43,10 @@ module DynamicAssets
|
|
43
43
|
end
|
44
44
|
|
45
45
|
def member_root
|
46
|
-
|
46
|
+
return @member_root if @member_root
|
47
|
+
|
48
|
+
possible_roots = ["#{Rails.root}/app/assets/#{type.to_s}", "#{Rails.root}/app/views/#{type.to_s}"]
|
49
|
+
@member_root = File.find_existing(possible_roots) || possible_roots.first
|
47
50
|
end
|
48
51
|
|
49
52
|
# Optionally pass context from which ERB can pull instance variables.
|
metadata
CHANGED
@@ -1,13 +1,13 @@
|
|
1
1
|
--- !ruby/object:Gem::Specification
|
2
2
|
name: dynamic_assets
|
3
3
|
version: !ruby/object:Gem::Version
|
4
|
-
hash:
|
4
|
+
hash: 17
|
5
5
|
prerelease: false
|
6
6
|
segments:
|
7
7
|
- 0
|
8
8
|
- 3
|
9
|
-
-
|
10
|
-
version: 0.3.
|
9
|
+
- 1
|
10
|
+
version: 0.3.1
|
11
11
|
platform: ruby
|
12
12
|
authors:
|
13
13
|
- Robert Davis
|
@@ -112,7 +112,7 @@ dependencies:
|
|
112
112
|
- 0
|
113
113
|
version: "0"
|
114
114
|
requirement: *id006
|
115
|
-
description:
|
115
|
+
description: Allow your Rails 3 app to package and process your CSS and JS assets on the fly.
|
116
116
|
email: davis@coaster.com
|
117
117
|
executables: []
|
118
118
|
|
@@ -192,7 +192,7 @@ rubyforge_project:
|
|
192
192
|
rubygems_version: 1.3.7
|
193
193
|
signing_key:
|
194
194
|
specification_version: 3
|
195
|
-
summary:
|
195
|
+
summary: Allow your Rails 3 app to package and process your CSS and JS assets on the fly.
|
196
196
|
test_files:
|
197
197
|
- spec/dummy_rails_app/app/controllers/application_controller.rb
|
198
198
|
- spec/dummy_rails_app/app/helpers/application_helper.rb
|