So I know how to submit a form to a server via form_for to a model's create and update methods, but if a model has some method foobar, how do I submit a form specifically to the foobar method? I tried specifying :method => "foobar" but that didn't seem to do the trick. How can I submit a form_for that goes to a non-RESTful method?
EDIT:
I don't want said method to be accessible to anyone by typing the address in their address bar. eg. www.site_name.com/controller_name/foobar should not be valid - the foobar method should solely be used for processing the submitted form.
You can use the :url optional parameter to form_for to specify the url you want to post to.
form_for(#model, :url => foobar_model_path) do |f|
...
end
Related
I am developing a Rhomobile application,on submit of a POST method, i am going to my 'Model 1' action, after execution of my action i want to redirect to another model's (Model 2) Index action and list the data.
I am from a Rails background, there i would have used URL, any similar concept exists here or any solution.
i tried, but it didn't worked for me render :controller => :model2, :action => :index
Please Note: I have never used rhodes and all of this information was acquired by simply reading the API documentation and taking a look at the source code.
According to the documentation You should be able to deal with this in a very railsy fashion eg
def some_action
redirect controller: :model2, action: :index
end
Seems the only caveat is if this redirection is to happen in a callback function. In this case the redirection should be handled by the WebView instead e.g.
Rho::WebView.navigate(url_for(controller: :model2 action: :index))
Source for Rho::RhoController#redirect supports these statements in the documentation.
Additionally as you might notice above it appears that Rho has ported a lot of the rails like helpers including url_for
The following rails routes.rb file
resources :aggregators, :constraints => { :protocol => "https"} do
collection do
get :confirm
post :send_sms
end
member do
post :confirmed
post :failed
post :cancelled
end
end
is not being called. When a form calls one of these actions,
<%= form_for(#aggregator) do |f| %>
the user gets bounced to the root page of the application. In comparing with and without the constraints, the non-https activity picks up
Started POST [...]
Processing by AggregatorsController#create as HTML
whereas the https version
Started POST [...]
Processing by AggregatorsController#index as HTML
So clearly the routing is missing the create action. (the bouncing back to home is an applicationController method which aplies a policy on the index action) I assumed it would be an integral part of resources. What am I doing wrong? Better yet I only want to invoke https on specific actions and would like to keep the focus on new, create and confirm...
I have the following two form_for() that I am confused about.
# form for users
form_for(#user) do |f|
# form for sessions
form_for(:sessions, url: login_path) do |f|
I understand that the first one is simply go through all the users and input the form. I am not sure why when you create a new session, the parameters for form_for is listed as such. Why is there a login path?
Michael Hartl explained it as "in the case of sessions we need to indicate the name of the resource and the corresponding URL", but that doesnt' really explain anything to me.
any enlightenment would be nice!
Passing :url to form_for method is optional when dealing with a model object. when using it to create a new object:
# long-style:
form_for(#user, url: users_path)
# same thing, short-style (record identification gets used)
form_for(#user)
In the short-style version a concept called Record Indentification is used, basically rails figures out if the record is new by asking record.new_record? It also selects the correct path to submit to based on the class of the object, in this case #user.class
Same principle applies when using form_for when updating an existing object. In this case the record.new_record? returns false, and rails figures out it must submit the form to the update action of the controller.
In cases when the path that the form must submit to cannot be figured out by rails using the above mechanism, then the url must be provided explicitly. This also applies when defining Singular Resources such as resource :geocoder. when creating forms for singular routes, the URL must be specified:
form_for #geocoder, url: geocoder_path do |f|
In the first case, the form_for helper inspects the #user variable to see its state. The User might be a new record (in which case the form points to /users with POST*) or an existing record (users/:id with PATCH). It can also provide pre-filled inputs based on the variable's state.
The second form is used when there's no need for an instance of a model (or maybe the model doesn't even exists) and the form_for helper is used just for convenience. The url parameter is explicitly set because by default the action would point to the current URL and you want it to point to login_path.
*Technically they are both POST on the browser side, Rails will distinguish between them later.
So I've got a Padrino app with a controller that looks roughly like this (simplified for brevity):
App.controllers :questions do
get :index, :with => :id, :provides => [:html, :json] do
# Stuff
end
post :index, :with => :id, :provides => [:html, :json] do
# Other stuff
end
end
If I hit "questions/1" in my browser, I see the HTML page for the given question. If I hit "questions/1.json", I see the JSON representation of the question. Exactly like I'd expect.
Now, if I submit a POST request to "questions/1" via a web form, it works. But if I try to send a POST request to "questions/1.json" (signaling that I want the response in JSON format—or at least that's how I thought it worked), I get a 405 Method Not Allowed.
I'm guessing there's something basic I'm misunderstanding here. What am I missing? More importantly, how should I define a route to accept POST requests and provide either HTML or JSON responses?
Well, I'm not really sure why this was happening; but for now I've gotten around the issue by setting the "ACCEPT" header in my POST request to "application/json" instead of tacking ".json" onto the end of the URL (and upon my limited internet research, this may be the preferred approach anyway).
I am trying to develop a RESTful Sinatra application. Now, I know how to respond to a delete request with something like
delete '/user/:id' do |id|
#do something in the model
end
What I am interested in is how do I get to execute that method. I can't have link that does a DELETE instead of a GET, can I?
The only solution I found so far is sending a DELETE request via jQuery: How to send a PUT/DELETE request in jQuery?
I tried looking into different RESTful Sinatra projects on github but my Ruby knowledge is probably to limited to get how they are doing it.
Put following line in your code.
use Rack::MethodOverride
It will help you interpret post methods with parameter "_method" with value "delete" as put.
Then you can write
delete '/user/:id' do |id|
I thinks it's like the Rails way. You need define a params '_method' with 'delete' value and add it on your form.
When you POST you form with this particular params, you do a DELETE request in sinatra.
Like :
<form action="/search" method="post">
<div style="margin:0;padding:0">
<input name="_method" type="hidden" value="delete" />
</div>
</form>
It's the same with PUT method
Another way is to use Curl:
curl -X DELETE http://host/user/1
%form{:action => "/note/delete/#{#note.id}", :method => "post"}
%input{:type => 'submit', :name=> "_method", :value => 'delete', :class => 'button'}
You can also trigger the delete route with a button like so
see also Call Sinatra delete route with jQuery for how to do this with jQuery and JSON at the front end and Sinatra on the back end.