I have a script as below
document.getElementById('lan').innerHTML=lan;
document.getElementById('city').innerHTML=city;
document.getElementById('text1').value=city+'|'+lan;
The variables lan and city contain text, for example 'kalmar'.
What I want to do is to take the contents of these two variables and combine them and set that combined string to be a form field's value, as to be able to use the regular submit function of the form to save it to database.
In Chrome and FF it works perfectly, but not in IE (surprise).
If I do alert(document.getElementById('text1').value) to see what value it holds IE only prints
[object]
Any clues as to what has happened/what I can do to make it compatible?
It's a big document but I cut and paste the essentials here:
HTML-element to receive the final combined value
<input type='hidden' name='text1' id='text1' value=''>
HTML-element (link) to assign value to above HTML element:
<div id="searchResult">Kalmar i Kalmar<br></div>
function populateFields(lan,city)
{
document.getElementById('lan').innerHTML=lan;
document.getElementById('city').innerHTML=city;
document.getElementById('text1').setAttribute('value',city+'|'+lan)
document.getElementById('save_button').style.zIndex='auto';
alert('LAN: '+document.getElementById('lan').innerHTML);
alert('CITY: '+document.getElementById('city').innerHTML);
alert('TEXT1: '+document.getElementById('text1').value);
}
Also - the alert() checks now print the correct values (i.e. Kalmar|Kalmar) but the form still doesn't save teh value that I have set the text1 field to!
In IE you could use setAttribute('value',city+'|'+lan).
Hope it fits your needs.
So I discovered there were a number of issues here.
First, the function populate_fields() had local variables named the same as some html elements in the document. IE does not like that, hence it printed [object] when I tried to read the value stored in my variables (since there was already an html element/DOM object with the same name, I guess my function variables just never declared).
Once that was sorted out, I also realized that the form didn't save my value, though it seemed that the form item had received the correct value (I checked using alert).
Turns out that I had a nested form, I.e.
<form>
<form>
</form>
<input last inputfield of first form>
</form>
and that made IE totally disregard the last form field... for some reason none of the other browsers had a problem...
Thanks for the attention guys!
Related
Interestingly, some input elements of Blazor Forms don't have the data stored in HTML as value (attribute) of the input-field. The fields doesn't even have a value attribute!
When I inspect and use 'Store as global object' functionality in chrome and check the value of the element in console (temp1.value), I can see the value.
I'm wondering where this value is being stored in the browser.
The value attribute is not set by changing the DOM's .value property.
Consider the following minimal example:
<input id=time>
<script>setInterval("time.value = new Date()", 1000);</script>
<input type=button onclick=alert(time.value) value=read>
You can inspect the clock and see that there's never a value attribute, yet the input's value property can be both setted and getted by script.
Thus, the value of the form input in your question can come from almost anywhere. It's likely embedded deep inside the other library support code that makes it easy to shuttle data back and forth, but that's speculation on my part. It's a JS variable of some sort, that much we know. The main thing is that attributes are not needed when making heavy use of JS.
I know it is possible to embed form values into the URL as parameters if the form has an ID assigned to it. But what if it does not have an ID?
For example the "Search" field in this page:
http://au.autodesk.com/speaker-resource-center/call-for-proposals/voting
<input type="text" placeholder="Search " class="form-control ng-valid ng-dirty search-box" ng-model="search.$" ng-change="updateButtons()">
I know it is possible to embed form values into the URL as parameters if the form has an ID assigned to it.
That is not true.
Server-side (and occasionally client-side) code on a page may read the query string as a means to set default values for form controls (typically so that a form can be corrected and resubmitted if there were errors in the previous attempt).
In these cases, the name attributes will usually map onto the query string (because the form will generate the query string from the name attributes). Often an input will be given an id that is the same as its name.
It is entirely under the control of the site's authors.
There is no way to set values of inputs on another site without the other side providing a mechanism to allow you to do that.
There's a few different ways to do that. Looking at that HTML, it's the first text-type input inside the div, so the first method that comes to mind is this:
You could pull out the div (using the class "search-area") and then target the first text input box within that div. I don't know whether you're using jQuery or native JS or exactly what language/library/framework you're using.
JQuery would be something like:
var inputElement = $(".search-area")[0].first()
This SO answer may help:
jQuery: how to find first visible input/select/textarea excluding buttons?
Edited to add: Answer is targetting the input element. As the answer from someone else mentions.. You can't actually do what you're wanting to do with the URL.
Edited again. Misread the question. I'll leave this here in case someone else needs to know how to target an input field that doesn't have an ID. Alternatively, I have no problems if someone wants to delete this answer.
I have a field that shows a value 4 in the UI. The site is built using a complex build process that I do not totally understand (I work as part of a team).
When I inspect the HTML for the field, I don't see the value 4.
I am confused about how this might happen. Is it possible that javascript is "showing" the value of the input field?
DOM elements have attributes and properties. The two are not always identical. The web inspector, in general, shows attributes as part of the DOM structure, like.
<input type="text" value="4" />
However, if there is no value attribute, this does not mean that the element has no value. For example, consider the following HTML:
<input type="text" id="test" />
When you load the page, the attribute document.getElementById("test").getAttribute("value") is null, and the property document.getElementById("test").value is "" (empty string). When you enter 4 into the input field, the attribute "value" is still null, but the property value has changed to "4".
Long story short, the web inspector is not obligated to show the value of an input since it is does not always appear in the DOM as an attribute.
yes, you can change the value in javascript. and that is what is happening in your case
document.getElementById("materials_price_1").value = "4";
I am not sure what the issue is.
If the input contains a 4 that does not mean the attribute value will be equal to 4.
It just means that the value of the input is 4.
Just check value of this field with JavaScript:
document.getElementById('materials_price_1').value;
Or with jQuery:
$('#materials_price_1').val();
Yes, if you using chrome you can in inspect element stand with the mouse on the elemnet in 'Elements' tab and right click.
Now choose 'Inspect DOM Properties' this will open you bottom of the tab the console tab. there you can find the DOM object of your field. open the object and find property value. this is the active value right now
Sure. it happens in the DOM. you can simply make it blank by writing this code in your body tag :
<script>
document.getElementById('materials_price_1').value='';
</script>
just make sure you put the code after your other Javascript codes.
I have a included a Dojo star rating widget (dojox.form.Rating) in a Dojo form but when submitted, it doesn't appear.
<div dojoType="dojox.form.Rating" numStars="5" id="field_3177" value="3"></div>
The documentation doesn't mention adding a name attribute, but even if I add one, it doesn't help.
<div dojoType="dojox.form.Rating" name="field_3177" numStars="5" id="field_3177" value="3"></div>
Examining the rendered HTML in Firebug, it seems the hidden input field has no name attribute - which would explain why it doesn't appear in the POSTed data.
<input type="hidden" dojoattachpoint="focusNode" value="3" id="field_3177" tabindex="0">
Is there something I should do before submitting?
You just need to add a name to the widget, i.e.
<div dojoType="dojox.form.Rating" numStars="5" id="field_3177" name="field_3177" value="3"></div>
This is nothing special to Dojo. All input elements must have a name in order to be submitted back to the server, see http://www.w3schools.com/tags/att_input_name.asp.
UPDATE:
Sorry, didn't see that you'd already tried adding a name param. I'd argue this is a bug in either the Form or (more likely) the rating widget. If you submit your form via XHR using dijit.form.Form.getValues() then you'll get the rating widget included - if you have a name. But if you use the native form submit then you don't.
I've created a test case at hhttp://telliott.net/dojoExamples/dojo-ratingInFormExample.html. You can get this to work for non-XHR form submission by quickly iterating through the values returned by getValues() and building the query string yourself. Not ideal. I suspect the template for the rating should be updated to put the name attribute onto the input node rather than the top level node.
Silly question:
have you added dojo.require("dojox.form.Rating"); to your code?
Hope it helps you.
//Daniel
I'm using jQuery to iterate through an HTML table, and dynamically fill in the row numbers of each row (by populating the row number in a text box):
function updateRowNums() {
$('#myTable').find('tr').each(function(index) {
$(this).find('input[id$="_rowOrder"]').val(index);
});
}
This function gets called under:
$(document).ready(function() {
// .. code truncated ... //
updateRowNums();
});
This works perfectly fine under Firefox. However, under Chrome (tried both 5.x and 9.x (beta)) and sometimes Safari, this ends up populating a bunch of other fields that don't even match the:
'input[id$="_rowOrder"]'
criteria, with the row numbers. So basically it scatters the numbers around in other, unrelated, text fields...
I'm pretty sure this is some sort of Chrome or jQuery bug, but I'm just checking, since it seems like pretty basic functionality. BTW, if I introduce an alert in the code, it then works fine on Chrome, so this may have something to do with the timing of the document loading in Chrome:
function updateRowNums() {
$('#myTable').find('tr').each(function(index) {
alert("XXXXXXXXXXXXXXXXXXX");
$(this).find('input[id$="_rowOrder"]').val(index);
});
}
Go here to see example:
http://jsfiddle.net/eGutT/6/
In this example, the steps you need to reproduce are:
Go to URL using Chrome (or Safari -- sometimes fails as well).
You will notice that everything works as expected so far (i.e. numbers filled down 1st column)
Click on the "NAVIGATE AWAY" link.
Click back
You will see numbers filled in across top row AND down first column
You will notice that I added console logging, to output the ID's of the elements that are getting their value modified. The output of this log is:
one_rowOrder
two_rowOrder
three_rowOrder
which indicates that only 3 elements were touched. However, from the result, you can see that 5 elements have numbers in them.
Thanks,
Galen
The problem is that your input's do not have a name attribute. Chrome/Safari seems to try to save what you entered in to form fields when you go forward and back in the history. Because your inputs do not have name attributes its guessing which input field to put the values back in, and is guessing incorrectly.
Add name attributes to your fields and its all fixed: http://jsfiddle.net/petersendidit/eGutT/14/
Chrome/Safari probably should be checking for the id attribute of the name attribute is missing.
If you are using digits as your IDs, jQuery won't recognize them and/or act correctly because it is invalid HTML. Either remove the digits or put a letter in front of them.