I have a resource blog.
I have a namespace admin that can create, see, delete blogs.
app/controllers/admin/blogs_controller.rb
Admin have its own portal
The route is pretty standard:
namespace :admin do
resources :blogs
end
and a standard user that have another portal and can just see the blogs and see the details of one blog.
I just implemented two methods in app/controllers/main_controller that look just like the index and show methods of Admin::BlogsController.
The route is:
get '/main/blog' => 'main#blog'
get '/main/blog/:id' => 'main#blog_show'
How can I improve my design?
is this solution which are you looking for?
namespace :admin do
resources :blogs
end
namespace :main do
resources :blogs, only: [:show, :index]
end
app/controllers/admin/blogs_controller.rb
Admin::BlogsController
app/controllers/main/blogs_controller.rb
Main::BlogsController
Related
I created a users table and implemented Devise. I then added an enum role to the user table so that I can identify admins, guides, and members.
What I'd like to do is limit routes for certain resources based on the enum user type. I've tried:
resources :users.guide do
get 'guide/dashboard', :to => 'guides#dashboard'
end
and some variants, but with no success. The above gives me the error:
undefined method `guide' for :users:Symbol
I've done some poking around and can't seem to find a good response. I'm avoiding CanCanCan and Rolify as I'd like to keep things as basic as possible. Any ideas? Thanks!
Edited Per Below Suggestion
So I went and updated my routes as suggested below so that the file looks similar to this:
Rails.application.routes.draw do
devise_for :users
#open to public
root 'welcome#index'
resources :guides, only: [:show], param: :username
resources :itineraries, only: [:index] #, only: [:index, :show]
authenticate :user, ->(u) { u.guide? } do
resources :guides, only: [:edit, :destroy], param: :username
get 'guide/dashboard', :to => 'guides#dashboard'
end
resources :locations, only: [:new, :create, :edit, :update, :destroy, :index, :show]
end
For whatever reason, the guide profile show/edit works fine; the dashboard works fine; but the other things outside of the authenticate block (itineraries and locations resources) don't work, I get redirected to the Devise login page. They are outside (and in one case above) the authenticate block, not sure why this is occurring with some resources/routes and not others.
You can use devise helpers. With authenticate, it is possible to make resources and routes that will ask for authentication before they can be accessed. Replacing authenticate with authenticated causes the resource to simply be unavailable if the user is not authenticated. Both helpers take an optional scope and block to provide constraints on the model instance itself.
authenticate :user, ->(u) { u.guide? } do
get 'guide/dashboard', :to => 'guides#dashboard'
end
So your problem is limit routes for certain resources based on the enum user type. I suggest you should implement the authorization stuff instead of trying to create more resources/scopes in your route, it's correctness.
I have a rails application that needs to search two different collections independently, but both are indexed in a single solr instance. However, when i try to search in one collection, when i get to the item i want displayed, it reroutes to the same id within the other collection. How should i adjust my routes.rb to remedy this?
Here is the code:
Rails.application.routes.draw do
get 'biofile/search'
get 'masterfile/search'
mount Blacklight::Engine => '/'
Blacklight::Marc.add_routes(self)
root to: "catalog#index"
concern :searchable, Blacklight::Routes::Searchable.new
resource :catalog, only: [:index], as: 'catalog', path: '/', controller: 'catalog' do
concerns :searchable
end
resource :masterfile, only: [:search], as: 'masterfile', path: '/masterfile', controller: 'masterfile' do
concerns :searchable
end
resource :biofile, only: [:search], as: 'biofile', path: '/biofile', controller: 'biofile' do
concerns :searchable
end
devise_for :users
concern :exportable, Blacklight::Routes::Exportable.new
resources :solr_documents, only: [:show], path: '/catalog', controller: 'catalog' do
concerns :exportable
end
resources :solr_documents, only: [:show], path: 'masterfile', controller: 'masterfile' do
concerns :exportable
end
resources :solr_documents, only: [:show], path: 'biofile', controller: 'biofile' do
concerns :exportable
end
resources :bookmarks do
concerns :exportable
collection do
delete 'clear'
end
end
get '/catalog/masterfile/', to: 'masterfile#search', as: 'masterfile'
get '/catalog/biofile/', to: 'biofile#search', as: 'biofile'
get '*path' => redirect('/')
end
are you asking about nested routes? you want the path to look like model1_model2_path? the below example will give you group_memberships_path to use in your view and the url would have the id of the group and the id of the membership like .../groups/22/membership/13/edit
use rails routes in rails 5.x or rake routes in rails 4 to see the list of your new routes and you can see the urls will take 2 id's that can be passed to your application.
# nested routes for groups
resources :groups do
resources :memberships
end
I think you'll need to override this method https://github.com/projectblacklight/blacklight/blob/9f676994f437f7664cfc2b5c4dffe4382a6d14d3/lib/blacklight/search_state.rb#L48 either by configuration or monkeypatch to behave differently based on some info in solr document
I'm working on creating a wiki app from scratch with the following organization:
Main Controller: Wiki
Nested Controller: WikiCategories
Nested Controller: WikiArticles
In my config/routes.rb I have:
resource :wiki do
resources :wiki_categories, :as => :categories
resources :wiki_articles, :as => :articles
end
I've chosen to name the categories and articles controllers as WikiCategories and WikiArticles to differentiate from other category and article controllers that I want to make in the future under a blog nesting.
This gives me the following routes:
/wiki/wiki_categories/new
/wiki/wiki_articles/new
Is there any way to rewrite the routes to be:
/wiki/categories/new
/wiki/articles/new
... while still using the WikiCategories and WikiArticles controller names?
I've chosen to name the categories and articles controllers as WikiCategories and WikiArticles to differentiate from other category and article controllers that I want to make in the future under a blog nesting.
IMO, it seems like you're bucking convention a bit. As discussed in Controller Namespaces and Routing, why not do:
namespace :wiki do
resources :categories, :articles
end
Which will give you:
wiki_categories GET /wiki/categories(.:format) wiki/categories#index
POST /wiki/categories(.:format) wiki/categories#create
new_wiki_category GET /wiki/categories/new(.:format) wiki/categories#new
edit_wiki_category GET /wiki/categories/:id/edit(.:format) wiki/categories#edit
wiki_category GET /wiki/categories/:id(.:format) wiki/categories#show
PATCH /wiki/categories/:id(.:format) wiki/categories#update
PUT /wiki/categories/:id(.:format) wiki/categories#update
DELETE /wiki/categories/:id(.:format) wiki/categories#destroy
wiki_articles GET /wiki/articles(.:format) wiki/articles#index
POST /wiki/articles(.:format) wiki/articles#create
new_wiki_article GET /wiki/articles/new(.:format) wiki/articles#new
edit_wiki_article GET /wiki/articles/:id/edit(.:format) wiki/articles#edit
wiki_article GET /wiki/articles/:id(.:format) wiki/articles#show
PATCH /wiki/articles/:id(.:format) wiki/articles#update
PUT /wiki/articles/:id(.:format) wiki/articles#update
DELETE /wiki/articles/:id(.:format) wiki/articles#destroy
Then, create namespaced controllers, something like:
app/controllers/wiki/categories.rb
class Wiki::CategoriesController < ApplicationController
...
end
and
app/controllers/wiki/articles.rb
class Wiki::ArticlesController < ApplicationController
...
end
Yes it is by specifying the controller, the resource can then be named whichever way you like.
resource :wiki do
resources :categories, controller: 'wiki_categories'
resources :articles, controller: 'wiki_articles'
end
Please see the guide for further information.
You can use the path: option as follows:
resource :wiki do
resources :wiki_categories, path: 'categories', :as => :categories
resources :wiki_articles, path: 'articles', :as => :articles
end
Which will give you:
/wiki/categories/...
/wiki/articles/...
See Translated Paths section of the guides for further details.
In my application, a User can make a Post, and a User can make Correction (think of it as a comment) on another user's post. Each User can have many Posts, and each Post can have many Corrections.
On each show page for a Post, there is a form to create a new Correction. This uses the user_post_corrections path.
On the show page for each User, I would like to display each Correction they've submitted for any Post. This requires a user_corrections path.
In order to achieve this, I have the following in my routes.rb:
resources :users do
resources :posts do
resources :corrections
end
end
resources :users do
resources :corrections
end
This intuitively feels bad to me, as I've created two nested routes that are very similar to one another.
Is there a better way to do this? My code is working fine as it is but is there a best practice method for implementing this kind of model?
Routing concerns are an excellent but underused tool for DRYing out your routes:
concern :correctable do
resources :corrections
end
# just an example of multiple concerns
concern :commentable do
resources :comments
end
resources :users, concerns: :correctable
resources :posts, concerns: [:correctable, :commentable]
However you should take when creating nested routes so that you are not nesting needlessly.
Often you might want the collective actions [new, index, create] to be scoped by the parent:
GET|POST /posts/:post_id/corrections
GET /posts/:post_id/corrections/new
While you want the member actions to be unscoped since you can always access a record directly if it has a unique id.
GET /corrections/:id
GET /corrections/:id/edit
PATCH /corrections/:id
DELETE /corrections/:id
To do this you would declare the routes like so:
resources :corrections, only: [:show, :update, :edit]
concern :correctable do
resources :corrections, only: [:new, :index, :create]
end
resources :users, :posts, concerns: [:correctable]
The shallow: true option does something like this but does not work well when you declare the same resources several times as it adds unscoped routes for every call.
The goal is to create a URL like this for a GET, REST API:
/manager/someID/report
example: /manager/2/report
I can get it to show in rake routes if do it this way:
get 'manager/:id/report', to: 'report#show'
But in some weblogs I read, thats the way unskilled developers write their routes! and looks like the better way is to use "nested resources" so I am banging my head over desk to get nested resources working the same way...but no success
this is what I have written so far:
resources :manager, only: [:show] do
resources :report, only: [:show], controller: 'report' do
member do
## WAT ?!
end
end
end
First, you might want to consider reading different blogs if they're calling routes like that "unskilled".
What you proposed is actually fine considering it's a non-standard RESTful route, and maybe even preferable in some cases. If you want an alternative approach, you have a couple different options. I don't think any one is more right than the other, but I prefer the first because it takes up less vertical space.
resources :manager, only: [:show] do
get 'report' => 'report#show', on: :member
end
or
resources :manager, only: [:show] do
member do
get 'report' => 'report#show'
end
end