I initially set out to learn how to handle "ajax-ready file uploads"; I found, and comprehend, one of the main concepts: it's not possible as ajax, but you can submit a form with the target set to a hidden iFrame's id [1]. That seems to be generally accepted by the community and compatible with all browsers. Is that an accurate assessment?
My question is: what are the pitfalls to this approach? Because if there are none, it seems to me that every "ajax-ready post" could be done in this same fashion. Remove the file upload component and this approach versus, say, a jQuery.post() approach appear to have identical outcomes.
In all the questions and resources I've researched, I've only been able to find "solutions" for handling my initial issue. I've been unable to find any sort of "pro v. con list" or "pitfalls to this approach" anywhere regarding a form targeting an iFrame; if you know of one, please feel free to share it!
[1] HTML Example:
<form method="post" target="take_the_reload">
...
</form>
<iframe class="hide_me" id="take_the_reload" name="take_the_reload"></iframe>
Much obliged,
Beez
References: Just a couple of the resources I've used:
http://www.joshclarkson.net/blog/file-uploads-in-a-hidden-iframe-using-jquery/
Firefox form targetting an iframe is opening new tab
http://terminalapp.net/submitting-a-form-with-target-set-to-a-script-generated-iframe-on-ie/
javascript: submit form in an iframe...help
http://www.openjs.com/articles/ajax/ajax_file_upload/
When I first started AJAX (before jQuery and Prototype came along) I used to do exactly that with all my forms....just post them to a hidden Iframe. It was easy and painless.
The drawbacks of form-post:
It's not really "pure" AJAX (file uploads aside). I'm sure all the DOM manipulation in the iframe for the result is slower than just getting back a response via XHR.
The error handling is more difficult - you have to look at what the server puts in the Iframe as a result
Things are moving towards JSON-based data handling which forms alone don't do
Sometimes you want to do something "in the middle" between the form and the server such as some field mapping or including other client-side data
Related
I have 3 web pages each page contains 1 bootstrap form. The forms are structured the same, but each has a different number of input fields and order in which they appear in the form.
The HTML page files, local JS files are all in the same folder(no sub-folders). The <head> on each page has the same assests.
The non-functional form has a text area and button that the other forms do not. I have tried commenting these out, but that didn't resolve the problem. I have tried removing the link to local CSS, that too made no difference in the issue.
When I check the html files with W3 validator I get one Error and 2 Warnings.
Error: Element legend not allowed as child of element form in this context.
Warning: The date input type is not supported in all browsers. Please be sure to test, and consider using a polyfill. Commenting out the legend makes no difference.
I do have a date field in both the working and non-working forms.
When I look at dev tools in Chrome I don't see any errors.
I have tested on both Chrome and FireFox, so I don't think it is a browser specific issue.
Note this is all done on local machine and all coded using notepadd++.
I know this would be a tremendous amount of code to post for review, but if required I will do so. I was hoping someone would have troubleshooting suggestion.
have created 2 jsbin. first link is page with non working form. Second link is page with working form. first link is https://jsbin.com/xuwuziy/edit?html,css,js,output . Second link is https://jsbin.com/luqatel/edit?html,css,js,output
In the first JSBin: $('#cruise1').bootstrapValidator(.... There's no element with id "cruise1" in the page. Instead your form's ID is "quoteForm". Therefore the validator does not bind to it because it can't find an element with the "cruise1" ID.
Since you're including the same validation JS on both pages, in order to get the same code to validate both forms, you have to use a selector that can match to both forms.
There are two possible, simple solutions.
1) Give both forms an id of "cruise1". However, this may not be very descriptive of your quote form.
2) Give both forms the same class, and use that as the selector to initialise the validator. e.g.:
The form tags:
<form class="form-horizontal validatableForm" id="quoteform">
and
<form class="form-horizontal validatableForm" id="cruise1">
And the validator intialisation:
$('.validatableForm').bootstrapValidator( //...etc
This will initialise the same validation on all forms which match the given selector (i.e. all forms with that class). In any one page, in your situation, you might only have one form loaded with that class, but it means it will work when the code is included in both pages, and if for any reason you had two forms with that class loaded in one page it would bind those as well.
One last note, since you mentioned you were new to this: I hope you are implementing the same validation rules in your server side code (the code which deals with the submitted form data). Client-side validation such as you've used is very nice for user experience, but it's not secure - any user, especially a malicious one, or an automated spam-bot, can easily manipulate or bypass the JavaScript validation (most simply, by just turning off JavaScript) and try to send invalid or problematic data to the server. You cannot trust anything which comes from the client-side and must re-validate everything in order to protect your application and database.
I am volunteering on a website-based project that is trying to make all pages fully operable JavaScript free before adding any JavaScript for enhancements, and I was asked to investigate whether or not a particular scenario could be handled purely through HTML/CSS.
What we have is a form that is populated to help us filter a list of tickets that are displayed on the screen after a page update through a GET action, which itself works fine, but the concern with the current implementation is that the URL cannot be made into a permanent link. The request, however, to keep the permanent link as minimal as possible, is to only send GET parameters for fields that are populated with something (so, suppressing GET parameters for fields that are blank) instead of having a different GET parameter for each form field on the page.
I have thought of several ways that could be done, most including JavaScript (example: create fields with ids but no names and a hidden field w/ name that uses JS to grab the data from the fields), but also one that would be a POST action with a redirect back to the GET with a human readable string that could be permanently used. The lead dev, however would prefer not to go through the POST/redirect method if at all possible.
That being said, I'm trying to make sure I cover all my bases and ask experts their thoughts on this before I strongly push for the POST/redirect solution: Is there a way using only HTML & CSS to directly suppress GET parameters of a form for fields that are blank without using a POST/redirect?
No, suppressing fields from being submitted in an HTML form with method of "GET" is not possible without using JavaScript, or instead submitting the form with a POST method and using a server side function to minimize the form.
What fields are submitted are defined by the HTML specification and HTML and CSS alone cannot modify this behavior and still have the browser be compliant with the standards.
No, you cannot programmatically suppress any default browser behavior without using some kind of client scripting language, like JavaScript.
As a side note, you say "JavaScript for enhancements", but JavaScript is not used for enhancements these days. And no one in the real world would except a decent front-end without the use of JavaScript. I would suggest you simply use JavaScript.
I do not think you can avoid Javascript here to pre process before submission to eliminate unchanged /empty form fields.
I was looking at the code in my Blogger template for the threaded comments because I wanted to find out how the <div> is a direct descendant of the <ol>? I don't think that is supposed to be so(Correct me if I'm wrong and cheer me on if I am right. I'm new to this).
Here is the thing,
I see the threaded comments are using <script type="text/javascript">, so I disabled JavaScript in my browser(Chrome), went back to a Blogger blog with a page with threaded comments and they were threaded.
The JSON stuff is in the same <script> to make the threaded look, which got me confused.
Does that mean that JSON is read and works even though JavaScript is disabled or is it something else?
No, when viewing source you will see that the comments get delivered both as inline json data and usual html. So the script (when active) doesn't need to retrieve the data from the dom to build its model structure.
Is there some secret and mystical way to change the value of my HTTP-request's referer, or at the very least, keep it from showing? Also, using a MitM page from another domain would not solve my issue, as you are now just submitting that other page's value.
This is not browser specific, I would need to do this on the HTML level.
The problem I am facing is a silent-login page where it sends an HTTP-Redirect to the http-Referrer, unless it is the same domain, or empty.
You can not control this on an html level. Your only option is to modify the login code to not issue the redirect or to direct it to the desired page.
It's an old question, but I know how you can do this. The first way is not guaranteed across all browsers, but you can use rel=noreferrer. AFAIK GC is the only UA to currently support this but it is in the standard. FX may also, IDK.
The second way is far more reliable, and it involves a cool little hack someone shared with me on IRC:
Basically, construct an iframe from a base64-encoded data: URI. The framed document is to have a script that listens for a window.postMessage() and when it gets fed the command with a URL to visit, it executes window.top.location = msg.data.URI or however it is that one reads the message. Sorry I can't recall, I haven't slept for a few days.
Enjoy if you still care.. :)
I read some AJAX-Form tutorial like this. The tag form is used in HTML code. However, I believed that it is not necessary. Since we send HTTP request through XmlHttpRequest, the sent data can be anything, not necessary input in form.
So, is there any reason to have form tag in HTML for AJAX application?
Apart from progressive enhancement as already discussed (don't make your site require JavaScript until it really has to), a <form> with onsubmit would be necessary to reliably catch an Enter keypress submission.
(Sure, you can try trapping keypresses on separate form fields, but it's fiddly, fragile and will never 100% reproduce the browser's native behaviour over what constitutes a form submission.)
Sometimes, web apps using ajax to transform their data either use forms as a fallback when the user has no JavaScript enabled (a sometimes expensive but very good thing to do).
Otherwise, if an application builds and sends an AJAX request, there is no compelling reason to use a form except in rare special cases when you actually need a form element. Off the top of my head:
when using jQuery's form serialize function
when monitoring all fields in a form for changes
when there is need to make use of the reset form button (that to my knowledge is available in a proper <form> only).
I see at least two possible reasons :
Graceful degradation (see also Unobtrusive JavaScript) : if a user doesn't have Javascript enabled in his browser, your website should still work, with plain-old HTML.
Behavior of the browser : users know what forms look like and how they behave (auto-completion, error-correction, ...) ; it's best not going too far away from that
And I would add that, if you want the user to input some data, that's why <form> and <input> tags exist ;-)
Using the right tags also helps users -- as an example, think about blind users who are navigating with some specific software : those software will probably have a specific behavior for forms an input fields.
It really depends what you're doing. If you're wanting to take form content submitted by the user and use AJAX to send that somewhere then you're going to want to use the form tag so your user can enter their data somewhere.
There will be other times when you're not sending data from a form and in that case, you wont have a form to be concerned about :)