Problems with ASP.Net object and Javascript

[tshad]

I have a function:

function SalaryDisplay(m e)
{
var salaryMinLabel = document.getEle mentById("Salar yMin");
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

[Grant Wagner]

"RobG" <rg***@iinet.ne t.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.toLow erCase() == '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.toLow erCase().indexO f('input') != -1)

than it is to: if (f[i].nodeName.toLow erCase() == '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.toLow erCase() will fail. Of
course this could be avoided with:

if ('string' == typeof f[i].nodeName &&
f[i].nodeName.toLow erCase().indexO f('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*****@agrico reunited.com>
comp.lang.javas cript FAQ - http://jibbering.com/faq

[Thomas 'PointedEars' Lahn]

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

[Thomas 'PointedEars' Lahn]

tshad wrote:

<script language="javas cript1.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

[Richard Cornford]

Grant Wagner wrote:

RobG wrote: <snip>

if (f[i].nodeName.toLow erCase() == '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.toLow erCase() will fail. Of course this could
be avoided with:

if ('string' == typeof f[i].nodeName &&
f[i].nodeName.toLow erCase().indexO f('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)).toL owerCase() == 'input')

- and/or:-

if( (new String(f[i].nodeName)).toL owerCase().inde xOf('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.

[David Dorward]

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

[Lasse Reichstein Nielsen]

"Richard Cornford" <Ri*****@litote s.demon.co.uk> writes:

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

if((new String(f[i].nodeName)).toL owerCase() == '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)).toL owerCase() == '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/rasterTriangleD OM.html>
'Faith without judgement merely degrades the spirit divine.'

[Richard Cornford]

Lasse Reichstein Nielsen wrote:

Richard Cornford wrote:

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

if((new String(f[i].nodeName)).toL owerCase() == '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)).toL owerCase() == '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.

[Thomas 'PointedEars' Lahn]

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.d e>

[David Dorward]

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

[Thomas 'PointedEars' Lahn]

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