Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Javascript > Problems with ASP.Net object and Javascript

Reply
Thread Tools

Problems with ASP.Net object and Javascript

 
 
Richard Cornford
Guest
Posts: n/a
 
      04-11-2005
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.


 
Reply With Quote
 
 
 
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      04-11-2005
"Richard Cornford" <(E-Mail Removed)> 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 - http://www.velocityreviews.com/forums/(E-Mail Removed)
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
 
Reply With Quote
 
 
 
 
Richard Cornford
Guest
Posts: n/a
 
      04-11-2005
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.


 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      04-12-2005
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°
<(E-Mail Removed)>
 
Reply With Quote
 
David Dorward
Guest
Posts: n/a
 
      04-12-2005
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
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      04-12-2005
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
 
Reply With Quote
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      04-12-2005
"Thomas 'PointedEars' Lahn" <(E-Mail Removed)> 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 - (E-Mail Removed)
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
 
Reply With Quote
 
Thomas 'PointedEars' Lahn
Guest
Posts: n/a
 
      04-12-2005
Lasse Reichstein Nielsen wrote:

> "Thomas 'PointedEars' Lahn" <(E-Mail Removed)> 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
 
Reply With Quote
 
Lasse Reichstein Nielsen
Guest
Posts: n/a
 
      04-12-2005
Thomas 'PointedEars' Lahn <(E-Mail Removed)> 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 - (E-Mail Removed)
DHTML Death Colors: <URL:http://www.infimum.dk/HTML/rasterTriangleDOM.html>
'Faith without judgement merely degrades the spirit divine.'
 
Reply With Quote
 
Richard Cornford
Guest
Posts: n/a
 
      04-12-2005
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.


 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Copy Java Object into JavaScript Object Rahul Java 2 04-23-2007 11:06 AM
Object creation - Do we really need to create a parent for a derieved object - can't the base object just point to an already created base object jon wayne C++ 9 09-22-2005 02:06 AM
Problems with ASP.Net object and Javascript tshad ASP .Net 4 04-21-2005 12:49 PM
Re: pass javascript object reference to a session object naijacoder naijacoder ASP .Net 0 09-15-2004 02:01 AM
Re: pass javascript object reference to a session object Girish bharadwaj ASP .Net 0 09-15-2004 01:55 AM



Advertisments