In a Rails project, and in an RSpec spec file, what are the pros and cons for using a named route, such as blogs_path() vs a hard coded URL, such as /blogs?
I know the answer is highly opinionated, but it will help me (and many others) to get a view of the pros and cons of each approach.
It's the same as with any hardcoded stuff: harder to change later.
If you change your path from /blogs to /interesting_stuff_people_have_to_say it's a one line change if you're using the methods (named routes):
- get :blogs
+ get :blogs, as: :interesting_stuff_people_have_to_say
But if you hardcoded the path, you need to change it everywhere you used it. You might even miss some cases:
url = 'blog' + 's'
redirect_to url
Which will cause your specs to fail (if you're lucky and have this covered) or errors on production.
Related
I have a massive monolithic Rails repo with a couple thousand routes.
Over time, developers have either deleted a route which maps to an existing controller or have deleted a controller which still has a route mapped to it
Is there a smart way for me to systematically find these anomalies within my rails app to clean it up?
NOTE: Please assume that these mismatches do not present a user-facing issue but is merely for maintenance purposes to trim the number of bad routes
The traceroute gem looks very nice, but just in case it doesn't work as you expect, you could do this in rails console.
Get an array of all your controllers with their actions:
ApplicationController.descendants.map {|c| [c, c.action_methods]}
Get an array of all routes:
Rails.application.routes.routes.map &:defaults
Then you could iterate over the two arrays, selecting actions that appear in one array but not in the other one.
Before starting the console set config.eager_load = true in config/environments.development.rb. Without this you won't see all of your controllers.
There is no such command that will find you:
But here is a thing you can do:
Run command:
rails routes > routes.rb
It will write all your route in an text file and they you can match the manually if you have the time.
But there is no harm if you have extra routes present in Rails application its common in most of the Rails applications.
I found this gem which aims to solve my question somewhat
https://github.com/amatsuda/traceroute
Question
I'm looking for something in the rails console or similar where I can call get_controller_for_path('/some/path/') and it will return the corresponding controller.
Background
I have a rails project with a lot of routes. I'm investigating a routing problem and want to confirm that a given URL will match a specific route.
I can use bundle exec rake routes to view the list of routes, but that still requires my human eyes to parse the hundreds (thousands?) of routes and figure out what's going on.
Here you go: Rails parse url to hash(Routes)
That says it's Rails.application.routes.recognize_path "/accounts/1"
You can also use assert_routing in your tests. If you don't have tests, now is a very good time to add some. And you can read the source of assert_routing, and assert_recognizes, to see what they do.
We are updating our large web app and getting rid of our URL synonym system. For example, though we only use one model for 'advertiser', it is aliased to 'merchants' and 'sellers', using synonymous paths. Thus, /merchant/1 and /seller/1 use the same exact controller and action as advertiser/1.
We no longer need this functionality, but we do need for old URLs to correctly redirect users to the proper place (i.e. proper controller actions).
So far, I've tried:
1) reading http://guides.rubyonrails.org/routing.html - This lead me to try the following suggestions
2) match '/merchants' => redirect('/advertisers') - this didn't seem to work at all, though the syntax seems correct.
3) iterating over resources (this produces a TON of routes and may cause insecurities):
ADVERTISER_SYNONOYMS = ['affiliates', 'sellers']
ADVERTISER_SYNONYMS.each do |a|
resources :advertisers, :path => a, :as => :advertiser
resources :other_controller do
member do
get :test
match :generate_test
end
end
end
end
We use nested resources in our routes.rb, so I'm struggling with getting these synonymns to be recognized all throughout more complex URLs. If anyone dealt with this problem or has a more elegant suggestion, I'd be most grateful.
There are many ways to handle this, including additional routes in routes.rb like you've tried, or rewrites at the webserver level such as Apache or Nginx.
One solution I like is the rack-rewrite gem; it keeps routes clean and the rules are plain ruby. It provides a set of methods for configuring rewrites and redirects. For your situation, I would want to use permanent redirects. Though I haven't tested it out myself, something like the following may work for you:
# Gemfile
gem 'rack-rewrite'
# application.rb
config.middleware.use(Rack::Rewrite) do
r301 %r{/merchant|seller/(\w+)}, '/advertiser/$1'
end
My app consists of two rails servers with mostly different concerns sitting behind a reverse proxy. Let's call them Server1 and Server2. Occasionally, Server1 needs to render a link to a url on Server2. Is there a good way to use Rails route helpers for this? Specifically in Rails 2? I came up with this:
ActionController::Routing::Routes.draw do |map|
# other routes omitted
map.with_options(:host => 'server2.example.com') do |add|
# create a named route for 'http://server2.example.com/thingies'
add.server2_thingies '/thingies', :controller => 'fake'
# create a named route for 'http://server2.example.com/thingies/combobulate'
add.enhance_server2_thingies '/thingies/combobulate', :controller => 'fake'
# create a named route for 'http://server2.example.com/mabobs/combobulate'
add.enhance_server2_mabobs '/mabobs/combobulate', :controller => 'fake'
# etc..
end
end
So then I can use server2_thingies_url and such in my views. This works, but it makes me feel like a bad person because there is no FakeController and I certainly have no intention of routing requests to it. I considered making helper methods and placing them in app/controllers/application_controller.rb, but a colleague made the argument that it is best to keep all route helpers in routes.rb, so things like rake routes will be accurate, for instance. Is there a better way?
I think I'd make a counter-argument to your colleague: if you're having to dirty up routes.rb with a "FakeController", then your rake routes is still not going to be accurate. In fact, I'd say that this is exactly the kind of thing that a helper was meant to help: it's taking logic that belongs purely in the view (link generation), and removing it from your view templates. Helpers are also easier to maintain and tweak.
Another advantage to the helper style is that if and when it's time to upgrade to Rails 3.x, the less hackish your routes.rb file is, the happier you will be - and that I can attest to from experience. :)
I'd just pass in :host to your foo_path or foo_url calls.
Seems cleaner than messing around with a FakeController
Is there a method like "full_url" such that #comment.full_url or full_url_for(#comment) returns "http://www.host.com/comments/id" where www.host.com is the default host domain and id is #comment.id. Or, if not, what would be an elegant way to generate this url string?
I'm pretty new at Rails, most of the methods I've learned insert the tag and other markup.
url_for is not helping because I can't do something like the following:
url_for(#comment, {:only_path => false})
I've spent way too much time trying to figure this out. It came down to either hacking or asking for the right way on SO. Here I am.
If you are setting up your routes correctly in your config/routes.rb file then you should have access to named routes in your controller and in your views. Which should mean that all you should need to do is:
comment_path(#comment)
Or for the full url
comment_url(#comment)
To see a list of all of the routes from the command line, you can type rake routes from the project root. Welcome to rails! Here is a good resource for rails 3 routing: http://guides.rubyonrails.org/routing.html
some additional resources via Railscasts:
http://railscasts.com/episodes/231-routing-walkthrough
http://railscasts.com/episodes/232-routing-walkthrough-part-2