Hello,

I hope someone has the time to help me.

I have a form that lists a variable price in
<input type=hidden name=price value=1>

I have a drop down box letting the user choose a quantity in
<select name=quantity>
<option value=1>1</option>
<option value=2>2</option>
etc...

I have a html form input field that I want to show the price in
<input type=text name=total_price>

How do I hook all this up so that the "total_price" field will display the variable price and multiply it by the quantity option to give a total numerical figure of cost?

Thanks,

KD

If the price is a price that changes daily (such as gasoline) and is stored on your server, JavaScript can't do the job. You need a server-side script.

If the price varies with the quantity ordered, then you need a script that reads the quantity, looks the price up in an array (indexed by the quantity ordered) and then display it in a text box.

I have the PHP doing its job. It's setting the
<input type=hidden name=price value=1>
or whatever the price may be.

I need to know what the javascript code is to make the box
<input type=text name=total_price>
to show the "price" * "quantity"

Anyone knock this up in javascript in 2 seconds for me?

You need to put quote marks around the attributes "text" and "total_price".

You need to read the two values for price and quantity. Then you need to find the product. Finally, you must put the answer into the form:

var price, quantity;

price = document.forms.nameOfForm.total_price.value;
quantity = document.forms.nameOfForm.quan_ordered.value;
revenue = price * quantity;
document.forms.nameOfForm.part_revenue.value = revenue;

>price = document.forms.nameOfForm.total_price.value;
Incorrect way of accessing form elements. Each form object has an 'elements' host object which has all the form elements as it's properties. Correct way would be: price = document.forms['nameOfForm'].elements['total_price'].value;

That syntax is necessary only if you are accessing the form using element numbers, variables containing the form or element names, or getElementByName.

None of my books on JavaScript show it for an element address not using variables. That is only one of many valid ways to address an element.

And it definitely does NOT work for addressing radio buttons, where you have to have an address of the syntax:

document.forms.myform.rabutton.checked

Is the W3C now deprecating JavaScript usage too?

> That syntax is necessary only if you are accessing the form using element numbers
Take a closer look at what I had posted. The fields or elements of a form should be accessed using the 'elements' nodelist or host object called HTMLCollection. Just because what you posted works now doesn't mean it always will.

> None of my books on JavaScript show it for an element address not using variables.
There are some things which you won't find in books. And anyways of the majority of books out there, only handful of them are worth reading.

> And it definitely does NOT work for addressing radio buttons
It certainly does. Please get your facts correct before putting a *NOT* there.

>Is the W3C now deprecating JavaScript usage too?
No, but you sure are using it the wrong way.

How are we supposed to know this "correct" way of doing things if most of the sources have not published it? Clairvoyance?

What is your source for this requirement of using the 'elements' nodelist? All of my sources say that it is becoming the obsolete way of addressing elements.

Are we talking about the necessity of including the "elements" name in the description?

Or are we talking about different syntax? These are equivalent, unless you want the program to be able to change parts of the descriptor (which requires the third case):

document.forms.nameOfForm.part_revenue.value = revenue;

document.forms.elements.value = revenue;

a = 'nameOfForm'; b = 'part_revenue'; document.forms[a].elements.value = revenue;

What is the "correct" syntax for using a radio button? Is it addressed as an array of arrays? I said it doesn't work, because I can't get it to work. If I try to address the element as a subscript, than I can't seem to address its own subscript.

> How are we supposed to know this "correct" way of doing things if most of the sources
> have not published it?
It's a real pity there are a lot of substandard tutorials / books out there to misguide beginners. Good sources are hard to find if one doesn't know what he is looking for.

> What is your source for this requirement of using the 'elements' nodelist?
DOM specification drafted by W3C.

> All of my sources say that it is becoming the obsolete way of addressing elements.
You are in bad company.

> What is the "correct" syntax for using a radio button?
Read this thoroughly for form access related queries. Then this.

OK, the pages you gave me even show the syntax I used as an alternative. I think you are interpreting them in a stricter sense than is required.

But they are also using deprecated forms in their pages, so they are not current. The name attribute is now deprecated in the form tag. The only place it works and validates is in the radio button. (I must use XHTML.)

And I see the difference between what I tried to use for radio buttons and what works. I was trying:

buton[i] = document.forms['namForm'].elements['buttonset[i]'].checked;

It should be:

buton[i] = document.forms['namForm'].elements['buttonset'].[i].checked;

But the following ARE completely interchangeable, according to those pages. One is not better than the other, unless dynamic addressing is needed:

document.forms.nameOfForm.part_revenue.value = revenue;

document.forms['nameOfForm'].elements['part_revenue'].value = revenue;

a = 'nameOfForm'; b = 'part_revenue'; document.forms[a].elements[b].value = revenue;

The reason to use the first version is to keep the files short. Some ISPs (including mine) charge more for longer downloads. Keeping the files short allows more downloads per hour with the cheaper plan.

> The name attribute is now deprecated in the form tag.
'name' attribute is deprecated anywhere outside the 'form' tag. With the name attribute deprecated, how do you propose on accessing the form data server side?

>I must use XHTML.
It's interesting you would want to use something not supported by IE6 and IE7.

Use id instead of name. I already asked the W3C this question.

The only use of name not deprecated is the grouping of radio buttons.

The choice to use XHTML is not mine to make.

IE7 supports it fairly well. There are only a few places where it doesn't work as defined, and IE7 mangles HTML the same way.

commented: Dumbass.. -2

You certainly don't know what you are talking about.

> Use id instead of name.
OK, a bit of refresher. Form values are normally submitted using two methods: GET and POST. In GET, the form data is appended to the URL while in POST, the form data forms a part of the request payload. Despite all these differences, it is a fact that the form data is submitted in the form of 'name / value' pairs and not 'id / value' pairs.

Try this code:

<!-- nameOfThisFile.html -->

<!DOCTYPE html 
     PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>    
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <title>OK</title>
</head>
<body id="bodyMain">
    <form action="nameOfThisFile.html" method="GET">
        <div>
        <input type="text" id="txtId" value="OK" />
        <input type="text" name="txtName" value="txtName" />
        <input type="submit" value="Submit" />
        </div>
    </form>    
</body>
</html>

After pressing the submit button, take a look at the URL. Only the form field with the name attribute defined gets submitted.

Plus in case you were wondering, the document is a fully compliant XHTML strict document, which just proves my point that 'name' attribute is NOT deprecated inside form tag for form elements.

> I already asked the W3C this question.
...and misinterpreted their reply.

> The choice to use XHTML is not mine to make.
Wrong. The choice of DOCTYPE to be used definitely lies with the developer developing the web application.

> IE7 supports it fairly well.
"Fairly well" doesn't cut in. And what about IE6. Do you have idea how many people out there still use IE6?

Are you sure you are not trying to misguide the people here? I thought you had already "got the solution from a helpful guy at W3C" according to this thread...

You should use 'name' for forms because that has universal support by browsers.

But name is deprecated in XHTML. It won't even work, and the code won't validate. That support will be gone.

Read this portion of a page by W3C:

http://www.w3.org/TR/xhtml1/#h-4.10

> But name is deprecated in XHTML. It won't even work, and the code won't validate.
The code I posted is valid XHTML.

> Read this portion of a page by W3C:
We don't need to read something we have well understood.

HTML 4 defined the name attribute for the elements a, applet, form, frame, iframe, img, and map. HTML 4 also introduced the id attribute. Both of these attributes are designed to be used as fragment identifiers.
[....]
Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will be removed in a subsequent version of XHTML.

Anyways, I have had enough of trying to squeeze this simple concept in that brain of yours. If you still disagree with what we have posted, best of luck.

Then tell me why it is that, when I put name attributes into form tags, it returns that there is no such attribute in form tags when I try to validate it in the XHTML 1.0 Strict doctype?

I emailed W3C about it, and they told me the name attribute is deprecated in form tags, but that, until recently, the validator was erroneously not catching it.

I am going to take their word above yours.

form != input..

name is XHTML deprecated as an attribute of the form element, that is <form...>. It's not deprecated on any of the form fields. The validator can't be wrong, it's fed the DTD/schema and it validates the input page; the schema/DTD can't be wrong; because they ARE XHTML 1.0. If the validator program itself was wrong... meh.. it's not.

I guess what people are trying to say is that name is not deprecated on the 'tags that make up forms'. which is a little ambiguous I'll admit.. but, read the posts, look at the context of examples.. name continues to be a valid attribute of input, select, submit and other form fields, and it is indeed needed for those fields to be submitted when the form is.

I agree with that.

Hey there hot heads :-)

how the hell did we get on to the subject of radio boxes?

And eh, which of the above codes should I use to calculate the "total price"?

Thanks!

Kev

You sure are quick on the uptake. :icon_rolleyes:

I've no knowledge of javascript at all never in my life. I really should learn but don't really have the time but need this functionality.

If I don't get an answer then I will learn, but would really rather not dedicate the resources to right now :-)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.