469,270 Members | 1,117 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,270 developers. It's quick & easy.

Problems with ASP.Net object and Javascript

I have a function:

function SalaryDisplay(me)
{
var salaryMinLabel = document.getElementById("SalaryMin");
salaryMinLabel.value = 200;
alert("after setting salaryMinLabel = " + salaryMinLabel.value);
}

I also have an asp.net object:

<asp:label id="SalaryMin" runat="server" />

Which renders into:

<span id="SalaryMin"></span>

The function seems to find the span fine. The alert box shows that it is
set to 200. But the web page never shows it.

Is there a problem setting the span element?

Thanks,

Tom
Jul 23 '05 #1
54 4043

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Ow******************@newssvr21.news.prodigy.c om...
I have a function:

function SalaryDisplay(me)
{
var salaryMinLabel = document.getElementById("SalaryMin");
salaryMinLabel.value = 200;
alert("after setting salaryMinLabel = " + salaryMinLabel.value);
}

I also have an asp.net object:

<asp:label id="SalaryMin" runat="server" />

Which renders into:

<span id="SalaryMin"></span>

The function seems to find the span fine. The alert box shows that it is
set to 200. But the web page never shows it.

Is there a problem setting the span element?
I just change the object to an asp:textbox which renders into an input field
on the screen and this works fine.

In asp, you use a label object to display (and change) text on the screen
that is not part of an input type of field.

Is there a way to do this in Javascript/html?

I just want to be able to display the results of some calculations on a
field that the user inputs as just a label.

Thanks,

Tom
Thanks,

Tom

Jul 23 '05 #2
tshad wrote:
var salaryMinLabel = document.getElementById("SalaryMin");
salaryMinLabel.value = 200; <span id="SalaryMin"></span> Is there a problem setting the span element?


Span elements don't have values. You need to create a new text node then
append it to the element to add text to it. Look at the JavaScript section
of the DOM 1 specification. http://w3.org/DOM/

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Jul 23 '05 #3
I tried to do the same thing with the <lable> label item and had the same
problem. It shows that the value was changed, but it didn't seem to do
anything on the screen:

Yearly Compensation:<input name="SalaryMin" type="text" id="SalaryMin"
/>&nbsp;/&nbsp;
<span id="SalaryMax"></span>
<Label id="SalaryMin2" for="SalaryMin">This is a test</Label> />

The javascript code:

function SalaryDisplay(me)
{
alert("this.value = " + me.value);
var salaryMinLabel = document.getElementById("SalaryMin2");
salaryMinLabel.innerText = 200;
alert("after setting salaryMinLabel = " + salaryMinLabel.value);
}

This doesn't seem to work. I tried to do it directly
(SalaryMin2.innerText=200), but that didn't work either.

Tom

"tshad" <ts**********@ftsolutions.com> wrote in message
news:VB******************@newssvr21.news.prodigy.c om...

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Ow******************@newssvr21.news.prodigy.c om...
I have a function:

function SalaryDisplay(me)
{
var salaryMinLabel = document.getElementById("SalaryMin");
salaryMinLabel.value = 200;
alert("after setting salaryMinLabel = " + salaryMinLabel.value);
}

I also have an asp.net object:

<asp:label id="SalaryMin" runat="server" />

Which renders into:

<span id="SalaryMin"></span>

The function seems to find the span fine. The alert box shows that it is
set to 200. But the web page never shows it.

Is there a problem setting the span element?


I just change the object to an asp:textbox which renders into an input
field on the screen and this works fine.

In asp, you use a label object to display (and change) text on the screen
that is not part of an input type of field.

Is there a way to do this in Javascript/html?

I just want to be able to display the results of some calculations on a
field that the user inputs as just a label.

Thanks,

Tom

Thanks,

Tom


Jul 23 '05 #4

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Ow******************@newssvr21.news.prodigy.c om...
Is there a problem setting the span element?


A 'value' property on span does not display. The newly-created span element
is empty and needs to have a text node appended.

var salaryMinLabel = document.getElementById("SalaryMin");
var sMLText = document.createTextNode("200")
salaryMinLabel.appendChild(sMLText);
alert("after setting salaryMinLabel = " +
salaryMinLabel.firstChild.nodeValue);

nf

Jul 23 '05 #5
"nutso fasst" <no********@no.where> wrote in message
news:db******************@newssvr21.news.prodigy.c om...

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Ow******************@newssvr21.news.prodigy.c om...
Is there a problem setting the span element?


A 'value' property on span does not display. The newly-created span
element
is empty and needs to have a text node appended.

var salaryMinLabel = document.getElementById("SalaryMin");
var sMLText = document.createTextNode("200")
salaryMinLabel.appendChild(sMLText);
alert("after setting salaryMinLabel = " +
salaryMinLabel.firstChild.nodeValue);


Works great.

Is there a way to create the child node at the beginning somehow?

The problem is that as I call this routine It creates another node each
time. I assume the next time I do the document.getElementById("SalaryMin")
the child node will still be there (since it was appended to the next time I
did it).

I am confused as to why or how it is working.

The 200 is showing on the screen, but when I do a viewsource, it isn't there
and doesn't seem to be anywhere on the page.

Here is the script from the viewsource of the page:

<script language="javascript1.4">
function SalaryDisplay(me)
{
alert("this.value = " + me.value);
var salaryMinLabel = document.getElementById("SalaryMin");
var sMLText = document.createTextNode("200")
salaryMinLabel.appendChild(sMLText);
SalaryMin2.innerText = 200;
alert("after setting salaryMinLabel = " +
salaryMinLabel.firstChild.nodeValue);
}
</script>

Here is the html of the label (span):

&nbsp;&nbsp;Yearly Compens:<span id="SalaryMin"></span>&nbsp;/&nbsp;
<span id="SalaryMax"></span>

As you can see there is no 200 there.

Thanks,

Tom
Jul 23 '05 #6

"tshad" <ts**********@ftsolutions.com> wrote in message
news:HH**************@newssvr14.news.prodigy.com.. .
"nutso fasst" <no********@no.where> wrote in message
news:db******************@newssvr21.news.prodigy.c om...

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Ow******************@newssvr21.news.prodigy.c om...
Is there a problem setting the span element?
A 'value' property on span does not display. The newly-created span
element
is empty and needs to have a text node appended.

var salaryMinLabel = document.getElementById("SalaryMin");
var sMLText = document.createTextNode("200")
salaryMinLabel.appendChild(sMLText);
alert("after setting salaryMinLabel = " +
salaryMinLabel.firstChild.nodeValue);


Works great.

Is there a way to create the child node at the beginning somehow?

The problem is that as I call this routine It creates another node each
time. I assume the next time I do the
document.getElementById("SalaryMin") the child node will still be there
(since it was appended to the next time I did it).

I am confused as to why or how it is working.

The 200 is showing on the screen, but when I do a viewsource, it isn't
there and doesn't seem to be anywhere on the page.

Here is the script from the viewsource of the page:

<script language="javascript1.4">
function SalaryDisplay(me)
{
alert("this.value = " + me.value);
var salaryMinLabel = document.getElementById("SalaryMin");
var sMLText = document.createTextNode("200")
salaryMinLabel.appendChild(sMLText);
SalaryMin2.innerText = 200;
alert("after setting salaryMinLabel = " +
salaryMinLabel.firstChild.nodeValue);
}
</script>

Here is the html of the label (span):

&nbsp;&nbsp;Yearly Compens:<span id="SalaryMin"></span>&nbsp;/&nbsp;
<span id="SalaryMax"></span>

As you can see there is no 200 there.


I figured it out.

I just check to see if the firstchild is null. The script I came up with
is:

<script language="javascript1.4">
function SalaryDisplay(me)
{
if(me.id == "WagesMin")
var salaryMinLabel = document.getElementById("SalaryMin")
else
var salaryMinLabel = document.getElementById("SalaryMax");

if (salaryMinLabel.firstChild == null)
{
var sMLText = document.createTextNode("200");
salaryMinLabel.appendChild(sMLText);
}
else
{
salaryMinLabel.firstChild.nodeValue = 5;
}
}
</script>

This works really well for Span tags.

I have a question on textboxes (input type=text). If I use the above code
and I put the number 12345 in the textbox and then leave the box - it will
put the 200 on top of the 12345 (not instead of). It doesn't get rid of the
12345 before it writes the 200, so the 200 is superimposed ontop of the
12345.

When you try to select the text and it is highlighted, only the 12345 shows.
As soon as you get rid of the selection, then you see the 200 on top of the
12345 (or whatever you changed it to) again.

Is this because that the 12345 is the value and the 200 is something else?

Why is it on top of the 12345 instead of next to it?

Thanks,

Tom
Thanks,

Tom

Jul 23 '05 #7
Ok.

This obviously is not going to work. I spent a lot of time getting this
work correctly and just found that if you go back a page (or forward) and
then go back to the page - all this SPAN information that was just generated
is now gone. Probably related to why it doesn't appear in Viewsource.

Is there a way to make sure it stays with the page?

Thanks,

Tom

"tshad" <ts**********@ftsolutions.com> wrote in message
news:mS***************@newssvr14.news.prodigy.com. ..

"tshad" <ts**********@ftsolutions.com> wrote in message
news:HH**************@newssvr14.news.prodigy.com.. .
"nutso fasst" <no********@no.where> wrote in message
news:db******************@newssvr21.news.prodigy.c om...

"tshad" <ts**********@ftsolutions.com> wrote in message
news:Ow******************@newssvr21.news.prodigy.c om...
Is there a problem setting the span element?

A 'value' property on span does not display. The newly-created span
element
is empty and needs to have a text node appended.

var salaryMinLabel = document.getElementById("SalaryMin");
var sMLText = document.createTextNode("200")
salaryMinLabel.appendChild(sMLText);
alert("after setting salaryMinLabel = " +
salaryMinLabel.firstChild.nodeValue);


Works great.

Is there a way to create the child node at the beginning somehow?

The problem is that as I call this routine It creates another node each
time. I assume the next time I do the
document.getElementById("SalaryMin") the child node will still be there
(since it was appended to the next time I did it).

I am confused as to why or how it is working.

The 200 is showing on the screen, but when I do a viewsource, it isn't
there and doesn't seem to be anywhere on the page.

Here is the script from the viewsource of the page:

<script language="javascript1.4">
function SalaryDisplay(me)
{
alert("this.value = " + me.value);
var salaryMinLabel = document.getElementById("SalaryMin");
var sMLText = document.createTextNode("200")
salaryMinLabel.appendChild(sMLText);
SalaryMin2.innerText = 200;
alert("after setting salaryMinLabel = " +
salaryMinLabel.firstChild.nodeValue);
}
</script>

Here is the html of the label (span):

&nbsp;&nbsp;Yearly Compens:<span id="SalaryMin"></span>&nbsp;/&nbsp;
<span id="SalaryMax"></span>

As you can see there is no 200 there.


I figured it out.

I just check to see if the firstchild is null. The script I came up with
is:

<script language="javascript1.4">
function SalaryDisplay(me)
{
if(me.id == "WagesMin")
var salaryMinLabel = document.getElementById("SalaryMin")
else
var salaryMinLabel = document.getElementById("SalaryMax");

if (salaryMinLabel.firstChild == null)
{
var sMLText = document.createTextNode("200");
salaryMinLabel.appendChild(sMLText);
}
else
{
salaryMinLabel.firstChild.nodeValue = 5;
}
}
</script>

This works really well for Span tags.

I have a question on textboxes (input type=text). If I use the above code
and I put the number 12345 in the textbox and then leave the box - it will
put the 200 on top of the 12345 (not instead of). It doesn't get rid of
the 12345 before it writes the 200, so the 200 is superimposed ontop of
the 12345.

When you try to select the text and it is highlighted, only the 12345
shows. As soon as you get rid of the selection, then you see the 200 on
top of the 12345 (or whatever you changed it to) again.

Is this because that the 12345 is the value and the 200 is something else?

Why is it on top of the 12345 instead of next to it?

Thanks,

Tom
Thanks,

Tom


Jul 23 '05 #8

"tshad" <ts**********@ftsolutions.com> wrote in message
news:FW******************@newssvr13.news.prodigy.c om...
Is there a way to make sure it stays with the page?


The span tag is being created server-side (runat=server); that is the
'source' you view. Content changes you make client-side do not automatically
go back to the source, and they are not automatically saved/restored if you
switch to another page and then return. You could create a framed site and
save all current values for each page in variables in the top frame. I don't
know about .net, but suppose there is a database connector. Suggest you try
a Microsoft .net newsgroup.

nf
Jul 23 '05 #9
tshad wrote:
Ok.

Please don't top-post - read the group FAQ:

<URL:http://www.jibbering.com/faq/#FAQ2_3>
This obviously is not going to work. I spent a lot of time getting this
work correctly and just found that if you go back a page (or forward) and
then go back to the page - all this SPAN information that was just generated
is now gone. Probably related to why it doesn't appear in Viewsource.
The page source is what was loaded from the server. Whatever you do
locally with scripting does not change the source any more than
modifying a photocopy changes the original.

Some information from history pages may be saved in cache by browsers
and used when the page is re-visited, but that mostly applies to data
entered into forms fields. Even then, you should not depend on this
behaviour being consistent across browsers. I don't think any
browser will cache changes made by scripts.

Is there a way to make sure it stays with the page?


This infers that you wish to maintain state somehow. Various methods
exist, such as storing user selections in a cookie or sending data
back to the server and then reconstructing the page when the user
re-visits. But that takes serious programming effort at both client
and server since the web is stateless and you are attempting to make
it otherwise.

[...]
--
Rob
Jul 23 '05 #10
"RobG" <rg***@iinet.net.auau> wrote in message
news:23****************@news.optus.net.au...
tshad wrote:
Ok.


Please don't top-post - read the group FAQ:

<URL:http://www.jibbering.com/faq/#FAQ2_3>
This obviously is not going to work. I spent a lot of time getting this
work correctly and just found that if you go back a page (or forward) and
then go back to the page - all this SPAN information that was just
generated is now gone. Probably related to why it doesn't appear in
Viewsource.


The page source is what was loaded from the server. Whatever you do
locally with scripting does not change the source any more than
modifying a photocopy changes the original.

Some information from history pages may be saved in cache by browsers
and used when the page is re-visited, but that mostly applies to data
entered into forms fields. Even then, you should not depend on this
behaviour being consistent across browsers. I don't think any
browser will cache changes made by scripts.

Is there a way to make sure it stays with the page?


This infers that you wish to maintain state somehow. Various methods
exist, such as storing user selections in a cookie or sending data
back to the server and then reconstructing the page when the user
re-visits. But that takes serious programming effort at both client
and server since the web is stateless and you are attempting to make
it otherwise.


No more that saving what is in the textboxes and which radio buttons that
were pushed. If you come back to the page, they are still there. Whatever
the SPAN originally was is also still there.

If I enter 100 into a text box and then hit the back button and then the
forward button, the box still has 100 in it. The 100 wasn't on the original
page that was sent. So it is saved somewhere. And not just what the user
puts in. I use Javascript to reformat the number to add a "$" and ","s.
When I come back, the number is still formatted.

But if I create a node for my SPAN in javascript (the same as my changing
the formatting in Javascript) to show calculated number as a label, I seem
to lose the Node I created. Why is that?

Thanks,

Tom
Jul 23 '05 #11
tshad wrote:
[...]
Is there a way to make sure it stays with the page?


This infers that you wish to maintain state somehow. Various methods
exist, such as storing user selections in a cookie or sending data
back to the server and then reconstructing the page when the user
re-visits. But that takes serious programming effort at both client
and server since the web is stateless and you are attempting to make
it otherwise.

No more that saving what is in the textboxes and which radio buttons that
were pushed. If you come back to the page, they are still there. Whatever
the SPAN originally was is also still there.


That's just how browsers work. Back in the good 'ol days, some
browsers didn't remember form values either but that was back with
Mozaic and Netscape 2 or somewhere back then.

I had a few comments on the code you've been posting, the only one of
use is in regard to your script tag: ditch the language attribute, it
is depreciated and will cause errors in some browsers.

You can do what you require if you have a form initialisation
function that looks at each form input and if there's something
there, runs the onchange if there is one.

Below is some sample code for what you are trying to do:

<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN'
'http://www.w3.org/TR/html4/strict.dtd'>
<html><head>
<title>form thing</title>
<meta http-equiv='Content-Type'
content='text/html; charset=ISO-8859-1'>
<script type="text/javascript">

function writeToSpan(t,o) {
if (document.getElementById) {
o = document.getElementById(o);
} else if (document.all) {
o = document.all[o];
}
writeIt(t,o);
}

function writeIt(t,x) {
if ( x.firstChild && /\#text/i.test(x.firstChild.nodeName)) {
x.firstChild.data = t;
} else {
if (document.createTextNode) {
x.appendChild(document.createTextNode(t));
}
}
}

function initForm(f){
f = document.forms[f];
var i = f.length;
while (i--) {
if (/input/i.test(f[i].nodeName)
&& /text/i.test(f[i].type)
&& f[i].onchange
&& '' != f[i].value){
f[i].onchange();
}
}
}

</script>
</head>
<body onload="initForm('formA');">

<form action="" name="formA">
<p>Write text to page:
<input name="inA" type="text" onchange="
writeToSpan(this.value,'outA');
"><span id="outA"></span>
<br>
Write text to input:
<input name="inB" type="text" onchange="
this.form.outB.value = this.value;
"><input type="text" name="outB">
<br><br>
<label for="inC">Replace this label:
<br><input name="inC" id="inC" type="text" onchange="
writeIt(this.value,this.parentNode);
"></label>
<br><br>
<input type="reset">
</p>
</form>

</body>
</html>

--
Rob
Jul 23 '05 #12
RobG wrote:
[...]

function initForm(f){
f = document.forms[f];
var i = f.length;
while (i--) {
if (/input/i.test(f[i].nodeName)
&& /text/i.test(f[i].type)
&& f[i].onchange
&& '' != f[i].value){
f[i].onchange();
}
}
}
Here is a more efficient initForm function:

function initForm(f){
f = document.forms[f];
var x, i = f.length;
while ( x = f[--i] ) {
if ( /text/i.test(x.type) && x.onchange && '' != x.value){
x.onchange();
}
}
}

</script>
</head>
<body onload="initForm('formA');">

<form action="" name="formA">
<p>Write text to page:
<input name="inA" type="text" onchange="
writeToSpan(this.value,'outA');
"><span id="outA"></span>
And to test that only the onchange() is fired, put this into the form
about here:

<br>onblur Write text to page:
<input name="inD" type="text" onblur="
writeToSpan(this.value,'outD');
"><span id="outD"></span>
<br>
Write text to input:
<input name="inB" type="text" onchange="
this.form.outB.value = this.value;
"><input type="text" name="outB">
<br><br>

[...]
--
Rob
Jul 23 '05 #13
These look pretty good.

I need to spend some time to digest them.

What does "/input/i.test(f[i].nodeName" and "/text/i.test(f[i].type" mean?

What I did on my page was to call the routine I use to create the SPAN label
Nodes. Since they are just calculated and formatted from a couple of text
fields (which are saved anyway), I just rebuild them from the text boxes.

<body class="ApplicantBody" onLoad="SalaryDisplayFromOnLoad()">

function SalaryDisplayFromOnLoad()
{
var WagesType = document.getElementById("WagesType");
SalaryDisplay(WagesType);
}

This seems to work. But doesn't take into account SPANs that are not
calculated from a text field and they only handle these specific labels, not
all the labels that might be created, as yours does.

Thanks,

Tom

"RobG" <rg***@iinet.net.auau> wrote in message
news:qv****************@news.optus.net.au...
RobG wrote:
[...]

function initForm(f){
f = document.forms[f];
var i = f.length;
while (i--) {
if (/input/i.test(f[i].nodeName)
&& /text/i.test(f[i].type)
&& f[i].onchange
&& '' != f[i].value){
f[i].onchange();
}
}
}


Here is a more efficient initForm function:

function initForm(f){
f = document.forms[f];
var x, i = f.length;
while ( x = f[--i] ) {
if ( /text/i.test(x.type) && x.onchange && '' != x.value){
x.onchange();
}
}
}

</script>
</head>
<body onload="initForm('formA');">

<form action="" name="formA">
<p>Write text to page:
<input name="inA" type="text" onchange="
writeToSpan(this.value,'outA');
"><span id="outA"></span>


And to test that only the onchange() is fired, put this into the form
about here:

<br>onblur Write text to page:
<input name="inD" type="text" onblur="
writeToSpan(this.value,'outD');
"><span id="outD"></span>
<br>
Write text to input:
<input name="inB" type="text" onchange="
this.form.outB.value = this.value;
"><input type="text" name="outB">
<br><br>

[...]
--
Rob

Jul 23 '05 #14

"RobG" <rg***@iinet.net.auau> wrote in message
news:qv****************@news.optus.net.au...
RobG wrote:
[...]

function initForm(f){
f = document.forms[f];
var i = f.length;
while (i--) {
if (/input/i.test(f[i].nodeName)
&& /text/i.test(f[i].type)
&& f[i].onchange
&& '' != f[i].value){
f[i].onchange();
}
}
}


Here is a more efficient initForm function:

function initForm(f){
f = document.forms[f];
var x, i = f.length;
while ( x = f[--i] ) {
if ( /text/i.test(x.type) && x.onchange && '' != x.value){
x.onchange();
}
}
}

</script>
</head>
<body onload="initForm('formA');">

<form action="" name="formA">
<p>Write text to page:
<input name="inA" type="text" onchange="
writeToSpan(this.value,'outA');
"><span id="outA"></span>


And to test that only the onchange() is fired, put this into the form
about here:

<br>onblur Write text to page:
<input name="inD" type="text" onblur="
writeToSpan(this.value,'outD');
"><span id="outD"></span>

I don't quite understant this one?

Why is the onblur where it is? I may have misunderstood.

Here is what I think you said:

**********************************************8
<form action="" name="formA">
<p>Write text to page:
<input name="inA" type="text"
onchange="writeToSpan(this.value,'outA');"><span id="outA"></span>

<br>onblur Write text to page:
<input name="inD" type="text" onblur="
writeToSpan(this.value,'outD');
"><span id="outD"></span>

<br>
Write text to input:<input name="inB" type="text"
onchange="this.form.outB.value = this.value;">
<input type="text" name="outB">
<br><br>
<label for="inC">Replace this label:<br>
<input name="inC" id="inC" type="text"
onchange="writeIt(this.value,this.parentNode);">
</label>
<br><br>
<input type="reset">
</p>
</form>
************************************************** ***************

Not sure what that does.

Tom
<br>
Write text to input:
<input name="inB" type="text" onchange="
this.form.outB.value = this.value;
"><input type="text" name="outB">
<br><br>

[...]
--
Rob

Jul 23 '05 #15
tshad wrote:
These look pretty good.

I need to spend some time to digest them.

What does "/input/i.test(f[i].nodeName" and "/text/i.test(f[i].type" mean?
/input/i creates a regular expression (RegExp) out of 'input' and the
i flag makes it case insensitive. 'test' will compare it to the
element f[i] nodeName to see if it's an input.

It is effectively the same as:

if (f[i].nodeName.toLowerCase() == 'input')

The HTML spec says to make such comparisons case insensitive, the
RegExp is fast.

The second test looks at the type of input - we want to match only
text inputs. It's probably not necessary to test nodeName before
type, I just figured some browsers may barf if you try to get the
type of a node that doesn't have one (e.g. label) but that seems not
to be the case.

What I did on my page was to call the routine I use to create the SPAN label
Nodes. Since they are just calculated and formatted from a couple of text
fields (which are saved anyway), I just rebuild them from the text boxes.

<body class="ApplicantBody" onLoad="SalaryDisplayFromOnLoad()">

function SalaryDisplayFromOnLoad()
{
var WagesType = document.getElementById("WagesType");
SalaryDisplay(WagesType);
}

This seems to work. But doesn't take into account SPANs that are not
calculated from a text field and they only handle these specific labels, not
all the labels that might be created, as yours does.

Thanks,

[...]
--
Rob
Jul 23 '05 #16
tshad wrote:
"RobG" <rg***@iinet.net.auau> wrote in message
news:qv****************@news.optus.net.au...
RobG wrote:
[...] [...]
<form action="" name="formA">
<p>Write text to page:
<input name="inA" type="text" onchange="
writeToSpan(this.value,'outA');
"><span id="outA"></span>
And to test that only the onchange() is fired, put this into the form
about here:

<br>onblur Write text to page:
<input name="inD" type="text" onblur="
writeToSpan(this.value,'outD');
"><span id="outD"></span>

I don't quite understant this one?

Why is the onblur where it is? I may have misunderstood.


I just put an onblur there to show that the function only ran
onchange events and nothing else. It's only there for testing.
Here is what I think you said:

**********************************************8
<form action="" name="formA">
<p>Write text to page:
<input name="inA" type="text"
onchange="writeToSpan(this.value,'outA');"><span id="outA"></span>
This calls writeToSpan() and passes the value of the text input and
the id of where to write the output to. Both are strings.

<br>onblur Write text to page:
<input name="inD" type="text" onblur="
writeToSpan(this.value,'outD');
"><span id="outD"></span>
This is just a test to show that onblur is not run by the onload,
only the onchange events.

<br>
Write text to input:<input name="inB" type="text"
onchange="this.form.outB.value = this.value;">
This assigns the of this input to the one called outB.
<input type="text" name="outB">
<br><br>
<label for="inC">Replace this label:<br>
<input name="inC" id="inC" type="text"
onchange="writeIt(this.value,this.parentNode);">
And this one calls writeIt() and passes the value of the text input
and a reference to the parent node (which is the label). Note that
the label will only be the parent if the text input is between the
label tags.
</label>
<br><br>
<input type="reset">
</p>
</form>
************************************************** ***************

Not sure what that does.

[...]

It's just a sample to illustrate how it all works, hopefully written
in reasonably clear and concise code. Use whatever helps.
--
Rob
Jul 23 '05 #17
"RobG" <rg***@iinet.net.auau> wrote in message
news:42***********************@per-qv1-newsreader-01.iinet.net.au...
tshad wrote:
"RobG" <rg***@iinet.net.auau> wrote in message
news:qv****************@news.optus.net.au...
RobG wrote:
[...] [...]<form action="" name="formA">
<p>Write text to page:
<input name="inA" type="text" onchange="
writeToSpan(this.value,'outA');
"><span id="outA"></span>

And to test that only the onchange() is fired, put this into the form
about here:

<br>onblur Write text to page:
<input name="inD" type="text" onblur="
writeToSpan(this.value,'outD');
"><span id="outD"></span>
I don't quite understant this one?

Why is the onblur where it is? I may have misunderstood.


I just put an onblur there to show that the function only ran onchange
events and nothing else. It's only there for testing.
Here is what I think you said:

**********************************************8
<form action="" name="formA">
<p>Write text to page:
<input name="inA" type="text"
onchange="writeToSpan(this.value,'outA');"><span id="outA"></span>


This calls writeToSpan() and passes the value of the text input and
the id of where to write the output to. Both are strings.

<br>onblur Write text to page:
<input name="inD" type="text" onblur="
writeToSpan(this.value,'outD');
"><span id="outD"></span>


This is just a test to show that onblur is not run by the onload,
only the onchange events.

<br>
Write text to input:<input name="inB" type="text"
onchange="this.form.outB.value = this.value;">


This assigns the of this input to the one called outB.
<input type="text" name="outB">
<br><br>
<label for="inC">Replace this label:<br>
<input name="inC" id="inC" type="text"
onchange="writeIt(this.value,this.parentNode);">


And this one calls writeIt() and passes the value of the text input
and a reference to the parent node (which is the label). Note that
the label will only be the parent if the text input is between the
label tags.
</label>
<br><br>
<input type="reset">
</p>
</form>
************************************************** ***************

Not sure what that does.

[...]

It's just a sample to illustrate how it all works, hopefully written
in reasonably clear and concise code. Use whatever helps.


That's great. It really helps. I am just trying to get a handle on it.

Thanks,

Tom
--
Rob

Jul 23 '05 #18

"RobG" <rg***@iinet.net.auau> wrote in message
news:42***********************@per-qv1-newsreader-01.iinet.net.au...
tshad wrote:
These look pretty good.

I need to spend some time to digest them.

What does "/input/i.test(f[i].nodeName" and "/text/i.test(f[i].type" mean?

/input/i creates a regular expression (RegExp) out of 'input' and the
i flag makes it case insensitive. 'test' will compare it to the
element f[i] nodeName to see if it's an input.
Is there a good page that talks about this method?

I've never seen it before.

Thanks,

Tom It is effectively the same as:

if (f[i].nodeName.toLowerCase() == 'input')

The HTML spec says to make such comparisons case insensitive, the
RegExp is fast.

The second test looks at the type of input - we want to match only
text inputs. It's probably not necessary to test nodeName before
type, I just figured some browsers may barf if you try to get the
type of a node that doesn't have one (e.g. label) but that seems not
to be the case.

What I did on my page was to call the routine I use to create the SPAN

label Nodes. Since they are just calculated and formatted from a couple of text fields (which are saved anyway), I just rebuild them from the text boxes.
<body class="ApplicantBody" onLoad="SalaryDisplayFromOnLoad()">

function SalaryDisplayFromOnLoad()
{
var WagesType = document.getElementById("WagesType");
SalaryDisplay(WagesType);
}

This seems to work. But doesn't take into account SPANs that are not
calculated from a text field and they only handle these specific labels, not all the labels that might be created, as yours does.

Thanks,

[...]
--
Rob

Jul 23 '05 #19
"RobG" <rg***@iinet.net.auau> wrote in message
news:7L****************@news.optus.net.au...
tshad wrote:
[...]

Is there a way to make sure it stays with the page?

This infers that you wish to maintain state somehow. Various methods
exist, such as storing user selections in a cookie or sending data
back to the server and then reconstructing the page when the user
re-visits. But that takes serious programming effort at both client
and server since the web is stateless and you are attempting to make
it otherwise.

No more that saving what is in the textboxes and which radio buttons that were pushed. If you come back to the page, they are still there. Whatever the SPAN originally was is also still there.


That's just how browsers work. Back in the good 'ol days, some
browsers didn't remember form values either but that was back with
Mozaic and Netscape 2 or somewhere back then.


I have been trying to find a place where it talks about what is saved and
what is not and can't seem to find it anywhere.

I was looking at "javascript: The Definitive Guide", which does a pretty
good job on DOM and how to add nodes, but I can't find anything that talks
about what is saved and what is not.

As we mentioned, the input/text box does seem to get saved, but not the SPAN
element. I would thing that would be pretty important discussion.

Thanks,

Tom
I had a few comments on the code you've been posting, the only one of
use is in regard to your script tag: ditch the language attribute, it
is depreciated and will cause errors in some browsers.

You can do what you require if you have a form initialisation
function that looks at each form input and if there's something
there, runs the onchange if there is one.

Below is some sample code for what you are trying to do:

<!DOCTYPE HTML PUBLIC '-//W3C//DTD HTML 4.01//EN'
'http://www.w3.org/TR/html4/strict.dtd'>
<html><head>
<title>form thing</title>
<meta http-equiv='Content-Type'
content='text/html; charset=ISO-8859-1'>
<script type="text/javascript">

function writeToSpan(t,o) {
if (document.getElementById) {
o = document.getElementById(o);
} else if (document.all) {
o = document.all[o];
}
writeIt(t,o);
}

function writeIt(t,x) {
if ( x.firstChild && /\#text/i.test(x.firstChild.nodeName)) {
x.firstChild.data = t;
} else {
if (document.createTextNode) {
x.appendChild(document.createTextNode(t));
}
}
}

function initForm(f){
f = document.forms[f];
var i = f.length;
while (i--) {
if (/input/i.test(f[i].nodeName)
&& /text/i.test(f[i].type)
&& f[i].onchange
&& '' != f[i].value){
f[i].onchange();
}
}
}

</script>
</head>
<body onload="initForm('formA');">

<form action="" name="formA">
<p>Write text to page:
<input name="inA" type="text" onchange="
writeToSpan(this.value,'outA');
"><span id="outA"></span>
<br>
Write text to input:
<input name="inB" type="text" onchange="
this.form.outB.value = this.value;
"><input type="text" name="outB">
<br><br>
<label for="inC">Replace this label:
<br><input name="inC" id="inC" type="text" onchange="
writeIt(this.value,this.parentNode);
"></label>
<br><br>
<input type="reset">
</p>
</form>

</body>
</html>

--
Rob

Jul 23 '05 #20
"RobG" <rg***@iinet.net.auau> wrote in message
news:42***********************@per-qv1-newsreader-01.iinet.net.au...
tshad wrote:
These look pretty good.

I need to spend some time to digest them.

What does "/input/i.test(f[i].nodeName" and "/text/i.test(f[i].type"
mean?


/input/i creates a regular expression (RegExp) out of 'input' and the
i flag makes it case insensitive. 'test' will compare it to the
element f[i] nodeName to see if it's an input.

It is effectively the same as:

if (f[i].nodeName.toLowerCase() == 'input')


Not to pick a nit, but nit-picking is what we do here:

if (/input/i.test(f[i].nodeName))

is closer to: if (f[i].nodeName.toLowerCase().indexOf('input') != -1)

than it is to: if (f[i].nodeName.toLowerCase() == 'input')

The reason I prefer the regex is because f[i].nodeName may not be typeof
'string', and if it isn't, f[i].nodeName.toLowerCase() will fail. Of
course this could be avoided with:

if ('string' == typeof f[i].nodeName &&
f[i].nodeName.toLowerCase().indexOf('input') != -1)

but:

if (/input/i.test(f[i].nodeName))

is easier to read, probably faster (although speed isn't the primary
consideration in choosing this mechanism) and guaranteed to produce the
correct result regardless of the typeof f[i].nodeName.

--
Grant Wagner <gw*****@agricoreunited.com>
comp.lang.javascript FAQ - http://jibbering.com/faq
Jul 23 '05 #21
David Dorward wrote:
Span elements don't have values. You need to create a new text node then
append it to the element to add text to it. Look at the JavaScript section
of the DOM 1 specification. http://w3.org/DOM/


There is no JavaScript section (only an `ECMAScript binding' section),
and since W3C DOM Level 1 HTML has been obsoleted by W3C DOM Level 2 HTML
which builds on W3C DOM Level 2 Core, one should look at the latter
instead. The respective sections are:

<http://www.w3.org/TR/DOM-Level-2-Core/core.html#ID-1950641247>
<http://www.w3.org/TR/DOM-Level-2-Core/ecma-script-binding.html>
PointedEars
Jul 23 '05 #22
tshad wrote:
<script language="javascript1.4">


This is not Valid HTML and error-prone. Use

<script type="text/javascript">

instead.
PointedEars
--
There are two possibilities: Either we are alone in the
universe or we are not. Both are equally terrifying.
-- Arthur C. Clarke
Jul 23 '05 #23
Grant Wagner wrote:
RobG wrote: <snip>
if (f[i].nodeName.toLowerCase() == 'input')

<snip> The reason I prefer the regex is because f[i].nodeName may
not be typeof 'string', and if it isn't,
f[i].nodeName.toLowerCase() will fail. Of course this could
be avoided with:

if ('string' == typeof f[i].nodeName &&
f[i].nodeName.toLowerCase().indexOf('input') != -1)

but:

if (/input/i.test(f[i].nodeName))

is easier to read, probably faster (although speed isn't
the primary consideration in choosing this mechanism) and
guaranteed to produce the correct result regardless of the
typeof f[i].nodeName.


An alternative to safe execution with the comparison operation could
be:-

if((new String(f[i].nodeName)).toLowerCase() == 'input')

- and/or:-

if( (new String(f[i].nodeName)).toLowerCase().indexOf('input') != -1 )

- because the result of applying the ECMAScript internal ToString
function to null or undefined are known strings that do not resemble
'input'. The safety measure also has the advantage of not carrying an
overhead as the construction of the String object was implied by the
context of a String method call (assuming f[i].nodeName actually was a
string to start with).

Richard.
Jul 23 '05 #24
Thomas 'PointedEars' Lahn wrote:

There is no JavaScript section (only an `ECMAScript binding' section),
synonyms :)
and since W3C DOM Level 1 HTML has been obsoleted by W3C DOM Level 2 HTML
which builds on W3C DOM Level 2 Core, one should look at the latter
instead.


The DOM 2 spec says that it builds on the DOM 1 spec, so wouldn't it
supplement it rather then obsolete it?

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Jul 23 '05 #25
"Richard Cornford" <Ri*****@litotes.demon.co.uk> writes:
An alternative to safe execution with the comparison operation could
be:-

if((new String(f[i].nodeName)).toLowerCase() == 'input')


While it's probably not hurtfull in any way, you never need to create
a new String object explicitly. Exactly the same effect would be
achieved by
if ((String(f[i].nodeName)).toLowerCase() == 'input')

Behind the scenes, there might be created a new String object anyway,
in order to call it's toLowerCase method, but an intelligent
Javascript interpreter should be able to optimize that away (should
such one exist).
I just don't like to see "new String(...)" :)
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #26
Lasse Reichstein Nielsen wrote:
Richard Cornford wrote:
An alternative to safe execution with the comparison
operation could be:-

if((new String(f[i].nodeName)).toLowerCase() == 'input')
While it's probably not hurtfull in any way, you never need
to create a new String object explicitly. Exactly the same
effect would be achieved by
if ((String(f[i].nodeName)).toLowerCase() == 'input')


Yes, the end result would be identical.
Behind the scenes, there might be created a new String
object anyway, in order to call it's toLowerCase method,
That is what ECMA 262 says happens when a method of a string object is
called on a string primitive.
but an intelligent Javascript interpreter
should be able to optimize that away (should
such one exist).
Yes, implementations may optimise any aspects of ECMA 262, they are only
required to behave (or appear to behave) as if they were following the
specification. But it is extremely difficult to tell which are
optimising what, and how. And in the cross-browser scripting world we
should not be too interested in optimisations that may only apply to
some implementations.
I just don't like to see "new String(...)" :)


And I don't mind seeing it when it is serving some purpose. Certainly
whenever I am planning to call more than three or so String methods on a
single string primitive I will usually explicitly convert it into a
String object (so that it is not necessary for the interpreter to do so
internally for each method call).

As a method of rendering a questionable, but probably string type,
property safe for the application of String methods I wouldn't argue
that passing the property's value through the String constructor called
as a function is equally effective. But as the language specification
says that an intermediate String object is created I see the explicit
construction of a String object as no more than rendering apparent what
should be expected to be happening anyway. (By 'expected' I mean that an
understanding based on the spec should expect that to be happening
conceptually, not that the interpreter actually has to be doing it.)

Maybe it is just a matter of personal bias, with my predominantly OO
programming experience numbing me to the sight of just another object
being constructed and your (I would guess) greater experience of
functional programming (certainly greater than mine) leaving you
preferring to see functions used. Or is there something more tangible
that can be said against the use of the object constructor?

You have probably guessed that I am not buying the efficiency due to
possible optimisation argument. And would counter by pointing out that
by the spec the implied String object creation will mean one extra call
to the internal ToString method with your version. Though as that call
is passing ToString a string primitive argument, which will just be
returned unaltered, the difference would be expected to be negligible.

Richard.
Jul 23 '05 #27
David Dorward wrote:
Thomas 'PointedEars' Lahn wrote:
There is no JavaScript section (only an `ECMAScript binding' section),


synonyms :)


Joky: yes :) Seriously: no.
and since W3C DOM Level 1 HTML has been obsoleted by W3C DOM Level 2 HTML
which builds on W3C DOM Level 2 Core, one should look at the latter
instead.


The DOM 2 spec says that it builds on the DOM 1 spec, so wouldn't it
supplement it rather then obsolete it?


Yo (Yes and no ;-)). See for yourself:

,-<http://www.w3.org/TR/DOM-Level-2-HTML/>
|
| Note: This specification renders the DOM Level 1 HTML Recommendation
| obsolete given that some changes from DOM Level 1 HTML are incompatible
| with that specification but represent more accurately the state of
| deployed software. W3C strongly suggests that developers and authors
| conform to DOM Level 2 HTML instead.
PointedEars
--
Viele glauben bloß, daß neue Formulierungen
altem Unsinn neuen Sinn einhauchen könnten.
-- Jürgen 'Jygn' Klingforth in dag°
<ar**************@klingforth.de>
Jul 23 '05 #28
Thomas 'PointedEars' Lahn wrote:
synonyms :)
Joky: yes :) Seriously: no.
Then what is the difference? I was under the impression that ECMAScript was
just the standard that was created from JavaScript and that browsers
implemented the standard now.
The DOM 2 spec says that it builds on the DOM 1 spec, so wouldn't it
supplement it rather then obsolete it?

,-<http://www.w3.org/TR/DOM-Level-2-HTML/>


Ah, I was looking at the DOM 2 Core which didn't mention that.

--
David Dorward <http://blog.dorward.me.uk/> <http://dorward.me.uk/>
Home is where the ~/.bashrc is
Jul 23 '05 #29
David Dorward schrieb:
Thomas 'PointedEars' Lahn wrote:
synonyms :)
Joky: yes :) Seriously: no.


Then what is the difference? I was under the impression that
ECMAScript was just the standard that was created from JavaScript


(I had almost posted a lengthy detailed explanation but for some reason
it did not make it into the newsgroup. So now I write only this:)

Correct. You could call ECMAScript a subset of JavaScript since
not all JavaScript 1.1+ features made it into ECMAScript, e.g.
Getters and Setters.
and that browsers implemented the standard now.


They implement Netscape JavaScript or Microsoft JScript which extend
standardized ECMAScript. They also implement and extend the W3C DOM,
a quasi-standard; the UA's DOM can also be accessed with ECMAScript
implementations (JavaScript in Gecko-based UAs, JScript in IE-based
ones) through the respective language binding feature.

I, among others, have already posted related information or pointers
thereto here several times. Google is your friend. [psf 6.1]
HTH

PointedEars
Jul 23 '05 #30
"Thomas 'PointedEars' Lahn" <Po*********@web.de> writes:
David Dorward schrieb:

Then what is the difference? I was under the impression that
ECMAScript was just the standard that was created from JavaScript
ECMAScript was created based on both Netscape JavaScript and Microsoft
JScript (which is probably why some of the features available in only
one of these is not in ECMAScript).

[ECMAScript] and that browsers implemented the standard now.


They implement Netscape JavaScript or Microsoft JScript which extend
standardized ECMAScript.


That's a yes. That these two browsers have named their extensions of
ECMAScript is mostly for historical reasons (they were named before
ECMAScript existed), but other browsers don't necessarily do so.

E.g., Opera implements ECMAScript v3. It doesn't implement Netscape
JavaScript nor Microsoft JScript. It has some extensions that are
compatible with parts of JavaScript and JScript, but it is not a full
implementation of either. As such, it's their own personal extension
of ECMAScript (and "an extended subset" of JavaScript and JScript).

Their own statement is:
<URL:http://www.opera.com/docs/specs/#ecmascript>.
Incidentally, the Windows version has a file called "es262-32.dll" :)

Did I have a point? :)
/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #31
Lasse Reichstein Nielsen wrote:
"Thomas 'PointedEars' Lahn" <Po*********@web.de> writes:
David Dorward schrieb:
Then what is the difference? I was under the impression that
ECMAScript was just the standard that was created from JavaScript
ECMAScript was created based on both Netscape JavaScript and Microsoft
JScript (which is probably why some of the features available in only
one of these is not in ECMAScript).
Having reviewed ECMA-262 (First Edition), I have to admit that my sources
were apparently incorrect. You're right, it states on page 5:

| This ECMA Standard is based on several originating technologies, the most
| well known being JavaScript? (Netscape Communications) and JScript?
| (Microsoft Corporation). The development of this Standard has started in
| November 1996.
[ECMAScript] and that browsers implemented the standard now.
They implement Netscape JavaScript or Microsoft JScript which extend
standardized ECMAScript.


That's a yes.


If I meant "yes", I would have said so.
That these two browsers have named their extensions of ECMAScript is
mostly for historical reasons (they were named before ECMAScript existed),
Those extensions are mostly not compliant with ECMAScript.
but other browsers don't necessarily do so.
E.g., Opera implements ECMAScript v3.
No. It implements many features of ECMAScript editions (_not_ versions,
BTW).
It doesn't implement Netscape JavaScript nor Microsoft JScript. It has
some extensions that are compatible with parts of JavaScript and JScript,
Which is why it does not implement ECMAScript 3 (per specification).
but it is not a full implementation of either.
Yes, indeed.
As such, it's their own personal extension of ECMAScript (and "an extended
subset" of JavaScript and JScript).
There is only one ECMAScript (with currently 4 possible editions). Any
extension/omission of it that is not allowed by the specification does
not result in an (compliant) ECMAScript implementation, strictly speaking.
And certainly the languages are not the same and/or cannot be used as
synonyms which was the question here.
Their own statement is:
<URL:http://www.opera.com/docs/specs/#ecmascript>.
Incidentally, the Windows version has a file called "es262-32.dll" :)

Did I have a point? :)


You missed it somehow.
PointedEars
Jul 23 '05 #32
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
That these two browsers have named their extensions of ECMAScript is
mostly for historical reasons (they were named before ECMAScript existed),
Those extensions are mostly not compliant with ECMAScript.


Depending on how one views extensions to a standard vs. compliance
with it. If all requirements of the standard are complied with, the
existence of further features would not make the extended language
uncompliant ... unless "no further features" *is* a requirement
of the standard. I don't believe it is for ECMAScript, quite the
contrary, in fact.

There is a difference between extending the syntax of the language
(which only IE does, with its conditional compilation features) and
extending the runtime environment that, syntactically correct,
programs are run in. The runtime environment is specified by the
standard, but not exclusively. The standard allows for extensions.
It even expects them.
It doesn't implement Netscape JavaScript nor Microsoft JScript. It has
some extensions that are compatible with parts of JavaScript and JScript,


Which is why it does not implement ECMAScript 3 (per specification).


ECMA262, 3rd edition (thanks), states (section 4):
---
ECMAScript as defined here is not intended to be computationally
self-sufficient; indeed, there are no provisions in this
specification for input of external data or output of computed
results. Instead, it is expected that the computational environment
of an ECMAScript program will provide not only the objects and other
facilities described in this specification but also certain
environment-specific host objects, whose description and behaviour
are beyond the scope of this specification except to indicate that
they may provide certain properties that can be accessed and certain
functions that can be called from an ECMAScript program.
---

A later note, from section 15, is:
---
NOTE Implementations that add additional capabilities to the set of
built-in functions are encouraged to do so by adding new functions
rather than adding new parameters to existing functions.
---

The ECMAScript standard writers *expect* implementations to have an
environment that extends that specified by the standard, while still
being compatible.
There is only one ECMAScript (with currently 4 possible editions).
Yes. It is a specification (or four).

There are several implementations of languages that comply with this
specification. Each is used in an environment where the standard-
specified runtime environment is extended with host objects and
non-standard properties.
Any extension/omission of it that is not allowed by the
specification does not result in an (compliant) ECMAScript
implementation, strictly speaking.
I disagree with this. Compliance is possible while also including
extensions, because the standard is not written to exclude extensions.
And certainly the languages are not the same and/or cannot be used
as synonyms which was the question here.


That is correct. There is no language called "Javascript" (lower case
"s").

Should anyone dare to use the word anyway, we'll just have to find a
meaning for it. I suggest "a generalization over ECMA-262-compliant
scripting languages". :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #33
Thomas 'PointedEars' Lahn wrote:
Lasse Reichstein Nielsen wrote:

<snip>
That these two browsers have named their extensions
of ECMAScript is mostly for historical reasons (they
were named before ECMAScript existed),


Those extensions are mostly not compliant with ECMAScript.
but other browsers don't necessarily do so.
E.g., Opera implements ECMAScript v3.


No. It implements many features of ECMAScript editions
(_not_ versions, BTW).
It doesn't implement Netscape JavaScript nor Microsoft
JScript. It has some extensions that are compatible with
parts of JavaScript and JScript,


Which is why it does not implement ECMAScript 3 (per
specification).
but it is not a full implementation of either.


Yes, indeed.
As such, it's their own personal extension of ECMAScript
(and "an extended subset" of JavaScript and JScript).


There is only one ECMAScript (with currently 4 possible
editions). Any extension/omission of it that is not allowed
by the specification does not result in an (compliant)
ECMAScript implementation, strictly speaking. And certainly
the languages are not the same and/or cannot be used as
synonyms which was the question here.

<snip>

ECMA 262 3rd edition commences with a section on conformance. Which
says:-

<quote cite=""ECMA 262 3rd edition Section 2>
2 Conformance

A conforming implementation of ECMAScript must provide and support all
the types, values, objects, properties, functions, and program syntax
and semantics described in this specification.

....

A conforming implementation of ECMAScript is permitted to provide
additional types, values, objects, properties, and functions beyond
those described in this specification. In particular, a conforming
implementation of ECMAScript is permitted to provide properties not
described in this specification, and values for those properties, for
objects that are described in this specification.

A conforming implementation of ECMAScript is permitted to support
program and regular expression syntax not described in this
specification. In particular, a conforming implementation of ECMAScript
is permitted to support program syntax that makes use of the "future
reserved words" listed in section 7.5.3 of this specification.
</quote>

Making it very clear that ECMA 262 provides for extension that would
include all of the differences between JavaScript, JScript and Opera's
implementation and an implementation that included nothing but what is
required by the standard. Thus they are all conforming ECMAScript
implementations.

Richard.
Jul 23 '05 #34
Lasse Reichstein Nielsen wrote:
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
That these two browsers have named their extensions of ECMAScript is
mostly for historical reasons (they were named before ECMAScript
existed), Those extensions are mostly not compliant with ECMAScript.


Depending on how one views extensions to a standard vs. compliance
with it.


There is nothing that allows for private meaning here. A specification
is a specification. Non-compliant behavior is just that.
If all requirements of the standard are complied with, the
existence of further features would not make the extended language
uncompliant ... unless "no further features" *is* a requirement
of the standard. I don't believe it is for ECMAScript, quite the
contrary, in fact.

There is a difference between extending the syntax of the language
(which only IE does, with its conditional compilation features) and
extending the runtime environment that, syntactically correct,
programs are run in. The runtime environment is specified by the
standard, but not exclusively. The standard allows for extensions.
It even expects them.
It allows for certain specified extensions, not extensions in general.
Conditional comments are one of the features that is not compliant to
ECMAScript. An ECMAScript compliant compiler would yield a syntax
error then.
It doesn't implement Netscape JavaScript nor Microsoft JScript. It has
some extensions that are compatible with parts of JavaScript and
JScript,


Which is why it does not implement ECMAScript 3 (per specification).


ECMA262, 3rd edition (thanks), states (section 4): [...]


Don't play human gateway this way. You can assume I have not only
downloaded but also read and understood all of it.
[...] it is expected that the computational environment
of an ECMAScript program will provide not only the objects and other
facilities described in this specification but also certain
environment-specific host objects, [...]
That does not say *any* extension to the *language* is allowed without
making it non-compliant. Host objects are a completely different issue.
A later note, from section 15, is:
---
NOTE Implementations that add additional capabilities to the set of
built-in functions are encouraged to do so by adding new functions
rather than adding new parameters to existing functions.
Your point is?
The ECMAScript standard writers *expect* implementations to have an
environment that extends that specified by the standard, while still
being compatible.


They expect extensions described by the specification and they expect
the existence of host objects. They do not expect that an implementation
calling itself ECMAScript compliant is in fact non-compliant.
Any extension/omission of it that is not allowed by the
specification does not result in an (compliant) ECMAScript
implementation, strictly speaking.


I disagree with this. Compliance is possible while also including
extensions, because the standard is not written to exclude extensions.


You disagree with the specification itself. What is not explicitely
"allowed" in a *specification* is "forbidden" in terms of compliance
with it.
PointedEars
Jul 23 '05 #35
Richard Cornford wrote:
[...]
<quote cite=""ECMA 262 3rd edition Section 2>
2 Conformance
[...]
</quote>

Making it very clear that ECMA 262 provides for extension that would
include all of the differences between JavaScript, JScript and Opera's
implementation and an implementation that included nothing but what is
required by the standard. Thus they are all conforming ECMAScript
implementations.


Point taken. Thank you.
PointedEars
--
Who stops to learn, ceases to exist.
-- Japan proverb
Jul 23 '05 #36
On Tue, 12 Apr 2005 21:09:07 +0100, "Richard Cornford"
<Ri*****@litotes.demon.co.uk> wrote:
Thus they are all conforming ECMAScript
implementations.


Well there are bugs...

Jim.
Jul 23 '05 #37
Jim Ley wrote:
[...] Richard Cornford [...] wrote:
Thus they are all conforming ECMAScript implementations.


Well there are bugs...


Please be more specific.
PointedEars
Jul 23 '05 #38
On Wed, 13 Apr 2005 19:30:44 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
Jim Ley wrote:
[...] Richard Cornford [...] wrote:
Thus they are all conforming ECMAScript implementations.


Well there are bugs...


Please be more specific.


There exist bugs in the JavaScript and JScript implementations that
make them non-compliant.

Jim.
Jul 23 '05 #39
On Wed, 13 Apr 2005 17:59:36 +0000, Jim Ley wrote:
On Wed, 13 Apr 2005 19:30:44 +0200, Thomas 'PointedEars' Lahn
<Po*********@web.de> wrote:
Jim Ley wrote:
[...] Richard Cornford [...] wrote:
Thus they are all conforming ECMAScript implementations.

Well there are bugs...


Please be more specific.


There exist bugs in the JavaScript and JScript implementations that
make them non-compliant.


Being non-compliant isn't a bug.

--
Life is short, but wide. -KV

Jul 23 '05 #40
Ivan Marsh <an*****@you.now> writes:
There exist bugs in the JavaScript and JScript implementations that
make them non-compliant.


Being non-compliant isn't a bug.


But claiming to be compliant and not being it, suggests that the
noncompliance is due to a bug, not a deliberate choice.

It should be noticed that JScript is not claimed to be compliant:
<URL:http://msdn.microsoft.com/library/en-us/script56/html/js56jsconabout.asp>

Rhino and SpiderMonkey do claim compliance:
<URL:http://www.mozilla.org/js/>

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #41
Jim Ley wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Jim Ley wrote:
[...] Richard Cornford [...] wrote:
Thus they are all conforming ECMAScript implementations.
Well there are bugs...

Please be more specific. <------------------------------------------.

|
There exist bugs in the JavaScript and JScript implementations that |
make them non-compliant. |

|
----------------------------------------------------------------------'
PointedEars
--
In the First World War, 13 million people were killed. In the Second
World War, 40 million people were killed. I think that if a third war
takes place, nothing is going to be left on the face of earth.
-- Shakira, 2003-02-05 @ MTV.com
Jul 23 '05 #42
Jim Ley wrote:
Richard Cornford wrote:
Thus they are all conforming ECMAScript
implementations.


Well there are bugs...


Fair enough, they all have minor behaviour that does not strictly
conform with the what is specified in ECMA 262. But it is not the
extensions that are getting in the way of that.

Ricahrd.
Jul 23 '05 #43
Thomas 'PointedEars' Lahn <Po*********@web.de> writes:
Jim Ley wrote:
[...] Thomas 'PointedEars' Lahn [...] wrote:
Jim Ley wrote:
[...] Richard Cornford [...] wrote:
> Thus they are all conforming ECMAScript implementations.
Well there are bugs...
Please be more specific. <------------------------------------------.

|
There exist bugs in the JavaScript and JScript implementations that |
make them non-compliant. |

|
----------------------------------------------------------------------'


Take arrays, a quite fundamental part of the language:

In IE:
[1,2,3,].length
is 4, it should be 3.

In FireFox:
"1" in [0,,2]
is true, should be false.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #44
>>>>>>Thus they are all conforming ECMAScript implementations.
>
>Well there are bugs...

Please be more specific. <------------------------------------------.

There exist bugs in the JavaScript and JScript implementations that |
make them non-compliant.


Take arrays, a quite fundamental part of the language:

In IE:
[1,2,3,].length
is 4, it should be 3.

In FireFox:
"1" in [0,,2]
is true, should be false.


If I do this with FF 1.02:

var my = [0,,2];
if ( my[1] ) alert('true');
else alert('false');

it displays 'false'
Andrew Poulos
Jul 23 '05 #45
Andrew Poulos schrieb:
>>> Thus they are all conforming ECMAScript implementations.

[...]
In FireFox:
"1" in [0,,2]
is true, should be false.


If I do this with FF 1.02:

var my = [0,,2];
if ( my[1] ) alert('true');
else alert('false');

it displays 'false'


I think this was about the `in' operation.
PointedEars

P.S.
Please provider proper attribution.
Jul 23 '05 #46
Lasse Reichstein Nielsen schrieb:
Ivan Marsh <an*****@you.now> writes:
There exist bugs in the JavaScript and JScript implementations
that make them non-compliant.


Being non-compliant isn't a bug.


But claiming to be compliant and not being it, suggests that the
noncompliance is due to a bug, not a deliberate choice.

It should be noticed that JScript is not claimed to be compliant:
<URL:http://msdn.microsoft.com/library/en...html/js56jscon
about.asp>

Rhino and SpiderMonkey do claim compliance:
<URL:http://www.mozilla.org/js/>


IBTD:

"with only minor exceptions ..., ... a full implementation" (M$) and
"a superset ... with mild differences" (Mozilla.org) is much the same
to me.
PointedEars
Jul 23 '05 #47
Andrew Poulos <ap*****@hotmail.com> writes:
Take arrays, a quite fundamental part of the language: ..... In FireFox:
"1" in [0,,2]
is true, should be false.
If I do this with FF 1.02:

var my = [0,,2];
if ( my[1] ) alert('true');
else alert('false');

it displays 'false'


As it should.

The "in" operator takes a string and an object, and gives true
if the object has a property with the name in string. E.g.

var o = {foo:42};
alert(["foo" in o, "bar" in o]);

It alerts "true,false".

An object might have a property with a value that is "falsey" (converts
to false as a boolean), even "undefined".

var o = {foo: undefined};
alert(["foo" in o, "bar" in o]);
alert([o["foo"],o["bar"]]);

alerts first "true,false", then "undefined,undefined".

There is a difference between not having the property, and having the
property with the value "undefined", even if attempting to read either
gives the same result (undefined).
The array literal [0,,2] should not have a property called "1"
according to the ECMAScript standard. The error in FireFox/Gecko's
ECMAScript implementation is that that it does, it just has the value
"undefined". It's a very minor and insignificant error, which is
probably why it hasen't been fixed, but it *is* an error.

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #48
"Thomas 'PointedEars' Lahn" <Po*********@web.de> writes:
IBTD:

"with only minor exceptions ..., ... a full implementation" (M$) and
"a superset ... with mild differences" (Mozilla.org) is much the same
to me.


Yes, but the Mozilla page also says "Like SpiderMonkey, Rhino is
ECMA-262 Edition 3 compliant.". However vague they are in other
places, that line is either too clear to misinterpret. It might be
wrong, but it's not ambiguous :)

/L
--
Lasse Reichstein Nielsen - lr*@hotpop.com
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
Jul 23 '05 #49
Lasse Reichstein Nielsen wrote:
The array literal [0,,2] should not have a property called "1"
according to the ECMAScript standard. [...]
Yes, it should. As of ECMAScript 3, Subsection 11.1.4 (Array Initialiser),
`[0,,2]' is the literal notation of an Array object with the following
structure and content (written as an object literal):

{"0": 0,
"1": undefined, // which is why its value converted to `false'
"2": 2,
// following other Array object specific properties like `length';
// from now on: `...'
}

The productions are:

ArrayLiteral :
[ Elision_opt ]
[ ElementList ]
[ ElementList , Elision_opt ]

ElementList :
Elision_opt AssignmentExpression
ElementList , Elision_opt AssignmentExpression

Elision :
,
Elision ,

"[0,,2]" can be produced by

ArrayLiteral
=> [ ElementList ]
=> [ ElementList , Elision_opt AssignmentExpression ]
=> [ Elision_opt AssignmentExpression , Elision_opt AssignmentExpression ]
=> [ AssignmentExpression , Elision_opt AssignmentExpression ]
=> ...
=> [ 0 , Elision_opt 2 ]
=> [ 0 , , 2 ]

and is therefore evaluated as follows:

...
[ ElementList , Elision_opt AssignmentExpression ]
| 1. Evaluate ElementList.
Evaluate production `ElementList : Elision_opt AssignmentExpression'
| 1. Create a new array as if by the expression new Array().
=> {...} == []
| 2. Evaluate Elision; if not present, use the numeric value zero.
=> 0
| 3. Evaluate AssignmentExpression.
=> 0
| 4. Call GetValue(Result(3)).
=> 0
| 5. Call the [[Put]] method of Result(1) with arguments Result(2)
| and Result(4).
=> [].[[Put]](0, 0)
=> {"0": 0, ...} == [0]
| 6. Return Result(1)
=> [0]

| 2. Evaluate Elision; if not present, use the numeric value zero.
Evaluate production `Elision : ,'
| 1. Return the numeric value 1.
=> 1

| 3. Evaluate AssignmentExpression.
=> 2

| 4. Call GetValue(Result(3)).
=> 2

| 5. Call the [[Get]] method of Result(1) with argument "length".
=> [0].[[Get]]("length")
=> 1

| 6. Call the [[Put]] method of Result(1) with arguments
| (Result(2)+Result(5)) and Result(4).
=> [0].[[Put]](1+1, 2)
=> [0].[[Put]](2, 2)

| 8.6.2.2 [[Put]] (P, V)
|
| 1. Call the [[CanPut]] method of O with name P.
=> true
| 2. If Result(1) is false, return.
| 3. If O doesn?t have a property with name P, go to step 6.
| [...]
| 6. Create a property with name P, set its value to V and give
| it empty attributes.
| 7. Return.

Now you assume that step 6.6. results in an object with the following
structure and content:

{"0": 0,
"2": 2,
...
}

However, ECMAScript 3 also states:

| 11.1.4 Array Initialiser
| [...]
| Array elements may be elided at the beginning, middle or end of the
| element list. Whenever a comma in the element list is not preceded
| by an AssignmentExpression (i.e., a comma at the beginning or after
| another comma), the missing array element contributes to the length
| of the Array and increases the index of subsequent elements.
| Elided array elements are not defined.

Since in "[0, , 2]", the second "comma in the element list is not preceded
by an AssignmentExpression", to be exact, is "a comma [...] after another
comma", "the missing array element ..." [continue reading above]. And so:

| 7. Return Result(1)
=> [0, undefined, 2]

The `in' operation returns `true' if/while the second operand has a
property named as the first operand; since that property ("1") exists
here, it returns `true'. (The property's value does not matter, as
you just explained.)
The error in FireFox/Gecko's ECMAScript implementation is that that
it does, it just has the value "undefined".


It is not an error :)
PointedEars
Jul 23 '05 #50

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

5 posts views Thread by Shawn Modersohn | last post: by
55 posts views Thread by drhowarddrfine | last post: by
10 posts views Thread by Danny | last post: by
2 posts views Thread by beseecher | last post: by
1 post views Thread by kevin.a.sweeney | last post: by
14 posts views Thread by julie.siebel | last post: by
10 posts views Thread by jodleren | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.