In the server side we fetch the form parameters by the form element name. Similarly how to fetch the form parameters in case the input element does not have the name attribute and has the id attribute?
I don't think that is possible. Unless an input element has name attribute it won't even be submitted in the GET/POST request while submitting the form.
So, my understanding is, to read value for any input field in html (on server side) we need to have name attribute defined on it.
Going through w3c specs at HTML specification, it says that the first step that happens during form submissions is Step one: Identify the successful controls. And successful control is the one that has Control name defined on that field. i.e, the name attribute .
Related
I searched around on the site before posting so I hope this isn't a duplicate, but this has been a question that has been bothering me.
Why doesn't HTML allow nested forms (without JS)? I have seen that it doesn't allow nested forms, but never why they are not allowed. To me, it doesn't make sense why they aren't allowed, especially if each form routes to two different actions. Why is this?
HTML doesn't all nested forms because they would cause more problems than they solve.
Forms in HTML are built for single HTTP requests. If you submit a parent form, should you submit the child form as fields in the parent form to the parent action? Or should the child fields be submitted to the child action as well? How do you handle the responses to both of these requests? Which response do you render? What if the parent submit fails and the child succeeds? How do you handle this in the response markup?
Any of these answers are handled in script rather than markup.
If the fields are required in the parent form, that should be part of its form as a single encapsulated way to represent the data needed for a single request. Any nested form is its own request and should be encapsulated as such.
The reasoning behind this is because the <form> tag expects an event action to be specified and having one form within another form would only cause problems because each form is expecting a different event to occur which could cause unexpected results with submit buttons because their default event to fire is whatever event has been specified in your form action.
The being said, you can have multiple <form> tags on a page, just not nested.
EDIT
You can also read the W3C documentation on the form element here: https://www.w3.org/MarkUp/html3/forms.html
One of the first thing it says is: **
Note you are not allowed to nest FORM elements!
**
I can understand why it seems like this might work...
Think about HTML code in general; you open a <tag> and close the </tag>. Most of the tags can contain multiple other tags, right? The header tag holds tags for the <title>, <meta data>, etc., and the <body> tag wraps a whole bunch of stuff together before you see the </body> tag. Some tags have different rules; like the <img> tag which stands alone. The <form> tag falls into one of those tags with "different rules".
A <form> is actually part of a script. It is presented on the HTML page to your site visitors as a means of gathering information. Once the site visitor clicks on the submit button, the <form> sends the information to it's related script to be processed. All of the <form> tags, whether they are <input> values, <checkboxes>, or <password> fields, are bundled between the opening and closing </form> tags.
Every <form></form> sends information to a seperate script. So, a script that logs the user in would need one <form></form> and a script that allows the user to change his password would be another <form></form>. If you want the script to handle both options, then you would have to code your script to process all of those bits of information.
In summary, a <form></form>cannot be nested because they function as a User Interface to gather information that will be processed by a script stored on your websites' server.
I have several inputs (file) in my html form. Is there any way on my servlet when the form is submitted that I can get the name attribute of the file tag? I'm asking because the form has 2 different sections for uploading forms, and I need to put the forms into 2 different categories when I process them in the Servlet, and I'm hoping to use the input name prefix to tell what section of the form the file came from. I have prefixes on the input 'name' attributes, but I'm not sure how I can get that on the servlet.
I know with a traditional form, with say an input of type text, I can say: request.getParameter("myInputName") and get the object, but I'm not sure how to handle this with file inputs.
I am currently trying to understand the jsp codes of another guy but I am having trouble with the following codes:
if( request.getParameter("username")!=null &&
!request.getParameter("username").equals(""))
The username is the field a user fills on an HTML form. The codes after these codes saves the data the user fills in into strings which will be later used for other purposes.
My question is what is the purpose of the !request.getParameter("username").equals("") code part in the above?
Has request.getParameter("username")!=null part of the code not already tested whether the user enters information into the input field of the HTML form or not?
Regards
If you reveive a request like
http://.../yourservlet
then the parameter value will be null, since no parameter named username is passed at all.
If you reveive a request like
http://.../yourservlet?username=
then the parameter value will be the empty string, since the parameter is passed, but its value is the empty string.
What you'll receive depends on the HTML, and on what the user actually does (he could type the URL manually in the address bar, for example). The code makes sure both cases are handled in the same way. Let's imagine some JavaScript in the page disabled the input field or removes it from the DOM when some checkbox is checked. In that case, the parameter won't be sent at all.
Has request.getParameter("username")!=null part of the code not already tested whether the user enters information into the input field of the HTML form or not?
No. A text input in a HTML form will always send a value. If nothing has been typed into it, then that value will be "".
I have a VBScript that goes over an HTML form, fills it with fixed values and then submit it. It works fine so far, but now i need to set the location of a file that is going to be uploaded within the form data.
I believed if I set the location on the value it was going to work, but it doesn't.
<input type='file' name="file_field" value='file_location'/>
Also, I found this while researching. It says...
input type=file
Value: Sets or retrieves the displayed value for the control object. This value is returned to the server when the control object is submitted.
Is there a way (by code) to fill that input, even with jQuery?
No. This is not possible.
Browsers block against setting the value attribute on input of file type for security reasons so that you can't upload a file without the user's selected any file himself.
I've noticed a lot of websites with form(s) containing input fields whose "name" attribute is specified even if it isn't used for styling or scripting purpose!
Moreover, according to the official document about the form in HTML document ...
name = cdata [CI] This attribute names
the element so that it may be referred
to from style sheets or scripts. Note.
This attribute has been included for
backwards compatibility. Applications
should use the id attribute to
identify elements.
So, my question is: should this attribute used only for styling and scripting purposes?
Thanks in advance!
EDIT: In particular, could be avoided the use of this attribute with input fields of "text" type (when there aren't no styling or scripting purposes)?
EDIT 2: So, you have almost confirmed what I had thought about: the "name" attribute will be deprecated in further HTML specifications/standards!!!??? It is still "alive" only for backwards compatibility ... in some cases can be avoided but there are still some cases (such as the radio button) where it is necessary!
I think you'll find almost every site will have inputs with the name attribute. I don't see it going away anytime soon.
The name attribute specifies a name
for an input element.
The name attribute is used to identify
form data after it has been submitted
to the server, or to reference form
data using JavaScript on the client
side.
Note: Only form elements with a name
attribute will have their values
passed when submitting a form.
source
The name attribute is the notation to reference specific elements within the scope of a webpage through non-DOM Javascript:
document.forms['your_form'].elements['aa']
The id attribute for the element needs to be set with the same value for the following to work:
document.getElementById('aa')
My understanding is that when Netscape created Javascript, it used the name attribute. The HTML spec however decided to go with id, but kept name for backwards compatibility. IME, using the name attribute was required for Internet Explorer 6 support because the javascript engine in IE wouldn't read the id attribute - only the name though both were defined.
...could be avoided the use of this attribute with input fields of "text" type (when there aren't no styling or scripting purposes)?
If you don't have any javascript attached to the text fields, yes - they would be unnecessary.
There are differences between id and name attributes. An id is applicable to any element in the HTML document while a name is relevant for input fields only. An id is required by standard to be unique in a page (though not necessarily followed in all web pages). Different elements may have same name though. One particular case comes into mind is the radio button. All radio buttons should have the same name and the value of the one selected would be given back to the form. So you can see that name still has significance in HTML form processing.
I have seen in automatic HTML form generation systems (like zope.formlib), that id and name attributes both are automatically generated for different types of input widgets. Such automatic form generation systems take proper care of all the nuances associated with differences in id and name attributes. They also do things like generating a hidden input element for each checkbox element. So wherever possible, I try to use some sort of automatic HTML form generation mechanism and let it take care of the issues involved.
This is an old question, but it's worth noting that many modern JS frameworks rely on the name attribute. In particular, jQuery's serialize function:
For a form element's value to be included in the serialized string, the element must have a name attribute.
If anything, name seems to be making a comeback.
It's also worth noting that the name attribute is useful because it has slightly more "scope" than id. id must be unique within a page, but the same name can be used multiple times. This makes it useful when you have multiple forms on the same page, or when you want to reference a group of checkboxes, etc.
IIRC older browsers use name in place of ID, that's why it's normally included.
Your reference to HTML 4 is way out of date. Here's WHATWG's discussion of name - https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#naming-form-controls:-the-name-attribute
name should not be used for scripting or styling. That is what id is for as you have said.
But name is not obsolete and I see no prospect that it might be removed from HTML. Its purpose is specifically to submit data to a server.
id should be unique for your HTML document to be well formed. name might not be. You might have a set of three radio buttons, let's say "Small", "Medium" and "Large". You could give them three unique values for their id attributes, so if your user interacts with other elements you could change the selected radio button in script. But when the form is submitted, you want only one value to be submitted, so you give all three radio buttons the name value for name.
<input type="radio" id="size-small" name="size">Small</input>
<input type="radio" id="size-medium" name="size">Medium</input>
<input type="radio" id="size-large" name="size">Large</input>