there's an issue, that is bothering me.
I'm following this "Ruby on Rails"-Tutorial to implement an ajaxified rating system
http://eighty-b.tumblr.com/post/1569674815/creating-an-ajaxified-star-rating-system-in-rails-3
Die author uses a self written helper method called "rating_ballot" which seems pretty redundant to me, because it checks if a rating has been given yet and otherwise forms a new one with
current_user.ratings.new
But that actually is being done more or less in the ratingscontroller
using this helper method the form looks like this
= form_for(rating_ballot, :html => { :class => 'rating_ballot' }) do |f|
But any other form (for example posting reviews) uses the instance variable instead of a helper method.
I want the form_for tag to look like this
= form_for(#rating, :html => { :class => 'rating_ballot' }) do |f|
but this only works for updating ratings, not creating new ones.
why is this "rating_ballot" so important ?
Take a look on that part
def rating_ballot
if #rating = current_user.ratings.find_by_photo_id(params[:id])
#rating
else
current_user.ratings.new
end
end
It try to find out #rating if exists and create new instance if not exsits
you can do it in you controller for example:
#rating = current_user.ratings.find_by_photo_id(params[:id])
#rating ||= current_user.ratings.new # create instance if did not find existing once
ans then use it in form like you wrote
I'm guessing the value of #rating is nil, which is why using this form for the #create action isn't working. The first argument should be a new object, or an object that represents an existing record, in order to create or update, respectively.
Another alternative way of using the form_for method is to supply a symbol representing the name of the class and also specifying the :url argument according to how your routes are specified. This is only good for creating though since the symbol doesn't represent an existing record.
Many helper methods, such as redirect_to, link_to, and url_for, can take an ActiveRecord object as a parameter instead of a hash that specifies the controller and action. I've seen the parameter passed different ways in different documentation. It sometimes gets passed as a symbol, sometimes as an instance variable, and sometimes as a local variable.
I'm confused about how the different parameter styles get expanded to return urls. I know that following REST conventions should create a url constructed of a controller and action but am unsure when Rails needs a specific parameter style to construct that url. Please help me understand the use cases for passing the ActiveRecord object as a symbol, an instance variable, or a local variable. Are there different requirements based on the method call? Or are there underlying differences in url construction?
Here are some examples:
From the API docs:
link_to "Profile", #profile
redirect_to post
<%= url_for(#workshop) %>
<%= form_for :person do |f| %> (this is described as the “generic #form_for”)
From the Ruby on Rails Guides:
<%= link_to 'New book', new_book_path %>
redirect_to(#book)
form_for(#article)
From the Rails 3 Way:
'link_to' "Help", help_widgets_path, :popup => 1
redirect_to post
url_for(timesheets_path)
form_for offer do |f|
Note: Upon further research, it seems that form_for is able to accept a local variable in the case where the calling view template passes a :locals hash as a parameter. The keys are the locals that can be used in the partial and the values are the instance variables from the template. Is that the correct understanding?
You can pass objects to link_to and url_for
You can also pass an object to a path helper
Both #post and post are objects. #post is an instance variable, and post is either a local variable or a method that will return a post
The only "weird" one is the form_for :post variety. This is old school Rails syntax, and will change this to the form_for #post syntax under the hood.
I'm using STI with a Rails 3.2 app. I want to force Rails to use the superclass name in link_to helpers (or any where else when it's generating paths) and not the subclass name.
So, <%= link_to current_user.name, current_user %> produces /:class_name/:id (class name can be "Moderator," "Member," etc...).
I would like it to produce /users/:id, where users does not change to the name of the subclass. I know I can change current_user to user_path(current_user), but I prefer to use the shortcut, letting Rails figure it out.
Is this possible?
I think you should define url helpers, something like this
def moderator_url record
user_url record
end
Or just use aliases
alias :moderator_url :user_url
This is code which rails use for url generation when you pass a record as a option
https://github.com/rails/rails/blob/537ede912895d421b24acfcbc86daf08f8f22157/actionpack/lib/action_dispatch/routing/polymorphic_routes.rb#L90
Use the named route:
<%= link_to current_user.name, user_path(current_user) %>
For links, I can get around this by adding a resource:
resources :owners, path: 'users', controller: 'users'
For forms, I need to specify generic form. My initial form was
= simple_form_for #user do |f|
To make this work, I had to specify the path and the method, while using a generic name instead of passing the user object to the form directly:
= simple_form_for :user, url: user_path(#user) do |f|
As my understanding on nested resources, on edge Rails, should not
link_to 'User posts', #user.posts
point to
/users/:id/posts
?
The routes.rb file contains
map.resources :users, :has_many => :posts
If this is not the default behavior, can it be accomplished doing something else?
Along the same lines as Rishav:
link_to "User Posts", [#user, :posts]
Here's an explanation from my blog.
Really early on in Rails, you would write routes like this:
redirect_to :controller => "posts", :action => "show", :id => #post.id
What this would do is dutifully redirect to the show action inside the PostsController and pass along the id parameter with a
value of whatever #post.id returns. Typical 302 response.
Then Rails 1.2 came along and allowed you to use routing helpers, like this:
redirect_to post_path(#post)
And the people rejoiced.
This would do effectively the same thing. post_path here would build a route using the #post object that would look something
like /posts/1 and then redirect_to would send back a 302 response to that route and the browser would follow it.
Then later versions (I can't remember which one), allowed syntax like this:
redirect_to #post
And the people rejoiced a second time.
Magic, but not really
Any sufficiently advanced technology is indistinguishable from magic.
While this seems like magic, it's not. What this is doing is actually very, very neat. The redirect_to method, much like its cousins link_to and form_for all use a common method to build URLs, called url_for. The url_for method takes many different
varieties of objects, such as strings, hashes or even instances of models, like in the example above.
What it does with these objects then, is quite neat. In the case of the redirect_to #post call above, it inspects the #post
object, sees that it is an object of the Post class (we assume, anyway) and checks to see if that object has been persisted in a
database somewhere by calling persisted? on it.
By "persisted", I mean that a Ruby object has a matching record in the database somewhere. The persisted? method in Active Record is implemented like this:
def persisted?
!(new_record? || destroyed?)
end
If the object wasn't created through a call such as Model.new then it won't be a new record, and if it hasn't had the destroy method called on it won't be
destroyed either. If both of these cases are true, then that makes the object has most likely been persisted to the database in the form of a record.
If it has been persisted, then url_for knows that this object can be found
somewhere, and that the place it can be found is most likely under a method called post_path. So it calls this method, and passes
in the to_param value of this object which is usually the id.
In short, it's effectively doing this:
#{#post.class.downcase}_path(#post.to_param)
Which comes out to being this:
post_path(1)
And when that method is called you would get this little string:
"/posts/1"
Lovely!
This is called polymorphic routing. You can pass an object to methods like redirect_to, link_to and form_for and it will
attempt to work out the correct URL of what to use.
The form of form_for
Now, when you're coding Rails you may have used form_for like this a very long time ago:
<% form_for #post, :url => { :controller => "posts", :action => "create" } do |f| %>
Of course, with advancements in Rails you could simplify it to this:
<% form_for #post, :url => posts_path do |f| %>
Because the form is going to default to having a POST HTTP method and therefore a request to posts_path is going to go to the
create action of PostsController, rather than the index action, which is what would result if it were a GET request.
But why stop there? Why not just write this?
<%= form_for #post do |f| %>
Personally, I see no reason not to... if it's something as simple as this. The form_for method uses url_for underneath, just like
redirect_to to work out where the form should go. It knows that the #post object is of the Post class (again, we assume) and it
checks to see if the object is persisted. If it is, then it will use post_path(#post). If it's not, then posts_path.
The form_for method itself checks to see if the object passed in is persisted also, and if it is then it'll default to a PUT HTTP
method, otherwise a POST.
So this is how form_for can be flexible enough to have an identical syntax on both a new and edit view. It's becoming more and
more common these days for people to even put their whole form_for tags into a single partial and include it in both the new and
edit pages.
A more complex form
So form_for is fairly simple for when you pass a normal object, but what happens if you pass an array of objects? Like this, for
instance:
<%= form_for [#post, #comment] do |f| %>
Well, both url_for and form_for have you covered there too.
The url_for method detects that this is an array and separates out each part and inspects them individually. First, what is this
#post thing? Well, in this case let's assume it's a Post instance that is persisted and has the id of 1. Second, what is this
#comment object? It's a Comment instance that has not yet been persisted to the database.
What url_for will do here is build up the URL helper method piece by piece by placing each part in an array, joining it into a routing method and then calling that routing method with the necessary arguments.
First, it knows that the #post object is of the Post class and is persisted, therefore the URL helper will begin with post. Second, it knows that the #comment object is of the Comment class and is not persisted, and therefore comments will follow post in the URL helper build. The parts that url_for now knows about are [:post, :comments].
The url_for method combines these individual parts with an underscore, so that it becomes post_comments and then appends _path
to the end of that, resulting in post_comments_path. Then it passes in just the persisted objects to the call to that method, resulting in a call like this:
post_comments_path(#post)
Calling that method results in this:
"/posts/1/comments"
Best part? form_for will still know to use POST if the #comment object is not a persisted object, and PUT if it is. A good
thing to remember is that the form_for is always for the last object specified in the array. The objects prior to it are just its
nesting, nothing more.
The more objects that are added, the more times url_for will do the hard yards and build the path out... although I recommend that
you keep it to just two parts.
A symbolic form
Now that we've covered using an array containing objects for form_for, let's take a look at another common use. An array containing
at least one Symbol object, like this:
<%= form_for [:admin, #post, #comment] do |f| %>
What the url_for method does here is very simple. It sees that there's a Symbol and takes it as it is. The first part of the
url will simply be the same as the symbol: admin. The URL that url_for knows of at this point is just [:admin].
Then url_for goes through the remaining parts of the array. In this case, let's assume both #post and #comment are persisted
and that they have the ids of 1 and 2 respectively. Same classes as before. url_for then adds post to the URL that it's building,
and comment too, resulting in [:admin, :post, :comment].
Then the joining happens, resulting in a method of admin_post_comment_path, and because both #post and #comment are persisted here,
they're passed in, resulting in this method call:
admin_post_comment_path(#post, #comment)
Which (usually) turns into this path:
/admin/posts/1/comments/2
You can use the array form of polymorphic routing with the redirect_to, link_to and form_for methods. There's probably other
methods that I'm not remembering right now that can do it too... it's generally anything in Rails that would normally take a URL.
There's no need to build your URLs in any Rails version greater-than 2 using hashes; that's pretty old school.
Instead, experiment with your new knowledge of polymorphic routing and use it to the best of your advantage.
This should work:
link_to "User Posts", user_posts_path(#user)
for more details visit:
http://guides.rubyonrails.org/routing.html
link_to uses url_for which uses polymorphic_url.
polymorphic_url:
builds the helper method, using the class name of active record objects
calls the helper with the active record objects as arguments
Therefore, as others said, you should use:
link_to 'User Posts', [#user, :posts]
for which the path is:
user_posts_path(#user)
^^^^ ^^^^^ ^^^^^
1 2 3
class of #user because it is an active record
convert to string because symbol
add as call argument because active record
That builds the good helper method.
This is how to link to a nested resource in the latest Rails:
link_to 'Destroy Comment', post_comment_path(comment.post, comment)
Note: This is in a partial so there isn't a #.
I have an admin namespace which gives me the usual routes such as admin_projects and admin_project, however they are not behaving in the usual way. This is my first Rails 2.3 project so maybe related I can't find any info via Google however.
map.namespace(:admin) do |admin|
admin.resources :projects
end
The strange thing is for a given URL (eg. /admin/projects/1) I don't have to pass in an object to get URL's it somehow guesses them:
<%= admin_project_path %> # => /admin/projects/1
No worries, not really a problem just not noticed this before.
But if I try and pass an object as is usual:
<%= admin_project_path(#project) %> # => admin_project_url failed to generate from {:controller=>"admin/projects", :action=>"show", :id=>#<Project id: 1, name: "teamc...>
":id" seems to contain the entire object, so I try passing the id directly and it works:
<%= admin_project_path(#project.id) %> # => /admin/projects/1
This would not be so bad but when it comes to forms I usually use [:admin, #object], however:
<%= url_for [:admin, #project.id] %> # => undefined method `admin_fixnum_path'
So I can't pass in an id, as it needs an objects class to work out the correct route to use.
<%= url_for [:admin, #project] %> # => Unfortunately this yields the same error as passing a object to admin_project_path, which is what it is calling.
I can't spot any mistakes and this is pretty standard so I'm not sure what is going wrong...
Interesting. What happens when you define a to_param method on Project? For instance
class Project < ActiveRecord::Base
def to_param
self.id
end
end
This should be the default and this shouldnt be necessary. But what happens if you make it explicit? Try adding the above method then going back to your original approach of only passing around #project
I wish I could help you on this one. We have a large application with several namespaced sections. Our routes are defined in the exact method you have described and we are calling our path helper with objects. No where in the application are we accessing using the id.
Our application started on Rails 2.1 and has transitioned through 2.2 and 2.3 with no significant changes to the routing. Sorry I couldn't be more help.
Peer