developing with / for internet explorer

[GHUM]

Hello,

I created some rather complex Intranet Application, using lots of
JavaScript, DOM-Maninpulation and XMLHTTPRequest communication.

I developed on FireFox, with the excellent firebug ... every misstake
was given back with a fine, fine traceback; exactly pointing to the
code at error.

My code runs fine on FireFox and Opera.

Now some people demand to have that application running with Internet
Explorer; and it fails at the syntax check of the JavaScript. That
surely should be fixable, but the bigger problem is:

Internet Explorer just gives me an error box with some rather bogus
line and character where he detected the error.

Enabling debugging and installing the scriptdebugger from Microsoft
(which, oddly enough, only runs with admin privileges), gives me a
debugging window. And: at each error the MochiKit main JS File is
opened at the beginning.

I am rather sure that the errors are within my JavaScript, not in
MochiKit.

So I am crying out for help: How do you resolve JS errors with Internet
Explorer? Is there any secret weapon to get at least usable line
numbers; or even a traceback of an error?

I do NOT need a full blown debugger, allowing me to single step and
all. Just "this line caused your error" with a usable "this" would be
enough.

Any suggestions?

Harald

[Richard Cornford]

GHUM wrote:

Richard,

>while IE will announce object expected. But when you discover
that the offending code is a function call, and armed with the
understandin g that functions are objects and to call a function,
so some referenced must be first resolved into an object
_and_then_ that object must turn out to be callable (have an
internal [[Call]] method) it is not so surprising that IE kicks
out an error message at the point of discovering that the
reference did not resolve as an object, and so the message is
couched in terms of object and not functions.

Thank you very much for this explanation! You did not give me
additional vocabulary, but instead gave me an insight into the
grammar :) That way of thinking will really help.

In terms of English I made a bit of a hash out of the grammar in that
paragraph (comes of trying to write posts well after I should have gone
to bed).

>>IE-Javascript, but because of the parent= ... IE seems not to
support named parameters.

>Named parameters? Javascript (any ECMA 3 rd Ed (or earlier).
implementation , including JScript <= 5.6) has no notion of named
parameters beyond the formal parameter list declarations (a comma
separated list of zero or more Identifiers) that appear in function
declarations and function expressions.

Uuups. So I just happened to abuse an assignment. Those "named
parameters" come from Python, where I do most of my development.
I grew to use those named parameters, because they help me understand
function calls years after the initial development of them.

>It is normal for browser environment hosts to provide a 'parent'
property of the global/window object that is used to hold a
reference to the global/window object of the frame containing
the (first) global/window object's frame in a frameset, or the
current global/window if there is no frameset (or IRAMEs in
the parent).

Good. So if in the interface description somebody would have
named the 3rd parameter "upperlevelelem ent" or similiar, I would
not have stumbled accross that error for ages.

Yes, assigning to 'upperlevelelem ent' would be very unlikely to provoke
any complaints from web browsers (except Gecko browser's "warnings",
and as many of those are utterly bogus (particularly in cross-browser
scripting) they are best turned off).

>It worries me that you have described this as 'named parameters'
and I wonder where you got that idea. You have not explained what
this 'MochiKit' is, or what relevance it has,

MochiKit is definitely not the "source" of that "named parameters"
idea. Those "parameter names" are used for the interface description,
giving something like:

getElementsByTa gAndClassName(t ag,class,[parent])

which is a rather usual description of a function interface. It was
clearly my mistake to keep the "parent"

It was probably a mistake to have the 'parent' there in the first place
as it is ambiguous in a browser object model where numerous
parent-child relationships exist (including the frame/frameset
relationships). Something like 'parentElement' would seem more clear,
except that the value being passed in is a string, which is assume is
an ID string for an element, and so 'parentElementI d' would probably be
the name that states what the parameter actually is. Then again, if
this function works like - getElementByTag Name - then maybe
'ancestorElemen tID' would be better yet as the IDed element will not
necessarily be the 'parent' of the elements returned.

... the reasoning was: "of course parameter 1 is a TAG, and 2 is
a CLASS... if the function is called "by Tag and Class". But will I
really know what the 3rd parameter is on first sight after 6months?

Which is fine so long as in 6 months time you don't have a better
appreciation of the browser DOM and find yourself wondering what this
'parent' has to do with the containing frame.

So to save me from looking
up the definition,

Generally, it should never be too much effort to cross-reference a
function call with the function definition, where the meaning of the
parameters (if not completely obvious) should be the subject of
comments. Javascript projects are rarely that big that locating the
code for a function definition is a major undertaking.

I used this "named parameter", and it worked out
fine. Or rahter, it seemed to work out fine.

Javascript can be like that; lots of things 'work', or seem to 'work',
while not doing what the expectation that motivated them thinks they
should be doing. If you look you will see plenty of 'mystical
incantations' appearing in published javascript code, with there
authors very reluctant to expand on their motivations for using them.

MochiKit itself is a really well documented JavaScript library at
www.mochikit.com; developed mainly by Bob Ipollito.

Fair enough, but bare in mind that there is an inverse relationship
between an individuals understanding of javascript (particularly in
relation to Internet browser scripting) and their tendency to use
large, interdependent javascript libraries (well documented or
otherwise). They are too self-evidently a poor approach to issues of
browser scripting so with the understanding comes a quest for a more
appropriate strategy to code re-use.

<snip>

The only thing MochiKit would be to "blame" of is that it
makes JavaScript often feel like Python - which is feel as
a good thing, because it makes me feel at home. So, feeling
"at home" I did as I do "at home".

<snip>

Probably the one factor that has resulted in the creation of more bad
javascript than any other is its ability to faster a sense of over
confidence in near-novices.

Personally, I think it is a mistake to try to make javascript seem like
any language that is not javascript. Javascript is sufficiently
flexible that in many respects it is possible to do that (or give the
illusion of having done that), but the more successful the attempt the
more the programmers of those other languages will bring in
expectations that will often be ultimately disappointed and prior to
that will act to keep them from understanding javascript for what it
is.

Richard.

[Randy Webb]

Dr John Stockton said the following on 7/16/2006 3:25 PM:

JRS: In article <n7************ *************** ***@comcast.com >, dated
Sun, 16 Jul 2006 01:29:28 remote, seen in news:comp.lang. javascript,
Randy Webb <Hi************ @aol.composted :

>Dr John Stockton said the following on 7/15/2006 6:30 PM:

>>JRS: In article <e9************ *******@news.de mon.co.uk>, dated Sat, 15
Jul 2006 13:45:06 remote, seen in news:comp.lang. javascript, Richard
Cornford <Ri*****@litote s.demon.co.ukpo sted :
Similarly, finding the exact line of code in a javascript file; If the
error report says line 45 the actual error will be in the immediate
vicinity of line 45, but not necessarily on that line. You go to, say,
line 42 and add a blank line after it, skip the next line of code and
add another blank line, skip the next line of code and add another
blank, and so on, inserting say 6 blank lines. If re-producing the error
now claims that it is on line 48 you know exactly which line it is on
because it is the line following the third blank line inserted.

That's not necessarily the location of the real error;

If that is your criteria, then you will *never* know the location of the
real error.

You mean "criterion" , the singular form.

No, I meant what I typed.

It is essential to determine the location of the real error, because
that is where the correction needs to be made.

That is for the programmer, not the browser to determine.

>>it's the location where Javascript realises that an error has occurred.

And that is all you can expect from the browser.

Of course; but Richard's words were claiming that to be the location of
the actual error.

Umm, because that *is* where the actual error is *to the parser*.

Richard's method, which I sometimes need myself, is good for determining
the line containing the point at which the code ceased to be possibly
valid; that's all.

And that's all you can depend on the browser to tell you.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly
Temporarily at: http://members.aol.com/_ht_a/hikksnotathome/cljfaq/
Javascript Best Practices - http://www.JavascriptToolbox.com/bestpractices/