object expected error

E

eruanion

Hi, I've been working on this for a while now and I can't seem to find
out what is wrong with my code. I have 2 files one c3common.js which
only contains javascript functions for my main html page and my main
html page which is test.html. They are of course part of a much bigger
system of files but i have tracked down the problem to that reduced
part of the code. The page loads perfectly fine however when i click
search i get the error line:37 object expected, which is the line of
the <form name=...... onSubmit="return validate(this);"> The code
basically just takes the data entered in name, email and phone number
and validates them with premade functions. now i know theres nothing
wrong with the functions in c3common.js because when i cut and paste
them into the html page in the script part everything starts working
perfectly but as soon as i move them into another .js file and link the
html page with the scr="c3common.js" piece of code i get the error. Oh
and before you ask the files are in the same directory so thats not the
problem. Thanks a lot for your time guys.

here it goes:

test.html =

<html>
<head>
<title>ShowEmployees (using JSTL)</title>

<script src="c3common.js" type="text/javascript"
language="JavaScript">

function validate(form)
{

window.alert("CHECK!"); //this never even gets shown at all

var check =1;

if(CheckName(form.name.value) == false)
{
window.alert("wrong name");
check =0;
}
if(CheckEmail(form.email.value) == false)
{
window.alert("wrong email");
check =0;
}
if(CheckPhoneNumber(form.telephone.value) == false)
{
window.alert("wrong telephone");
check =0;
}

return check;
}
</script>
</head>

<body>

<form name="search" method="POST" onsubmit="return
validate(this);">
<h1>Searching Employees Database</h1>

<table>
<tr>
<td>Name</td> <td><input type="text" name="name" value=""/> </td>
</tr>
<tr>
<td>E-mail Address</td> <td><input type="text" name="email"
value=""/> </td>
</tr>
<tr>
<td>Phone number</td> <td><input type="text" name="telephone"
value=""/> </td>
</tr>
<tr>
<td><input type="hidden" name="action" value="showEmployees"/>
</td>
<td><input type="hidden" name="page" value="0" /> </td>
</tr>
<tr>
<td><input type="submit" name="submit" value="Search"/> </td>
<td><input type="reset" value="Resets all fields"/> </td>
</tr>
</table>
</form>
</body>
</html>
 
V

VK

<html>
<head>
<title>ShowEmployees (using JSTL)</title>

<script src="c3common.js" type="text/javascript"
language="JavaScript">

function validate(form)

You cannot use one <script> tag for both .js file and inline code:-
inline code is being ignored in this case.

Change to:

<script src="c3common.js" type="text/javascript"></script>
<script type="text/javascript">
// inline code
</script>

As I see this error over and over in different places, I presume that
some "reputable" source claims that it's possible. If it's a wiki I
would appreciate to be pointed out so I could correct the article.

P.S. It is generally a bad idea to name you form field "name" - it may
lead to some funny addressing issues.
"customer", "user", "requester" etc. are much better.
 
E

eruanion

ohh thank you soo much, for some reason i has tried that before but
then i had made some changes to the code that might have messed it up,
works perfectly now thx.
 
R

Richard Cornford

VK said:
You cannot use one <script> tag for both .js file and
inline code:-

You cannot use one SCRIPT _tag_ for anything as HTML requires two script
tags to define one SCRIPT element (opening and closing tags are not
optional).

But you can use one SCRIPT element to import a file and simultaneously
define script within that element. It isn't a good idea to do so but it
is a reasonably commonly implemented facility; see the FAQ.
inline code is being ignored in this case.

That would depend upon the browser and factors beyond your current
understanding.
Change to:

<script src="c3common.js" type="text/javascript"></script>
<script type="text/javascript">
// inline code
</script>

That is 4 _tags_ defining two _elements_. Acquiring a basic
understanding of HTML would be a good idea prior to attempting to give
advice on the subject. The distinction between an HTML tag and an
element being pretty basic.
As I see this error over and over in different places, I
presume that some "reputable" source claims that it's possible.
<snip>

You see something you don't understand and assume that it is an error,
but the one does not follow from the other, especially as you don't
actually understand the code you write yourself (even if you are not
necessarily aware of that yourself).
P.S. It is generally a bad idea to name you form field "name"
- it may lead to some funny addressing issues.
"customer", "user", "requester" etc. are much better.

Name or NAME would do just as well, as javascript is case sensitive.

Richard.
 
T

Thomas 'PointedEars' Lahn

Richard said:
You cannot use one SCRIPT _tag_ for anything as HTML requires two script
tags to define one SCRIPT element (opening and closing tags are not
optional).
True.

But you can use one SCRIPT element to import a file and simultaneously
define script within that element.

No, you cannot. It is specified and implemented that

,-[HTML 4.01, 18.2.1 The SCRIPT element]
|
| [...] If the `src' has a URI value, user agents must ignore
| the element's contents and retrieve the script via the URI.

See below.

(There is also a common misconception among some people here regarding the
`charset' attribute [but the FAQ is clear and correct about it, the misuse
of the "tag" term aside] that is addressed by the next sentence of the
spec:

"Note that the `charset' attribute refers to the character encoding of the
script designated by the `src' attribute; it does not concern the content
of the SCRIPT element.")
It isn't a good idea to do so
True.

but it is a reasonably commonly implemented facility;

It is not in Netscape 4.8, Mozilla 1.7.12, Firefox 1.5.0.1, Opera 8.52, and
KHTML 3.5.1:

<URL:http://pointedears.de/scripts/test/include>

Netscape 4.8 even navigates to the Error 404 document if a script resource
is specified that does not exist. (Interestingly, KJS 3.5.1 does not allow
for augmentation of the Object constructor.)
see the FAQ.

The FAQ has to be corrected in that regard.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
<URL:http://pointedears.de/scripts/test/include>

[...] (Interestingly, KJS 3.5.1 does not allow for augmentation of the
Object constructor.)

Ignore that, it does. It is just that the remote version of object.js still
used FunctionExpressions in Object literals which are not supported by KJS
as yet. Therefore the included script could not be compiled, and the
Object constructor was not augmented. If you use only references to those
Function objects instead, everything is fine.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
Thomas said:
<URL:http://pointedears.de/scripts/test/include>

[...] (Interestingly, KJS 3.5.1 does not allow for augmentation of the
Object constructor.)

Ignore that, it does. It is just that the remote version of object.js
still used FunctionExpressions in Object literals which are not supported
by KJS as yet. Therefore the included script could not be compiled, and
the Object constructor was not augmented. If you use only references to
those Function objects instead, everything is fine.

It gets even more strange: the above statement is not generally true.
I have reduced the problem to the following:

var x = {
y: function z() {}
};

and

// or: var x = function() {};
// that does not make a difference
function x() {};

// The following line triggers a "read error" (message; if you have
// enabled debugging)
x({
y: function z() {}
});

If you omit the `z', thereby making the function anonymous, the error
goes away. Can anyone with a KHTML-based UA confirm or deny that?
Can anyone explain that?


PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
I have reduced the problem to the following:

var x = {
y: function z() {}
};

and

// or: var x = function() {};
// that does not make a difference
function x() {};

// The following line triggers a "read error" (message; if you have
// enabled debugging)
x({
y: function z() {}
});

If you omit the `z', thereby making the function anonymous, the error
goes away. Can anyone with a KHTML-based UA confirm or deny that?
Can anyone explain that?

I have reported this now as
<URL:https://bugs.kde.org/show_bug.cgi?id=123529>


PointedEars
 
B

Ben C

Thomas 'PointedEars' Lahn wrote:

I tried this in Konqueror, and got a parse error. If I left out the z it
worked. It worked on firefox both ways.

var x = {
y: function z() { alert("hello"); }
};
x.y();

It is definitely a bug because the grammar defines a FunctionExpression
as:

function Identifier<opt> (FormalParameterList<opt>) {FunctionBody}

So you should be allowed to have that Identifier there if you want one,
and you might need it if you wanted to make the function recursive.
 
V

VK

Richard said:
But you can use one SCRIPT element to import a file and simultaneously
define script within that element. It isn't a good idea to do so but it
is a reasonably commonly implemented facility; see the FAQ.

What FAQ? I hope it's not the official group FAQ at
<http://www.jibbering.com/faq>? I looked at and I did not see anything
similar - but I might missed it. If so, it should be corrected
immediately as it's a gross error.

<script type="text/javascript" src="outer.js">
inner:
</script>

In this case inner block will be ignored and only outer file executed.
This is really a basic - it was this way ever since src attribute was
introduced. I am not aware of any browsers having different behavior.

Just for hell of it I tested the sample below on NN 4.5 (for my memory
check), IE.6.0, FF 1.5 and Opera 8.5:

<html>
<head>
<title>Script in Script doesn't work</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript" src="outer.js">
window.alert('Hi from inner!');
</script>
</head>

<body>

</body>
</html>

// where outer.js contains:
window.alert('Hi from outer!');
 
R

Randy Webb

VK said the following on 3/14/2006 3:56 AM:
What FAQ? I hope it's not the official group FAQ at
<http://www.jibbering.com/faq>? I looked at and I did not see anything
similar - but I might missed it. If so, it should be corrected
immediately as it's a gross error.

IIRC, it is in the notes section. It was an attempted hack to try to
determine if an external file had been loaded or not.
<script type="text/javascript" src="outer.js">
inner:
</script>

<script type="text/javascript" src="fileThatDidntLoad.js">
//code here
</script>

I think you have to look back at some of the older IE and NS browsers
(NS6/7) to find browsers that will execute the code block. IE6 throws an
Invalid Character error on a src file that doesn't exist.

And yes, it should be removed.
 
V

VK

Randy said:
VK said the following on 3/14/2006 3:56 AM:

IIRC, it is in the notes section. It was an attempted hack to try to
determine if an external file had been loaded or not.


<script type="text/javascript" src="fileThatDidntLoad.js">
//code here
</script>

I think you have to look back at some of the older IE and NS browsers
(NS6/7) to find browsers that will execute the code block. IE6 throws an
Invalid Character error on a src file that doesn't exist.

There is nothing to look at: it is exactly as I said and always was
this way.
But I guess I can guess :) how this error appeared:- when Netscape
introduced src attribute and external .js file concept, they also
provided a fallback option for older Netscape versions: "inner script
statements are ignored if src attribute is set and recognized". So
looking at legacy scripts (must be really ancient though) one can see
something like:

<script language="JavaScript" src="myScript.js">
window.alert("External scripts are not supported.");
</script>

If the inner block is not so obvious as in the sample above, one may
decide that both inner and outer scripts are allowed in one tag set.
But in the reality the inner block is a *fallback code* in case if src
attribute is not supported.

As there are not any modern browsers w/o script src support, this
fallback option is currently useless (though still supported for legacy
reasons).

It is important to repeat that "inner script statements are ignored if
src attribute is *set and recognized*". It means that the src attribute
support by itself tourns inner block parsing off - so it cannot be used
for fallback if external file is not available. If in the posted sample
you change to:

<script type="text/javascript" src="non_existing_file.js">
inner:
</script>

and the inner block still will be ignored. This behavior is consistent
since NN 3.x
 
V

VK

VK said:
There is nothing to look at: it is exactly as I said and always was
this way.
But I guess I can guess :) how this error appeared:- when Netscape
introduced src attribute and external .js file concept, they also
provided a fallback option for older Netscape versions: "inner script
statements are ignored if src attribute is set and recognized". So
looking at legacy scripts (must be really ancient though) one can see
something like:

<script language="JavaScript" src="myScript.js">
window.alert("External scripts are not supported.");
</script>

If the inner block is not so obvious as in the sample above, one may
decide that both inner and outer scripts are allowed in one tag set.
But in the reality the inner block is a *fallback code* in case if src
attribute is not supported.

As there are not any modern browsers w/o script src support, this
fallback option is currently useless (though still supported for legacy
reasons).

It is important to repeat that "inner script statements are ignored if
src attribute is *set and recognized*". It means that the src attribute
support by itself tourns inner block parsing off - so it cannot be used
for fallback if external file is not available. If in the posted sample
you change to:

<script type="text/javascript" src="non_existing_file.js">
inner:
</script>

and the inner block still will be ignored. This behavior is consistent
since NN 3.x

I guess I found the offending line (thanks to Randy Webb for his hint):
<http://jibbering.com/faq/faq_notes/script_tags.html#hsMix>

In the name of Tim and Brendan :), anyone - please take it out or
change as described in this thread - *right now*!
 
R

Richard Cornford

Randy Webb wrote:
<script type="text/javascript" src="fileThatDidntLoad.js">
//code here
</script>

I think you have to look back at some of the older IE and NS browsers
(NS6/7) to find browsers that will execute the code block. IE6 throws an
Invalid Character error on a src file that doesn't exist.

Unfortunately if IE throws an invalid character error then you have not
tested the phenomenon as that is the symptom of the response form the
SRC request being treated as if it was javascript source. As browsers
treat whatever (non-HTTP error) response they get from the server when
they attempt to load a SRC as javascript source text, regardless of
headers, you can only test this using an HTTP server that is properly
set up to respond to a request for a missing resource with a
well-formed 404 HTTP error.

A server that just sends HTML error pages (as opposed to HTML content
for a 404 error) will give the browser the impression that the remote
file does exist. The same goes for local files system testing with IE
as the error page that would be displayed if you entered a file
protocol URL for a non-existing file into the address bar is the same
page that gets sent to the javascript interpreter when a non-existing
file is referenced with a SRC.
And yes, it should be removed.

Probably not, although it may benefit from more emphasis on the
non-universal browser support instead of just the issues with proper
HTTP 404 errors and the fact that the entire technique is unnecessary
in practice.

Richard.
 
V

VK

Richard said:
Randy Webb wrote:


Unfortunately if IE throws an invalid character error then you have not
tested the phenomenon as that is the symptom of the response form the
SRC request being treated as if it was javascript source. As browsers
treat whatever (non-HTTP error) response they get from the server when
they attempt to load a SRC as javascript source text, regardless of
headers, you can only test this using an HTTP server that is properly
set up to respond to a request for a missing resource with a
well-formed 404 HTTP error.

I am sorry but Randy's case has to contain some extra error in it -
this is why it caused an error in IE.

This sample works as expected (inner block is silently ignored):

<html>
<head>
<title>Untitled Document</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script language="JavaScript" src="fileThatDidntLoad.js">
alert("Hi from inner!");
</script>
</head>

<body>

</body>
</html>

I want to clarify once again: this is *missing feature fallback*, not
resource availability fallback.
If current UA understands and supports src attribute for script tag and
if this attribute is set to anything except empty string:- in this case
inner block is not parsed nor executed. It has absolutely nothing to do
with server response (200, 404, XYZ). For resource availability one
need to use onError handler (unfortunately supported by IE only), or
periodically check typeof of some variable in the *outer script*:

if ('undefined' == typeof someVar) {
setTimeout(// for another check
}
 
R

Richard Cornford

VK wrote:
I am sorry but Randy's case has to contain some extra error in it -
this is why it caused an error in IE.
<snip>

And where would those errors be? In the external file that did not
exits or in the content of the SCRIPT element that was ignored? It is
reasoning like this that makes your opinion on anything worthless.

Richard.
 
V

VK

Thomas said:
It gets even more strange: the above statement is not generally true.
I have reduced the problem to the following:

var x = {
y: function z() {}
};

and

// or: var x = function() {};
// that does not make a difference
function x() {};

// The following line triggers a "read error" (message; if you have
// enabled debugging)
x({
y: function z() {}
});

You would be even more amazed if you try your sample on any IE or an
old Netscape. If I'm reading your intentions right the result would be
far from expected ones:

<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script>
var x = {
y: function z() { alert("hello"); }
};
alert(z); // displays z function body
</script>
</head>
<body>
</body>
</html>

Function z is treated as *function statement*. The result of this
statement's execution is function reference (named or anonymous). In
any case it's being added to the Global object.
I tryed to point in
<http://groups.google.com/group/comp..._frm/thread/349b270972a6b28b/529b6517cc56c0fe>

that ()() way is based on very particular JavaScript implementation in
Firefox which is in its turn based on sloppy wording in ECMA specs
(this fact may be confirmed by Netscape 4.5 behavior which is equal to
IE's one). So ()() still works in other browsers (means doesn't crash)
but the internal mechanics is far of what authors would expect.
 
V

VK

Richard said:
VK wrote:

<snip>

And where would those errors be? In the external file that did not
exits or in the content of the SCRIPT element that was ignored? It is
reasoning like this that makes your opinion on anything worthless.

I cannot comment on it: as I said there must be some extra factor not
revealed in the posted code. Maybe by some strange occasion the .js
file with such name existed on the poster's machine and contained a
syntax error.

It seems that I have to prove again that the sky is blue (and do not
mistype the word "blue"! - otherwise the whole proof is counted as
failed :).

For the purity of picture I placed the test case on the Web so do not
deal with local files:
<http://geocities.com/schools_ring/tmp/test.html>

// test.html
<html>
<head>
<title>Test</title>
<meta http-equiv="Content-Type"
content="text/html; charset=iso-8859-1">
<script type="text/javascript" src="existing.js">
window.alert('Hi from Inner 1');
</script>
<script type="text/javascript" src="nonexisting.js">
window.alert('Hi from Inner 2');
</script>
</head>
<body>
</body>
</html>

// existing.js
window.alert("Hi from Outer 1");

// nonexisting.js
// doesn't exists as its name suggests.

Go study the behavior as long as you want on any browser you want.

After you are done *please* expedit the changes in the relevant FAQ
Notes section.
 
R

Randy Webb

Richard Cornford said the following on 3/14/2006 10:56 AM:
Randy Webb wrote:


Unfortunately if IE throws an invalid character error then you have not
tested the phenomenon as that is the symptom of the response form the
SRC request being treated as if it was javascript source. As browsers
treat whatever (non-HTTP error) response they get from the server when
they attempt to load a SRC as javascript source text, regardless of
headers, you can only test this using an HTTP server that is properly
set up to respond to a request for a missing resource with a
well-formed 404 HTTP error.

It's been so long since I looked into that I had forgotten that part of
the error. Thank you for reminding me, and yes, that would be the reason
for the error message.

It also gave me cause to read that part of the Notes. I glanced over it
quickly and have to agree with you that the way it is written is proper.
 
T

Thomas 'PointedEars' Lahn

VK said:
Thomas said:
It gets even more strange: the above statement is not generally true.
I have reduced the problem to the following:

var x = {
y: function z() {}
};

and

// or: var x = function() {};
// that does not make a difference
function x() {};

// The following line triggers a "read error" (message; if you have
// enabled debugging)
x({
y: function z() {}
});

You would be even more amazed if you try your sample on any IE or an
old Netscape. If I'm reading your intentions right the result would be
far from expected ones: [...]

You could not possibly miss the point more that I was making. No surprise
here, though.
var x = {
y: function z() { alert("hello"); }
};
alert(z); // displays z function body

Of course it does, and more.
Function z is treated as *function statement*.

No, it is a FunctionExpression, as produced through the AssignmentExpression
production (if you only read the specs once). Because of the identifier,
which is optional per the FunctionExpression production and is used here,
there is a named reference to a Function object. One which .toString()
method returns its code. This is specified behavior, and kjs' behavior is
so far not standards compliant in that regard.

A FunctionStatement is not allowed there.
[snipped the usual nonsense based on VK's usual misconceptions
about the language]

You really should look into Occam's Razor, and apply it to the results of
your thinking process. Before you post.


PointedEars
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,769
Messages
2,569,582
Members
45,058
Latest member
QQXCharlot

Latest Threads

Top