I've read many posts about doing Rails nested forms, which I think I understand. And I've read several posts about limits on HTTP GET requests, which I also think I understand. But I have not seen any question/answer regarding their combination, so here goes...
If the limit on an HTTP request is somewhere between 256 and 2048 (approximately, and depending upon browser, server configuration, etc, etc), does this then put a caution on how elaborate one gets with a nested attribute form in Rails? So I have, for example, an Service Invoice form which has work items (that include descriptions for each) as a nested attribute (separate SQL table) and a list of payments (another nested attributes). If make all this editable on one form and want to do a Submit button to update all the data, does Rails attempt to pass all this stuff in one HTTP request string back to the server? So then, if it's possible that all my invoice header info, work item descriptions, and payment descriptions all total more than, say, about 2K bytes of info, I will not be able to use a single nested form for data entry?
Thanks.
The HTTP request limits you mention are only for GET requests; that is, those are limits on the length of a URL, and in a GET request, all data is included in the URL.
However, a form submission that is meant to create or update a resource should always be a POST or PUT request, not a GET. The only time this would be an issue would be if you were, for example, doing a very elaborate search form, so that you were filling out a complex form but doing a GET request (i.e. not doing any update). That seems unlikely, and in that case it would probably be appropriate to turn that into a POST (e.g. identify a new resource that you're creating).
Related
I'm trying to get the field values submitted through survey monkey forms. Since its in a seperate iframe, i cant access it from my domain (CORS). Is there any api to get the individual responses submitted through these forms?
You mean you're using a website collector and the responses are embedded on your website, and you want to read the responses in javascript when the user submits the form? Yes that won't work.
Either way I think the best way to do it is to use the API.
You can fetch the list of survey responses (and their details) see the docs.
To get the list of responses for a survey you would do:
GET /v3/surveys/<survey_id>/responses
You can filter by date or other fields (if you need be).
You can fetch the full details with
GET /v3/surveys/<survey_id>/responses/<response_id>
Alternatively, you can setup a webhook where you'll be notified every time a new response comes in, you can then make the request defined above to get the details of the response.
Hopefully those options work for you, I don't know your use case well enough to give other options.
I have a page with a list of items and above the list I have multiple links that act as filters. Clicking on the links causes an ajax request to be fired with a whole host of URL parameters. Any example set of params after clicking a few filters:
?letters=a-e&page=1&sort=alphabetically&type=steel
It is all working fine but I feel like the params on the URL are very messy, and the code behind has to do alot of checking to see which params exist, merge new ones, overwrite existing ones etc.
Is there a nicer way to accomplish this without URL parameters.
I guess the downside to that would be the fact a user would not be able to link to a specific filtered view or is there a way this could be accomplished too?
You have several options when working with long query strings. If this isn't really causing a problem (like requests dying) then you should ask yourself if it's really worth the effort to switch it to something else.
Use POST Requests
If the length of the query string is causing problem, you can switch to using POST requests instead of GET request from your filter links. That will prevent the URL from containing the filter parameters, but your controller can still deal with the parameters in the same way.
The link_to helper can be setup to use a different HTTP verb as follows:
link_to("My Filter", filter_path, method: :post)
Make sure you update your routes appropriately if you use this technique.
Use an Ajax Request to Refresh the Page
If you configure your filters to all be remote (Ajax) links, you can update the filters and refresh the contents of the page without ever changing the URL. This is the basic pattern of the solution:
Send a remote request to the server with the current filter options
Update the page contents based on those filters
Make sure the filters (and remote request) will submit all of the current parameters again
Store Filters in the User's Session
If you store the current filters in the session, whenever the user visits the base page, you can retrieve the stored filters and only display the appropriate information. Your filter links could still be GET requests (including the lengthy query strings), but instead of rendering the page after the filter request, you would redirect back to the main list with no extra query parameters. That would make it appear to the user that the URL never changed, and would even allow you to remember their last filter if they navigate away.
Sharing Links
Like you mentioned, sharing links becomes a problem with all of these solutions. You can provide a "share this filter" section on the page to help mitigate that. You would put a URL the user could copy in that section that includes the necessary information to recreate the filter. The links could contain the full query string or perhaps an encoded version of the filter.
New to web development, my understanding is that GET is used to get user input and POST to give them output. If I have a hybrid page, eg. on StackOverflow, if I write a question, it POSTs a page with my question, but also has a text box to GET my answer. In my routes file, what method would the URL associated with my postQgetA() method specify - GET or POST?
From technical point of view you can use only GET to perform almost every operation, but...
GET is most common method and it's used when you ie. click on the link, to get data (and do not modify it on server), optionally you send id of the resource to get (if you need to get data of single user).
POST is most often used to sending new data to the server ie. from form - to store them in your database (or proccess in any other way)
There are also other request methods (ie. DELETE, PUT) you can use with Play, however some of them need to be 'emulated' via ie. ajax, as there is not possible to set method of the common link ie. to DELETE. It's described how to use non-GET/POST methods in Play! (Note, that Julien suggests there, using GET for delete action although is possible it's a broken semantics.)
There are also other discussions on StackOverflow where you can find examples and suggestions for choosing correct method for your routes.
BTW, if you sending some request, let's say it's POST you don't need to perform separate GET as sending a request generates a response in other words, after sending new question with POST first you're trying to save it to DB, if no errors render the page and send it back in response.
using asp.net mvc, I'm initializing a list in the server code, and allowing the end-user to add to the list on the form (using JQuery to add entries). I know how to obtain a list's selected items on a post back, but I don't need to do that here. I want the complete contents of the list accessible in the server code after a post back.
Is a posted list just not going to give me the full content? Should I use Ajax to send each item to the server as each items gets added to the list?
thanks
There are a couple of ways that I can think of doing this.
make an ajax call each time an item is added - as you suggested
when an item is added to the list, you also add a hidden field to the form that will be submitted. Then on post back (although that terminology is very Web Forms-y), in your action method, you'll have access to the contents of the list. If you name things correctly you should be able to model bind to a List.
The latter would be my preference, it depends on your particular situation though.
Some things to keep in mind:
Bandwidth from the user to the web server is very small compared to bandwidth from a database to the web server
The database most likely cached whatever query you just ran to populate that list
It sounds like you're asking for the entire list to be included with the postback data, and that means having the browser upload that data for the user.
With all that in mind, it should be obvious that you're better off rebuilding your base list from the database.
I'm writing a web form for my Ruby on Rails app. The form has a text field, some checkboxes, a set of radio buttons and two text boxes.
What are the pluses and minuses of using GET over POST and vice versa. I always thought you should use GET for retrieving the form and POST for submitting, but I've just learnt you can do both. Does it really make a difference? Cheers.
<% form_tag({ :action => "create" }, :method => "get") do %>
GET requests are always added to the URL, where as POST is submitted with the body of the request. As you note both can be used to retrieve and send data, but there are some distinctions:
As GET is sent with the URL you are limited in size to the maximum length of the query string. This varies from browser to browser, but is usually at least around 2000 characters (on modern browsers). This usually makes it inappropriate for sending large text fields (eg email).
AS the GET command is exposed in the query string it can be easily modified by the user
As the GET command is in the query string it does make it easier for users to bookmark a specific page, assuming your page will work with some state variables stored.
POST is usually more appropriate for sending data, as it is suits the nature of a request, mostly because of the limitations of the above.
The HTML specifications technically define the difference between both as "GET" means that form data is to be encoded (by a browser) into a URL while the "POST" means that the form data is to appear within a message body.
But the usage recommendation would be that the "GET" method should be used when the form processing is "idempotent", and in those cases only. As a simplification, we might say that "GET" is basically for just getting (retrieving) data whereas "POST" may involve anything, like storing or updating data, or ordering a product, or sending E-mail.
Depends on if you're being semantic or not. Both GET and POST hold intrinsic meaning if you're making an HTML-based API. But in general, GET is used for fetching data, POST is used for submitting data.
The biggest difference is that GET puts all the data in the URL (which can be limited in size), while POST sends it as a data part of the HTTP request. If you allow data entry with GET requests, you're also making a lot of web exploits a lot easier, like CSRF. Someone can just make a pre-filled link to the vulnerable form's action (say, a password change form?), send it to unsuspecting users who click it and unknowingly change their password.
In addition, no browser will warn the user if they refresh a GET page that does data entry (which would make a duplicate entry, if you're not careful), but on a POST, most browsers will show a warning.
I think other answers covered the main stuff. Also I want to add this bit. Using GET for critical data such as sending password over a GET request will expose the password more than POST because it'll be stored in browser's history cache, proxy caches, server logs etc.