This has to do more with Rails than jQuery so I am posting it here. I
am using jQuery UI widgets in my application. One of the CSS file is
called ui.theme.css which has references to background-image as shown
below:
.ui-widget-content .ui-icon {background-image:
url(images/ui-icons_222222_256x240.png)/{iconsContent}/; }
Following Rails conventions, I put the stylesheets in public/stylesheets
and javascripts in public/javascripts directories.
Trouble is: this creates problems in terms of background images not
loading correctly, I have to change the aforementioned line to:
.ui-widget-content .ui-icon {background-image:
url(’/images/ui-icons_222222_256x240.png’)/{iconsContent}/; }
In other words, put a forward slash “/” in front of the images and put
the whole uri string in quotes for Rails to load it correctly. This
seems like a lot of work for no good reason. Any advice on how to get
around it without having to modify the CSS files?
Thanks.
Bharat
Hi–
On May 9, 2009, at 6:53 PM, Bharat R. wrote:
stylesheets
seems like a lot of work for no good reason. Any advice on how to get
around it without having to modify the CSS files?
I don’t think it’s a Rails thing. I think it’s the way URLs are
resolved into physical pathnames by Web servers. A document-relative
URL is always (AFAIK) going to load the specified resource relative to
the directory in which the current document exists by default. Because
Rails “fakes” a rather deeper directory structure using routing, the
only time a server will try to load a resource like images/ui-
icons_22222_256x240.png from public/images is if your are looking at a
document called ‘/’.
There are several ways to approach this. I humbly call them the
expensive way, the cheap-but-brittle way, and the Apache way.
Expensive way: Put code in your routes.rb to snag the request for your
ui-icons and map them to the correct directory. Why not? Because they
all of a sudden become dynamic resources and expensive to serve.
Cheap-but-brittle way: Make the change to the CSS and get on with it.
That’s what I do and I believe it’s pretty common practice. When you
upgrade versions, it’s brittle, shatters into a million pieces, but
it’s easy to spot.
Apache way: Write some keen rewrite rule that recognizes your jQ-UI
resource and maps it to the correct location no matter where your
document exists.
Obviously there are variants for nginx and there might even be some
keen Metal solution I haven’t thought of. But really, overthinking
this one won’t get you to done much quicker.
Good luck.
Bharat R. wrote:
"Cheap-but-brittle way: Make the change to the CSS and get on with
it.
That’s what I do and I believe it’s pretty common practice. When you
upgrade versions, it’s brittle, shatters into a million pieces, but
it’s easy to spot. "
I don’t remember: will affect URLs in CSS? I think not, but
it might be worth a try.
Thank you. I will go with this route, already have. I can see that
Mr. Yahuda Katz has his work cut out for him for Rails 3.0. After
all, he is the jQuery man 
I hope he makes jQuery a first class
Rails citizen instead of the rather unwelcome guest which it currently
is in Rails world.
I’ve never used jQuery, but it seems to me that this would be a serious
problem with the framework. I don’t think a general-purpose JS
framework should have hard-coded image URLs in its stylesheets – that’s
just way too brittle, for exactly the reasons you’re running into. I’ve
been thinking about playing with jQuery, but this seems like such a bad
idea that I wonder if I should even touch the framework!
Best,
Marnen Laibow-Koser
http://www.marnen.org
[email protected]
I caution you not to jump to conclusions. This is due to jQuery UI
themes that is not part of the core jQuery library. So you can still
get a lot done without having to do what I had to do. Even without the
CSS magic, the core functionality is working fine 
But it is clear to
me that either Rails or jQuery are not particularly tailored for each
other at this point. Though, Yahuda Katz, who is now on Rails 3 core
team as well as jQuery teams is bound to do something to make things
better.
On the plus side though, the jQuery API is so well designed and
implemented that I am rather enjoying coding in client side Javascript
which I did not particularly care for in the original Rails Javascript
frameworks, Protoype and Scriptaculous
"Cheap-but-brittle way: Make the change to the CSS and get on with
it.
That’s what I do and I believe it’s pretty common practice. When you
upgrade versions, it’s brittle, shatters into a million pieces, but
it’s easy to spot. "
Thank you. I will go with this route, already have. I can see that
Mr. Yahuda Katz has his work cut out for him for Rails 3.0. After
all, he is the jQuery man I hope he makes jQuery a first class
Rails citizen instead of the rather unwelcome guest which it currently
is in Rails world.