Rails: How to Access Restful Helpers

Rails: how do you access RESTful helpers?

You have several questions in there, most of which have already been answered by people below.

The answer to one that wasn't fully addressed however, is: yes you can use the script/console to see where your routes go. Just type in app.[route_helper] and it will respond with the path. For example app.users_path will return /users/

So for your example type app.entries_url for the full URL - or app.entries_path for its relative path within the console.

Resource helpers in rails console

route helpers are available within the app object, so you can get access to them this way

app.photos_path     # => "/photos"

How to use routing helpers in a model with Rails 3?

Got an answer from the rails IRC: just add

  include Rails.application.routes.url_helpers

to your model

helper path generated by Rails based on a custom REST method fails

As posted in the description, here is the "usage".

# GET /reso
def show
...
  @reset_path = "foo_reso"
...
end # show

However, all the above is doing is just setting the @reset_path instance variable into a literal string `"foo_reso" (which coincidentally matches the old route)

What the poster really wants is :

 @reset_path = foo_reso_path

which will generate the right path /reso/foo into the instance variable @reset_path

Sidenote: The poster has done all the right things here to debug route problems. Most of the time, you can trust rake routes. Checking that one can access the route directly is good, and so is checking the usage of the route helper is correct too is crucial

Rails: How to parameterize access to a RESTful resource?

I think that really your question comes down to how to know when it's appropriate to represent something as a resource and when to parameterize it using a query string.

I don't know your domain, but from your question it appears that historical data about a device is a resource and that accessing subsets of that data through a range is best represented as a query string, in the same way that you might paginate a large list of items.

Something else to consider is caching, because if you want to page cache each range individually then you will have to use path segments within the route i.e. :range. That way Rails will generate a unique HTML file on disk to represent that range. If you use a query string then it will effectively get ignored and the same HTML file will be returned for different ranges.

When should you use RESTful controllers in a Rails app, and when should you not?

Make a resource of each top-level model in your system. By top-level, I mean models that are independent and have meaning outside of the associated model. Generally, that's most models. In the following example Position and Candidate are top-level. You could consider Candidate to be composed of PastEmployment and positions to which she has applied. Applications to positions and prior work history can be accessed through the Candidate resource, since they don't exist on their own.

Models

class Position
  has_many :candidate_positions
  has_many :candidates, :through => :candidate_positions
end

class Candidate
  has_many :candidate_positions
  has_many :positions, :through => :candidate_positions
  has_many :past_employments
  accepts_nested_attributes_for :past_employments
  accepts_nested_attributes_for :candidate_positions
end

class PastEmployment
  belongs_to :candidate
end

class CandidatePosition
  belongs_to :candidate
  belongs_to :position
end

Routes

map.resources :positions
map.resources :candidates

Use a non-resourceful controller for interactions with the user that span models. For example, if you wanted to have a HomeController that shows available positions as well as recent candidates, that would be a new, plain controller. If you want to edit any of the information on this controller, cool! You already have controllers available to handle the form posts, that will automatically be wired with <% form_for @candidate %>. You can render your collection of positions with <%= render @positions %>, and because you've made them a resource, Rails will know to look in views/positions/_position.html.erb for the appropriate partial.

The end result should be that you're never writing logic to handle the persistence of an object in more than one place. That's when controllers get complex and forms get out of hand. It also means that Rails and external systems know where to retrieve and store objects. Same URL, same controller, just a different format.

---

Related Topics