I am new to rails and have a question on how to best route my particular application. I am using a legacy database so the schema is already set and complicates things a bit. The layout of the app includes a top navigation bar that includes 'users' and then for a particular 'user' there is another navigation bar to display/edit a variety of forms. For example once a particular 'user' is queried there are seperate forms for 'general information' and 'account information', etc.
The setup I have now is to have a 'users' namespace to correspond to the top level navigation and in the namespace have the second level of navigation: 'general', 'project', etc. With this setup each form selected from the second level of navigation has its own controller which seems a bit odd.
namespace :users do
resources :general, :project
end
This allows me to have the following urls where :id belongs to 'user'
/users/general/:id
/users/general/:id/edit
/users/account/:id
/users/account/:id/edit
Does this seem reasonable or does anyone have any other ideas on how to deal with a nested navigation setup in a RESTful way? The legacy database complicates in that I do not have a 'general','account' model or DB table. For each form I need to pull from several models/tables that have associations with the 'user' model. Having a 'general' controller while not having a 'general' model does not seem very rails like which is what is bothering me.
You're headed in the right direction, however, namespaces aren't going to help you maintain the assocations you're looking for. Instead, I'd try this:
resources :users do
resources :general, :project
end
I'd also recommend taking a look at the Rails routing guide.
Related
the title sounds strange, so is my problem... I am building a simple app - I have a restaurant model which has_many meals that users can add to their carts as orders(the order model has a meal's id and a quantity). Now, I would like to be able to add options to the meals - e.g. a pizza meal would have "small", "medium", and "large" option which would affect the price of this item. How do you think is the best way to implement this?
My problem is that each meal might have different options, and options can have different prices. Therefore, I cannot just add an attribute "option" as a string. On the other hand, if I use another model, there would be too much nesting in the routes which I read is a bad practice:
resources :restaurants do
resources :meals do
resources :options
end
end
How to avoid this? Thank you for any suggestions!!
There's no reason not to have an options model to hold each of your options as necessary - though you should really consider a shallow route for restaurants as the restaurant itself has nothing to do with options. So instead your routes might look like:
resources :restaurants, shallow: true do
resources :meals do
resources :options
end
end
If you look at your routes now (rake routes) you'll see how much they change.
But its worth considering that you don't need the resources for options. A visitor won't be creating new options. They'll be adding existing options to a collection (meal + option = order .. or something similar) -- so you might only have that route in the admin namespace for creating new options for a menu.
If I were to have for example a 'languages' model view and controller. Then within that I were to have tracks, and then within that I were to have lessons. How would I go about making a route for the lesson, would it be:
/languages/:language_id/tracks/:track_id/lessons/:lesson_id
Doing this would mean nesting them, something which is advised against.
My question is how would I create a route that would suit this and still convey to Rails the parent and it's identifier?
Yes you are right. You shouldn't nest your route no more than 1 level deep. However to get the approach you are after by using shallow nesting as highlighted here: Section 3.7.4. Primary purpose for this is to generate the collection actions scoped under the parent, so as to get a sense of the hierarchy. So you could do:
resources :languages, shallow: true do
resources :tracks do
resources :lessons
end
end
I am little bit confused in using rails route. I need some suggestion about customizing my url.
This is my current url
http://localhost:3000/posts/product/41?product_id=2
and
http://localhost:3000/posts/product/41?model_id=24&product_id=2
This is my link
<%= link_to product_model.name, controller: :posts,action: :product,product_id: params[:product_id],model_id: product_model.id
Logically product should come first in url. But why model prefers first here.
And i need my url something like this
http://localhost:3000/posts/product/41/mobile
and
http://localhost:3000/posts/product/41/mobile/nokia
Since i am not familiar with rails route i didn't write any special coding in my route
Here is the simple route exist
resources :posts
Ok your question here actually contains two different problems, so i will give suggestions to both.
1. Nested resources
Your first problem is to use "nested routes". Rails guide has a long and good article about routes and how to write and use them, including nested routes. You can check it out here: http://guides.rubyonrails.org/routing.html#nested-resources.
However in your situation would the solution look something like this:
resources :category do
resources :sub_category do
resources :products do
resources :models
end
end
end
You can now greate links like this
<%= link_to product_model.name, category_sub_category_product_model_path(#category, #sub_category, #product, product_model) %>
You can see that i have removed posts, see 3. Refactor design to see why. If you really want this as a action on posts, should you however do something like this (but would recommend this!):
get "posts/product/:category_id/:subcategory_id/:product_id/:model_id", to "posts#product", as: :posts_product
This would be used like this in your views:
<%= link_to product_model.name, posts_product_path(#category, #sub_category, #product, product_model) %>
2. Pretty URL's
Your second problem is to use model names instead of id's in your urls. The simpels solution for this is having a unique attribute on your model that you can use instead of id, and then just add a to_param method. Fx for product could we do something like this:
class Product < ActiveRecord::Base
def to_param
name
end
end
Ryan Bates have made a good screencast about this: http://railscasts.com/episodes/63-model-name-in-url-revised. If you want something more flexible should you use the gem Friendly Id. And again does Ryan comes to the rescue with another great RailsCast: http://railscasts.com/episodes/314-pretty-urls-with-friendlyid.
3. Change design
Ok well so this is just my opinion, feel free to ignore it. But their is some bad practices and signs in your examples, so let me just quickly go through what i think you should improve on.
Restful actions
You should, when possible always avoid creating controller actions that is not restful (simply put is the base actions index, show, new, create, edit, update and destroy the only restful actions). In your example does this mean that the product action of the posts controller should be changed to something restful. Why not move it to the product model controller and call it "show"?
Deeply nested resources
You should avoid nesting your routes to deeply. Is it really important to show both the category, the sub category, the product AND the model in your url? Maybe that's how your models are associated internally in your application but why should the user know this? If you don't have a list of subcategories at "/posts/product" and a list of products at "posts/product/41" is there no reason to have so long a route. A rule of thumb is "nest no deeper then two levels", ie. ":category/:sub_category". Further more does short routes mean better SEO.
As i said, feel free to ignore these suggestions, your application would work without these changes. However changing these things would greatly help you structure you code, and keep your codebase clean and maintainable. These rules and principles is not something i have just conjured out of nothing, but very accepted principles in the Rails community. You can google each of these principles or patterns and see a lot of articles and posts on why it's a good idea to follow them, especially when you work with Rails.
Resources
Rails Routing from the Outside In — Ruby on Rails Guides
norman/friendly_id - Github
#314 Pretty URLs with FriendlyId - RailsCasts
#63 Model Name in URL (revised) - RailsCasts
Take a look at the friendly-id gem
There's a great RailsCast about it
Add this to your model inmodel.rb
def to_param
name
end
and then add
#model = Model.find_by_name(params[:id]) to your show method, then you can get the url as you mentioned above.
PS: You Should have name field for Model table in your schema.
I think you are looking for nested routes. Please refer this link http://guides.rubyonrails.org/routing.html#nested-resources
and use to_param method in the model if you want to display model_name instead of id as explained by #Ajay Kumar
def to_param
name
end
where name is the model attribute for that specific model.
Why not a namespace?
namespace :posts do
resources :products
end
This should do I think..
Namespace does not include restful ids into the scope..
I have an application, built with Rails 3.1.3, that has products and categories. The categories are related to other categories, so a category can be a parent or a child category. The products are then related to a child category.
Now, I'm thinking about how I should define the routes. Is it a good idea to somehow nest the categories and products resources? Ideally, I would like URLs like this:
example.com/parent/child/product-1234
like this:
example.com/clothes/underwear/some-socks-1234
or maybe like this to keep it restful?
example.com/p/clothes/c/underwear/....
But maybe that's a bit messy to achieve with the routes? I would have to nest the category with itself I guess?
Any ideas on how to achieve something like this?
EDIT:
Do I create the category routes like this:
resources :categories, :as => "parent" do
resources :categories, :as => "child"
end
or similar? It's not that important to have the product nested inside the categories. Maybe it will just make it hard to manage...
You can either be RESTful or not, you can't have it both ways.
If Category is a resource, then you can define routes with resource :categories statement and use Rails built-in support for REST. But then all categories should be accessible through categories/id. If you want different categories be accessible through different routes, then you are not RESTful and you can't use Rails REST support.
Alternatively you can say that parent and child categories are different resources and be RESTful again.
Edit: looking at my answer now (after it was accepted) I feel like I was probably too stiff. The answer should probably be "it depends" (as usual). If the application is CRUD (admin), I would stick to plain categories and nested products (shallow). On the storefront where you need nice looking url you can totally have non-REST routes and actions. It just mean more coding.
I would add an extra route besides the RESTful ones to support your URLs. This ignores the categories (they don't even have to exist) and routes directly to the product.
...
resources :products
resources :categories
match ':parent/:child/:product' => "products#show"
...
In your show action you can simply check which of params[:product] and params[:id] that is set and handle the different routes.
params[:parent] and params[:child] will also be available but i would suggest just looking for the product and get the category through that object since that should be more reliable.
Say I have this setup:
My model is 'content', and I want to use this model in 2 controllers.
blog_controller.rb
article_controller.rb
My 'content' model has a property 'content_type' which tells me if this content is a 'blog' or a 'article'.
This seems to prevent me from doing:
resources :article
resources :blog
right? since the models are different? or can I still do this?
You can still do it.
In your routes file, the resources method is, by default, looking for a controller of the same name that you pass it. So regardless of what the model's name is, if you have a controller named blog_controller you can do resources :blog
In classic SO fashion, instead of answering your question I'm going to criticism your implementation ;-)
I think the root of your problem is that you want a single table for content, with code shared between articles and blogs. In rails, the way to do that is called "Single Table Inheritance".