I am incredibly new to Ruby, so I apologise in advance if this question seems very simple or vague.
Where, when using jsonapi-resources is the base path for JSON API links specified? I wish to change from specifying full URLs to root-relative paths to these resources.
I've found the routes.rb which has
Rails.application.routes.draw do
# Route / to the front-end
root to: 'root#index'
namespace :api do
jsonapi_resources :widgets
// ...more jsonapi_resources calls
end
I am guessing you are looking for something like this?
Rails.application.routes.draw do
namespace :api do
namespace :v1 do
jsonapi_resources :cars, only: [:index]
end
end
end
Related
I have a JSON route path that looks like this:
/jobs/{jobid}/employees/{employeeid}/departments/cubes/{cubeid}/register
The following route works fine when there was no cube and cubed:
resources :departments, only: [] do
get 'register', on: :collection
end
I tried doing this:
namespace :departments do
resources :cubes, only: [] do
get 'register', on: :collection
end
end
What change do I need to do in the above code so it will work with the route path?
When I add:
resources :jobs do
resources :employees do
namespace :departments do
get 'cubes/:cube_id/register',
to: 'cubes#register'
end
end
end
to my routes.rb and then run rake routes, I get this line in my output:
GET /jobs/:job_id/employees/:employee_id/departments/cubes/:cube_id/register(.:format) departments/cubes#register
It's not a good practice to nest resources more than 1 level
http://guides.rubyonrails.org/routing.html
Resources should never be nested more than 1 level deep.
http://weblog.jamisbuck.org/2007/2/5/nesting-resources
Rule of thumb: resources should never be nested more than 1 level
deep. A collection may need to be scoped by its parent, but a specific
member can always be accessed directly by an id, and shouldn’t need
scoping (unless the id is not unique, for some reason).
I would like to customize my path helpers in Rails 4.
I have a Site5 website (which uses Apache server) with multiple subdomains. I have rewrite rules in my .htaccess file which adds the folder name to the url. For example
cs1337.mysite.com/login
is rewritten to
cs1337.mysite.com/cs1337/login
In routes.rb, I have added a scope in routes.rb:
scope '/cs1337' do
get '/login', to: 'sessions#new', as: :login
# etc.
end
which gives me the correct routing. Everything works, but the annoying thing is that all my path helpers have the '/cs1337' prefix, which is unnecessary since the .htaccess rewrite rules add it back in. For example,
login_path # => /cs1337/login
when only
login_path # => /login
is necessary.
I would like to override all of the path helpers to strip off the prefix, using something like
def <override all path helpers>
path = super
path.gsub(%r{^/cs1337}, '')
end
I know the path helpers are dynamically generated, but I can't figure out where start ... I can't even find what module the path helpers are generated in.
Thanks for any help you can offer!
Short answer: No, as far as I can tell.
I couldn't find anything that lets you have the route Rails intercepts be different from the path that the helpers give you. I don't think Rails plays well with .htaccess rewrites.
Do you need the folder name to be in the path? If not, I would remove the scope '/cs1337' do and use something like this StackOverflow post to do domain-specific routes.
If you need it there, I would recommend being okay with the end user seeing "cs1337.mysite.com/cs1337/path".
Ok everyone,
i am using rails 4.2.0
so i have created three scaffolds but needed to add an additional view to one of my models.
I have a Site and Resident model and what i am looking to accomplish is to create a resident thst ties directly back to the site from a link on the site show page.
In my site controller i have the following.
def new_site_resident
#site.residents.create(resident_params)
end
AND
def resident_params
params.require(:resident).permit(:site_id, :unit_number, :f_name, :m_name, :l_name, :dob)
end
im my routes folder i have
get "/sites/:id/new_site_resident"
and have tried get "/sites/new_site_resident
when i use the get "/sites/new_site_resident it comes back with this error:
Couldn't find Site with 'id'=new_site_resident
^^ i am sure this is telling me it is looking for a site with that as the id.
when i use get "/sites/id/new_site_resident" in routes.rb and then try to go to:
http://localhost:3000/sites/1/new_site_resident it gives the error of:
No route matches [GET] "/sites/1/new_site_resident"
not too sure where to go with this? but as i said before i want to be able to look at the site and then be able to directly create a resident in that link that ties back to the site without having to manually enter the site id as the end uses would know that the site id would be.
Current routes.rb file.
Rails.application.routes.draw do
root 'home#index'
resources :sites
resources :vehicles
resources :residents
get "/sites/:id/new_site_resident"
devise_for :users, controllers: { registrations: "registrations" }
To create route to your action, you can use resources:
resources :sites do
member do
get :new_site_resident
end
end
then you can remove
get "/sites/:id/new_site_resident"
Just move
get "/sites/:id/new_site_resident"
line to the start of the routes file. File should look like
Rails.application.routes.draw do
root 'home#index'
get "/sites/:id/new_site_resident"
resources :sites
resources :vehicles
resources :residents
devise_for :users, controllers: { registrations: "registrations" }
Or try member routes to define this route like
resources :sites do
member do
get :new_site_resident
end
end
sinatra-authentication expects a layout.haml for its pre-rolled authentication views.
How do I specify a different layout template that sinatra-authentication can use (e.g. auth_layout.haml) so that I can keep layout.haml for my app's views?
My current not-ideal approach to this is to:
Allow sinatra-authentication to use the standard layout.haml
Explicitly use another layout file (e.g. std_layout.haml) in all other parts of the app
e.g.
...
erb :home_page, :layout => :std_layout
...
I'd prefer it the other way around :)
You may read on Layout Engines or simply try:
get '/login' do
haml :login, layout: auth_layout
end
EDIT-1: your comment is Ok layout: auth_layout is ruby 1.9 syntax :layout => auth_layout is syntax used before 1.9
And if you are talking about this sinatra-authentication you must hack this file's app.get '/login/?' method regarding (Module::Helpers#use_layout?).
EDIT-2: I guess overwriting use_layout? method will help you, perhaps something like
Module Sinatra
Module Helpers
def use_layout?
request.xhr? ? false : :auth_layout
end
end
end
I want to be able to follow a convention closer to what Rails does with resourceful routing. For example, I'm considering "signups" to be a resource, with it's own controller containing "new" and "create" actions.
In app/controllers/signup.rb I have:
MyApp.controllers :signups do
get :index do
# ...
end
post :index do
# ...
end
end
Is there any way I can use these route names, while actually responding on a path other than '/signups'? It feels like Padrino's route naming system is very tightly coupled with the URLs the routes map to.
I've tried:
MyApp.controllers :signups, :map => '/another-path' do
# ...
end
Among various other things without success. Perhaps I should just go back to using Rails... I was just getting frustrated with the startup overhead in TDD and I'm embarking on a new project at the moment (please don't refer me to Spork... that has it's own issues).
This is how I would do what you are asking
# in app/controller/signups.rb
MyApp.controllers :'another-path' do
get '/' do
# ...
end
end