On Sunday, May 25, 2014 2:31:33 AM UTC-4, Ruby-Forum.com User wrote:
>
> mike2r wrote in post #1146887:
> > I would use resources, as
> > Scott
> > suggests, but limit the actions that you really need such as:
> >
> > resources :dicts, only: [:show]
>
> Now in my case, the action has a "non-standard" name, i.e. ":manage".
>
> Can I use this too in the "only:" array, or should I instead use a
> standard action (in this case probably "edit"), which then, inside my
> controller, invokes the "manage" method?
>
> From my understanding of the "Rails Routing From The Outside" guide,
> routes.rb defines which controller methods are invoked, when a certain
> request arrives, and the "resources" definition just creates standard
> routes with standard action names for the "common case"
> (show/index/edit/....). Did I grasp this correctly?
>
> If I understood this right, I would have two possibilities: Use ab
> action name which reflects the purpose of the action (here: 'manage')
> and write a special route definition, as Евгений Шурмин suggested above,
> or use the standard action names, and use a 'resources' definition. From
> a viewpoint of maintainability, what would you consider the better
> solution?
>
> --
> Posted via http://www.ruby-forum.com/.
To answer your first question, when a segment key is part of your route
(:id) you need to tell rails what you want the named route to look like or
it won't generate one. Even if you didn't have the segment key, for
example:
get 'dict/manage' => 'dict#manage'
it would generate the named routes dict_manage_path and dict_manage_url
which isn't what you want. Therefore, you need the as: :dict to generate
the named route you are after.
In answer to your second question, yes, you have grasped the basics
correctly and yes. The resources statement creates the standard routes as
well as the named routes to go with them. However, it's part of a larger
architecture of handling REST transactions. When you use the following:
rails generate scaffold dict
it will generate not only the routes statement, but the standard actions
and views to go with it. If you stick to the rails convention, it will
save you a lot of time and work, and I advise that you do so unless there
is functionality that just won't work with that structure.
I would argue that from your description (i'm at a little bit of a loss
since I haven't actually seen your controller code), dict is a resource,
even if you don't intend to initially offer users full CRUD options on the
resource. Therefore, I prefer setting this up in the routes (and
elsewhere) as a resource and using standard Rails action names. The word
"manage" to me could be adding a new entry to dict, modifying an existing
entry, etc. This actually involves a number of actions and it would be
better to more specific about the purpose of each action. By the way, edit
actually involves two actions. The first is to provide the user with a
form populated with the values of the existing entry to be edited. The
second happens when the user makes changes and submits the form, and the
resource is updated. In the Rails architecture, these are the edit and
update actions respectively and you would need to allow both in your
resources statement.
If you don't like the Rails standard names for your routes, you can change
them, although I still maintain it's better to learn the Rails way of doing
things and stick to it when possible. This makes maintenance and
integration with other parts of your application much easier. However, in
this case, let's assume we want to say manage instead of edit. You would
route as follows:
resources: :dicts, path_names: { edit: 'manage' }
Note: this changes the path name, so you will have /dicts/:id/manage, but
it doesn't change the controller actions, it will still map to the action
edit in the controller. Usually this is only done when there are specific
reasons to do so, such as creating a site in a different language where you
want the URL's to reflect a language other than English.
--
You received this message because you are subscribed to the Google Groups "Ruby
on Rails: Talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rubyonrails-talk+unsubscr...@googlegroups.com.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/rubyonrails-talk/2f71e12f-a238-41e1-8c7c-9c9513fd3204%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
