Any progress on this issue? how to solve this on 3rd party libs, it is very
annoying...
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;
>>
>> // Font-Awesome-More:
>> @font-face {
>> font-family: 'FontAwesome';
>> * src: url('../font/fontawesome-webfont.eot');*
>> }
>>
>>
>> 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].
>>>
>>>
>>> [1]
>>> http://guides.rubyonrails.org/asset_pipeline.html#coding-links-to-assets
>>> --
>>> *Rafael Mendonça França*
>>>
>>> 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:
>>>
>>> .some-class { background: url(sprite.png) } /* relative URL */
>>>
>>> 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:
>>>
>>> http://grails.org/plugin/resources
>>> http://grails-plugins.github.com/grails-resources/ (sorry,
>>> documentation is not that good, but it works this way, I promiss)
>>>
>>> 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 view this discussion on the web visit
https://groups.google.com/d/msg/rubyonrails-core/-/lAmu2pqS7ckJ.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/rubyonrails-core?hl=en.
