Under development this file path is "/assets/my_controller/project_name.css" while the image is located at "/assets/my_controller/sprite.png".
When assets:precompile is run, project_name.css no longer exists and the rule is appended to application.css, but the relative URL is not rewritten to 'my_controller/sprite.png' or '/assets/my_controller/sprite.png'.
The Grails Resources plugin supports URL rewriting for dealing with this kind of issue that happens when using an asset pipeline:
It is not a good experience to have your application working under development and stopping working under production due to things like this.
Also, I like the idea of grouping my assets in sub-directories.
Shouldn't the Rails assets generator support URL rewriting in CSS for supporting such an organized tree both in development and production environment out of the box?
On Monday, 7 May, 2012 at 11:49, Rodrigo Rosenfeld Rosas wrote:
> There are some times where I add some JavaScript libraries as submodules to my project:
> git submodule add git://... resources/project_name
> cd assets/stylesheets/my_controller
> ln -s ../../../resources/project_name/css/project_name.css
> cd -
> cd assets/images/my_controller
> ln -s ../../../resources/project_name/img/sprite.png
> While this works great in development mode, I have to create more symbolic links to make it work under production as well.
> Here is why. Under development mode the css is written like this:
> Under development this file path is "/assets/my_controller/project_name.css" while the image is located at "/assets/my_controller/sprite.png".
> When assets:precompile is run, project_name.css no longer exists and the rule is appended to application.css, but the relative URL is not rewritten to 'my_controller/sprite.png' or '/assets/my_controller/sprite.png'.
> The Grails Resources plugin supports URL rewriting for dealing with this kind of issue that happens when using an asset pipeline:
> It is not a good experience to have your application working under development and stopping working under production due to things like this.
> Also, I like the idea of grouping my assets in sub-directories.
> Shouldn't the Rails assets generator support URL rewriting in CSS for supporting such an organized tree both in development and production environment out of the box?
> Am I missing something?
> Best,
> Rodrigo.
> --
> You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
> To post to this group, send email to rubyonrails-core@googlegroups.com (mailto:rubyonrails-core@googlegroups.com).
> To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com (mailto:rubyonrails-core+unsubscribe@googlegroups.com).
> For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
>> Under development this file path is >> "/assets/my_controller/project_name.css" while the image is located >> at "/assets/my_controller/sprite.png".
>> When assets:precompile is run, project_name.css no longer exists and >> the rule is appended to application.css, but the relative URL is not >> rewritten to 'my_controller/sprite.png' or >> '/assets/my_controller/sprite.png'.
>> The Grails Resources plugin supports URL rewriting for dealing with >> this kind of issue that happens when using an asset pipeline:
>> It is not a good experience to have your application working under >> development and stopping working under production due to things like >> this.
>> Also, I like the idea of grouping my assets in sub-directories.
>> Shouldn't the Rails assets generator support URL rewriting in CSS for >> supporting such an organized tree both in development and production >> environment out of the box?
I've had this problem with the asset pipeline as well, even though I don't use submodules. I agree with Rodrigo that a solution is needed, but I have not yet figured out what the best solution is--that's why I haven't yet tried to contribute a solution myself.
To recap, the problem occurs when integrating third party client-side assets that include CSS which has relative paths to images or fonts. A couple of real examples:
// Chosen:
background: *url('chosen-sprite.png')* right top no-repeat;
The relative paths work fine in development mode but fail in production when the CSS asset is packaged into application.css, which is at a different directory level than the images and fonts. The ".." case is especially tricky to work around.
If it helps, I think this is a decent set of requirements for any solution we come up with:
- *Vendor's JS and CSS can be packaged in the minified JS and CSS files* for the app, as described in the Rails Guide to the Asset Pipeline, even if the CSS has relative path references to other assets.
- *Each JS library is in a directory named after it.* Personally, this only matters to me when a JS library has multiple files (e.g., JS, CSS, and images). For single-file libraries I don't mind having them sit together in a single directory.
- *Let app developers keep each JS library's original directory structure
* when copying it into an app. In other words, something like vendor/chosen, not vendor/javascripts/chosen.js + vendor/stylesheets/chosen.css. Why? So later on, when you download a newer version, you don't have to go finding where you moved all the files.
- *Don't require the use of a gem just to use a JavaScript library.* Why? Because not all JavaScript libraries have corresponding gems and even when there is one I have low confidence that it will be kept up-to-date. The library and the gem are often written by different people. It's darn likely that the gem maintainer will not bother updating the gem in a timely manner every time the JS library gets an update.
- *Don't require app developers to modify the asset references in the JavaScript library or its CSS.* That becomes a maintenance headache. E.g., I don't want to replace background-image: url(bkgnd.png) with background-image: url(<%= asset_path(bkgnd.png) %>) throughout the CSS files in someone else's library.
- *Keep it simple*. :-) In other words, there might be an easy solution that does not require parsing and rewriting CSS, and would work even in JavaScript libraries that dynamically update CSS background paths.
> Under development this file path is > "/assets/my_controller/project_name.css" while the image is located at > "/assets/my_controller/sprite.png".
> When assets:precompile is run, project_name.css no longer exists and the > rule is appended to application.css, but the relative URL is not rewritten > to 'my_controller/sprite.png' or '/assets/my_controller/sprite.png'.
> The Grails Resources plugin supports URL rewriting for dealing with this > kind of issue that happens when using an asset pipeline:
> It is not a good experience to have your application working under > development and stopping working under production due to things like this.
> Also, I like the idea of grouping my assets in sub-directories.
> Shouldn't the Rails assets generator support URL rewriting in CSS for > supporting such an organized tree both in development and production > environment out of the box?
So what are people doing now to solve it? I just had to rewrite all my 3rd party css files to replace the relative image path with <%= asset_path 'image_name' %>. Just wondering if anybody else came up with something better.
On Tuesday, May 8, 2012 1:42:00 PM UTC-4, Brian Morearty wrote:
> I've had this problem with the asset pipeline as well, even though I don't > use submodules. I agree with Rodrigo that a solution is needed, but I have > not yet figured out what the best solution is--that's why I haven't yet > tried to contribute a solution myself.
> To recap, the problem occurs when integrating third party client-side > assets that include CSS which has relative paths to images or fonts. A > couple of real examples:
> // Chosen:
> background: *url('chosen-sprite.png')* right top no-repeat;
> The relative paths work fine in development mode but fail in production > when the CSS asset is packaged into application.css, which is at a > different directory level than the images and fonts. The ".." case is > especially tricky to work around.
> If it helps, I think this is a decent set of requirements for any solution > we come up with:
> - *Vendor's JS and CSS can be packaged in the minified JS and CSS files
> * for the app, as described in the Rails Guide to the Asset Pipeline, > even if the CSS has relative path references to other assets.
> - *Each JS library is in a directory named after it.* Personally, this > only matters to me when a JS library has multiple files (e.g., JS, CSS, and > images). For single-file libraries I don't mind having them sit together in > a single directory.
> - *Let app developers keep each JS library's original directory > structure* when copying it into an app. In other words, something like > vendor/chosen, not vendor/javascripts/chosen.js + > vendor/stylesheets/chosen.css. Why? So later on, when you download a newer > version, you don't have to go finding where you moved all the files.
> - *Don't require the use of a gem just to use a JavaScript library.* Why? > Because not all JavaScript libraries have corresponding gems and even when > there is one I have low confidence that it will be kept up-to-date. The > library and the gem are often written by different people. It's darn likely > that the gem maintainer will not bother updating the gem in a timely manner > every time the JS library gets an update.
> - *Don't require app developers to modify the asset references in the > JavaScript library or its CSS.* That becomes a maintenance headache. > E.g., I don't want to replace background-image: url(bkgnd.png) with > background-image: url(<%= asset_path(bkgnd.png) %>) throughout the CSS > files in someone else's library.
> - *Keep it simple*. :-) In other words, there might be an easy > solution that does not require parsing and rewriting CSS, and would work > even in JavaScript libraries that dynamically update CSS background paths.
> Thanks.
> Brian
> On Monday, May 7, 2012 7:57:46 AM UTC-7, Rodrigo Rosenfeld Rosas wrote:
>> As far as I understand this won't work for files I don't own, like >> linked files from external resources in submodule directories.
>> I don't like the idea of copying the files from external projects and >> rewriting them.
>> Cheers,
>> Rodrigo.
>> Em 07-05-2012 11:54, Rafael Mendonça França escreveu:
>> Yes, it should and it does. Please take a look at the Assets pipeline >> guide[1].
>> Under development this file path is >> "/assets/my_controller/project_name.css" while the image is located at >> "/assets/my_controller/sprite.png".
>> When assets:precompile is run, project_name.css no longer exists and the >> rule is appended to application.css, but the relative URL is not rewritten >> to 'my_controller/sprite.png' or '/assets/my_controller/sprite.png'.
>> The Grails Resources plugin supports URL rewriting for dealing with this >> kind of issue that happens when using an asset pipeline:
>> It is not a good experience to have your application working under >> development and stopping working under production due to things like this.
>> Also, I like the idea of grouping my assets in sub-directories.
>> Shouldn't the Rails assets generator support URL rewriting in CSS for >> supporting such an organized tree both in development and production >> environment out of the box?
On Wednesday, September 19, 2012 1:13:53 PM UTC-5, eugene miretsky wrote:
> Hi,
> So what are people doing now to solve it? > I just had to rewrite all my 3rd party css files to replace the relative > image path with <%= asset_path 'image_name' %>. Just wondering if anybody > else came up with something better.
> On Tuesday, May 8, 2012 1:42:00 PM UTC-4, Brian Morearty wrote:
>> I've had this problem with the asset pipeline as well, even though I >> don't use submodules. I agree with Rodrigo that a solution is needed, but I >> have not yet figured out what the best solution is--that's why I haven't >> yet tried to contribute a solution myself.
>> To recap, the problem occurs when integrating third party client-side >> assets that include CSS which has relative paths to images or fonts. A >> couple of real examples:
>> // Chosen:
>> background: *url('chosen-sprite.png')* right top no-repeat;
>> The relative paths work fine in development mode but fail in production >> when the CSS asset is packaged into application.css, which is at a >> different directory level than the images and fonts. The ".." case is >> especially tricky to work around.
>> If it helps, I think this is a decent set of requirements for any >> solution we come up with:
>> - *Vendor's JS and CSS can be packaged in the minified JS and CSS >> files* for the app, as described in the Rails Guide to the Asset >> Pipeline, even if the CSS has relative path references to other assets.
>> - *Each JS library is in a directory named after it.* Personally, >> this only matters to me when a JS library has multiple files (e.g., JS, >> CSS, and images). For single-file libraries I don't mind having them sit >> together in a single directory.
>> - *Let app developers keep each JS library's original directory >> structure* when copying it into an app. In other words, something >> like vendor/chosen, not vendor/javascripts/chosen.js + >> vendor/stylesheets/chosen.css. Why? So later on, when you download a newer >> version, you don't have to go finding where you moved all the files.
>> - *Don't require the use of a gem just to use a JavaScript library.* Why? >> Because not all JavaScript libraries have corresponding gems and even when >> there is one I have low confidence that it will be kept up-to-date. The >> library and the gem are often written by different people. It's darn likely >> that the gem maintainer will not bother updating the gem in a timely manner >> every time the JS library gets an update.
>> - *Don't require app developers to modify the asset references in the >> JavaScript library or its CSS.* That becomes a maintenance headache. >> E.g., I don't want to replace background-image: url(bkgnd.png) with >> background-image: url(<%= asset_path(bkgnd.png) %>) throughout the >> CSS files in someone else's library.
>> - *Keep it simple*. :-) In other words, there might be an easy >> solution that does not require parsing and rewriting CSS, and would work >> even in JavaScript libraries that dynamically update CSS background paths.
>> Thanks.
>> Brian
>> On Monday, May 7, 2012 7:57:46 AM UTC-7, Rodrigo Rosenfeld Rosas wrote:
>>> As far as I understand this won't work for files I don't own, like >>> linked files from external resources in submodule directories.
>>> I don't like the idea of copying the files from external projects and >>> rewriting them.
>>> Cheers,
>>> Rodrigo.
>>> Em 07-05-2012 11:54, Rafael Mendonça França escreveu:
>>> Yes, it should and it does. Please take a look at the Assets pipeline >>> guide[1].
>>> Under development this file path is >>> "/assets/my_controller/project_name.css" while the image is located at >>> "/assets/my_controller/sprite.png".
>>> When assets:precompile is run, project_name.css no longer exists and the >>> rule is appended to application.css, but the relative URL is not rewritten >>> to 'my_controller/sprite.png' or '/assets/my_controller/sprite.png'.
>>> The Grails Resources plugin supports URL rewriting for dealing with this >>> kind of issue that happens when using an asset pipeline:
>>> It is not a good experience to have your application working under >>> development and stopping working under production due to things like this.
>>> Also, I like the idea of grouping my assets in sub-directories.
>>> Shouldn't the Rails assets generator support URL rewriting in CSS for >>> supporting such an organized tree both in development and production >>> environment out of the box?
