I've started using omniauth in a project but having some issues in production vs. development. In production my RailsURI is /myApp and in development it's just /
In my templates I use <%= link_to "/auth/google" do %> which works for production but not development since I need to link to "/myApp/auth/google". My route look like this:
match '/auth/:service/callback' => 'services#create'
Ideally, I'd like to have some setup like:
<%= link_to provider_google_path %> generated for me for each provider I support. I guess I could support this by putting in a helper like <%= link_to provider(:google) %> but was wondering if there was a best practices way of solving this.
It appears there is a similar question here that has an answer. You may want to take a look at that.
Create named routes for OmniAuth in Rails 3
Related
Rails 5 has introduced new form helper method form_with.
How does it differs with form_for and when is it more appropriate to use?
This is really in preparation for rails 5.1 where only form_with should be used. It's meant to serve as a replacement for the two methods form_for and form_tag.
form_for and form_tag in Rails were very similar, both allowed you to create a form tag but the first one uses model’s attributes to build create or update form, while the second one simply creates an HTML form tag with the passed URL as action.
Use form_with (more up-to-date)
form_with is the latest.
form_for and form_tag are obsolete.
Why is there a change?
See Kasper Timm Hansen's pull request - I cannot state it better than pull request itself:
form_tag and form_for serve very similar use cases. This
PR unifies that usage such that form_with can output just
the opening form tag akin to form_tag and can just work with
a url, for instance.
This means you don't need to use form_tag if you don't have a model. You can use the form_with helper and it can still handle URLs.
Note Re: Ids and Classes: The Ruby 5.1 version of form_with, by default doesn't attach a class or id to the form. For Rails 5.2 and later, however, form_with WILL automatically generate ids based on the model, if present—basically the same id behavior as form_for, so you will NOT need to manually specify them anymore. (source)
Existing answers are great. What I also found helpful were the first few paragraphs here. Basically:
form_tag and form_for are soft deprecated and they will be replaced by form_with in the future.
DHH's proposal: https://github.com/rails/rails/issues/25197
The pull request: https://github.com/rails/rails/pull/26976/files (I didn't read it, but it could be useful)
This question stems from Hartl's Rails Tutorial (progressed in chapter 9) - sorry if it seems particularly noobish...
Currently, I understand that in the routes.rb file, when a page was defined using, for example:
match '/help', to: 'static_pages#help'
a link generated in an embedded ruby:
<li><%= link_to "Help", help_path %></li>
would function. The help_path, and specifically the word "path", would correspond to the "#help" defined in routes.
However, the routes file did not define links for items such as users_path (used to show all users), or edit_user_path(current user) (used to edit settings of the current user) - I was confused as to where they were defined, and how they are able to correctly function and link me the desired places.
Thanks!
The routes file does, in fact, get an entry determining the behavior of users (shown in listing 2.2). It gets created through the scaffolding described here.
resources :users
By convention a "resource" entry in your routes.rb file sets up a number of paths that will be associated with users. Refer to the Rails Guide for a good overview.
When connecting to an external json api and submitting a form to update a resource is it better to use form_for or form_tag ?
Specifically I'm using the Shopify API http://api.shopify.com/
In config/routes.rb I made default resource routes with resources :variants and now I'm trying to make a form that updates a variant resource but can't configure the form to have the proper action.
==== Update ====
Yes there's a shopify API gem: https://github.com/Shopify/shopify_api that does most of the heavy lifting- just can't quite figure out how to make it work.
To update an #variant object I need to PUT here: PUT /admin/variants/#{id}.json
But I can't quite construct the form_tag properly. I have these routes:
rake routes:
variants GET /variants(.:format) variants#index
POST /variants(.:format) variants#create
new_variant GET /variants/new(.:format) variants#new
edit_variant GET /variants/:id/edit(.:format) variants#edit
variant GET /variants/:id(.:format) variants#show
PUT /variants/:id(.:format) variants#update
DELETE /variants/:id(.:format) variants#destroy
Does your app define the Model? If so, you should be able to use form_for. If not, then you have to use form_tag.
form_for takes a Model instance as parameter (hence the name). Output of form fields is more concise, since form_for can infer a lot about from the model. You can also use fields_for to do nested forms.
If you use form_tag, then you need to write more code to properly construct the HTTP parameters so that Rails can reconstruct the params hash on the server.
So I just started using Dynamic segments as I need them to specify certain elements for grabbing data from AWS S3 via HTTParty.
I have this match statement in my routes.rb file:
match ':installation/:venue/:controller(/:action(/:id))'
This works great and allows me to do exactly what I want to do, which is pull in the installation and venue and use them with HTTParty to get their corresponding information from S3.
Now I need to keep my links through out persistent like these due to the fact that my application controller reads these in. So for example when I write a link_to I have had to do the following in a view/partial:
<%= link_to some_name,
"#{#installation}/#{#venue}/#{controller.controller_name}/show/some_id" %>
If it was just this ugliness I had to deal with that wouldn't be a problem, but I don't understand how I can pass around options in regards to this.
So basically is there a way to have resourceful routes for dynamic segments?
You can use polimorphic_url
http://apidock.com/rails/ActionDispatch/Routing/PolymorphicRoutes/polymorphic_url
I'm having trouble with a plugin on a rails 3 app called vote_fu_rails_3. This is a rails 3 compatible version of vote_fu by peteonrails. Both plugins are inspired by acts_as_voteable.
I have a site you can look at http://rubeddit.heroku.com - it's a reddit clone for a class i'm doing.
I am trying to get voting working. I have setup everything according to the instructions on the github page. I have a Link model that has_many :votes and my vote model has belongs_to :user and belongs_to :link.
When trying to do the method to vote_for a link by trying <%= link_to 'up', #user.vote_for(#link) %> I get a SQLite constraint error that voteable_id cannot be NULL.
You can see my code here am i doing something incorrectly? I'm open to any suggestions, i'm pretty new with rails.
Edit: The main issue i'm having seems to stem from voteable_id and voteable_type. These are from polymorphic associations. Since I only have the need to vote on Links (a single model) I guess I have the option of removing the polymorphic associations. Leaving them in place however would also make allowing Comments (yet to be added) to be voted on, fairly simple.