A resource named "image" gives problems

Hi.

I can't be the only one in the world having the wonderful idea to have a resource named "image".

I have a controller named images_controller I have a route named "image", and therefore a helper called image_path(id).

But using image_path in an action view erb file gives problems, there another helper named image_path[1] is defined, hence I can no longer use the named route url helper image_path

For now I have changed my routes.rb from map.resources :images to map.resources :images, :singular => "my_image",

Then I can use my_image_path in action views.

But... Isn't image such a common word for a resource that [1] should have a different name, e.g. asset_path, image_asset_path, or something else. There is already an alias path_to_image[1]. How about just stick to that?

What do you say?

There are some others having this problem: [2]

Jarl

Footnotes: [1] ActionView::Helpers::AssetTagHelper

[2] Pragmatic Bookshelf: By Developers, For Developers

map.resources :images, :as => 'your_custom_name'

You've already read the API about the ActionView helpers so you know it's not something you can use.

You can post suggestions in Dev but the likelihood of this being changed is nil.

Not directly related to your problem but I had problems in the past with resources named - Type (this is very common in my opinion) - Controller

Mostly it was that some part of scaffolding didn't work, because of the @controller variable already used in the controller.

I don't have a real good solution for this, except maybe issue a warning to the user when he tries to scaffold from these specific resource names. Something like "you could have problems, choose a different name". This warning could also suggest an appropriate substitute name.

This could also apply to your "Image" problem. The scaffold could suggest for you to rename it to something else, say "Picture".

Tomislav

I've found naming a resource "Test" to be problematic, which is kind of a drag in an educational application.

I've found naming a resource "Test" to be problematic, which is kind of a drag in an educational application.

For future reference a list of words to be avoided can be found at http://wiki.rubyonrails.org/rails/pages/ReservedWords.

It would be useful if the generators showed a warning when any of these words is used.

Colin

I’ve had problems with Template in the past (which isn’t on the wiki list).

-John

I'm not sure this is a Rails problem. Most web apps have an 'images' directory under the public web root. If you send a request to a URL that looks something like http://example.com/images/foo then your web server is going to interpret that to mean you want it to serve the static image file named 'foo' from the images directory. The request shouldn't even make it to your application.

I don't know if that's the problem you're having, but it seems like enough of a reason to not have an 'images' resource.

That's really kind of sidestepping the issue though. It's not just
resources called 'images' that this happens to, and there's absolutely
no requirement for template images to be stored in /images - they
could be at another path, or on an asset server.

+1 for allowing generators to pick up on any reserved keywords and
warn about them. Obviously we can't catch everything, but it would be
helpful to flag up names we know aren't going to work.

-Matt

+1 for allowing generators to pick up on any reserved keywords and warn about them. Obviously we can't catch everything, but it would be helpful to flag up names we know aren't going to work.

The generators actually do this already, but they only check for existing constants. For example if you're generating a model called Mime it basically does

if Object.const_defined?("Mime")   fail end

Clearly that's not enough to catch everything though as the examples people have mentioned here are causing problems *without* constants defined.

If someone wants to take a stab at this, I'm keen to take a look at a patch.

Rails has a public directory as the root with subdirectories for image(s) javascript, etc.

And requests for those resources don't go through the app.

But that's not the problem here, the app still needs to be able to generate uris for those resources in rendered views so that the browser knows to ask for them.

Now rails provides standard helper functions, such as image_path, javascript_path, and stylesheet_path to aid in rendering those uris.

But if you have routes for a resource named x, you expect rails to generate helpers to generate the related uris, so you get x_path, and x_url, but if x is image or javascript or ... then you will only see one say image_tag helper, and apparently it's the one for the static asset.

I'd quite like to take a shot at it, but I haven't contributed to the core before -is there a policy/procedure document somewhere I can take a look at first?

-Matt

http://guides.rubyonrails.org/contributing_to_rails.html

You might also find some of the resources linked from http://wiki.railsbridge.org/projects/railsbridge/wiki/BugMash useful.

Mike

+1 for the warn. -1 for anything else.

Colin Law <clanlaw@googlemail.com> writes:

Rick DeNatale <rick.denatale@gmail.com> writes:

Rails has a public directory as the root with subdirectories for image(s) javascript, etc.

And requests for those resources don't go through the app.

But that's not the problem here, the app still needs to be able to generate uris for those resources in rendered views so that the browser knows to ask for them.

Now rails provides standard helper functions, such as image_path, javascript_path, and stylesheet_path to aid in rendering those uris.

But if you have routes for a resource named x, you expect rails to generate helpers to generate the related uris, so you get x_path, and x_url, but if x is image or javascript or ... then you will only see one say image_tag helper, and apparently it's the one for the static asset.

You definitely got my point!

Jarl

I did say for future reference :slight_smile:

Perhaps someone will add it.

Colin