Is there some way to override the paths for images, stylesheets and
javascripts without monkey patching? (Rails 3 Beta)
I just looked at asset_tag_helper.rb and I see this:
def stylesheet_path(source)
compute_public_path(source, ‘stylesheets’, ‘css’)
end
Unless I’m missing something in the way the code works, that seems
hard coded to me. Am I stuck using the directories /images, /
stylesheets and /javascripts instead of something more concise like /
img, /css and /js if I opt to use the helpers?
It’s hardcoded as you say. Being able to configure these paths would
really
be a good addition to the core if you were to write this as a new
feature.
/Lasse
2010/3/26 cult hero [email protected]
I might fix that myself. Seems like it would be easy enough. I found a
similar annoyance today too. (I’ll post that in a moment.)
Colin,
Yeah – but it should be possible to use your own conventions if that’s
what
you want, even though the recommendation is to use the built-in
conventions.
Regarding plugins and copying, Rails has configured paths, like
config.javascripts_dir and config.stylesheets_dir.
/Lasse
2010/3/27 Colin L. [email protected]
On 26 March 2010 22:36, Lasse B. [email protected] wrote:
It’s hardcoded as you say. Being able to configure these paths would really
be a good addition to the core if you were to write this as a new feature.
/Lasse
2010/3/26 cult hero [email protected]
Is there some way to override the paths for images, stylesheets and
javascripts without monkey patching? (Rails 3 Beta)
Do some plugins copy scripts and css to those folders? If so do they
ask rails where to put them or just assume the conventional names?
I am not convinced it would be a good thing to use alternative names
just for aesthetic reasons. Rails is all about convention after all.
One does not like all the conventions but it is better to stick to
them when possible.
Colin
On 29 March 2010 19:15, cult hero [email protected] wrote:
problems for now and when I have time on the weekend or something,
I’ll see about making some modifications and submitting actual
patches. (There are a few other areas in the view helpers to inject
some things I don’t much care for that require similar methods.)
This isn’t necessarily purely about convention, especially when you’re
integrating Rails into an existing infrastructure. Symlinks might do
the job… but I’m not in love with the idea. (And let’s face it, I’m
a control freak about certain aspects of my apps, plain and simple.)
If you are not using ActiveRecord and think the view helpers are
rubbish and don’t want to stick to the conventions, I am interested in
knowing what benefits you are getting from rails. (No criticism
implied, we are all entitled to work the way we want to.)
Colin
The reason I didn’t use Rails 2 was because of too much convention. (I
didn’t want to use ActiveRecord, for one thing.) There is a point
where too much convention starts to inhibit what I do and what I want.
It might be fine for others, but that’s why I prefer some level of
configuration with sensible defaults rather than a method where a path
is hardcoded. In general, I find that hardcoding something like that
isn’t good practice.
I’m finding that the view helpers are probably the weakest area in
this regard. It’s not a biggie though. Monkey patching has fixed the
problems for now and when I have time on the weekend or something,
I’ll see about making some modifications and submitting actual
patches. (There are a few other areas in the view helpers to inject
some things I don’t much care for that require similar methods.)
This isn’t necessarily purely about convention, especially when you’re
integrating Rails into an existing infrastructure. Symlinks might do
the job… but I’m not in love with the idea. (And let’s face it, I’m
a control freak about certain aspects of my apps, plain and simple.)