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] http://api.rubyonrails.org/classes/ActionView/Helpers/AssetTagHelper.html#M001720

[2] http://forums.pragprog.com/forums/59/topics/2723

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