Strange "Element undefined" problem

[Daniel Breitner]

Hi experts,

I get a strange Error "'Element' is undefined" in IE at
http://bbold.de/exercises/cryptic_clue/index.php?exc=voltage
It also does not work in FF; seems same problem, although FF shows no
error at all. The funny (strange) thing is, that the *same* (!) code
is *running* on
http://demo2.wuwei-webservices.de/cryptic_clue/index.php?exc=voltage
Here you can see, what this eLearning exercise should do actually.

Since there it works fine, and on bbold.de not, where I simply wanted
to install a copy, I am out of my abilites. Please help!

Explanation to the line that IE complains about: (652 of page source)
Element.addMethods(WuweiElementExtensions);

WuweiElementExtensions is defined in the lines before, and then I
simply going to attach the functions defined there to the Element
object. This all is based on prototype framework. Why should Element
here be undefined?? (And not at the other domain with the same code?)

Thank you very much!!!
Daniel

*************

Marty - it's perfect! You're just not thinking fourth dimensionally!
[Emmett "Doc" Brown]

If you wish to email me, please use newsreply at wuwei minus webservices dot de

 

[Matthias Reuter]

The funny (strange) thing is, that the *same* (!) code

is *running* on

No it's not the same code.

http://demo2.wuwei-webservices.de/cryptic_clue/index.php?exc=voltage

Here you embed Prototype at the beginning.

http://bbold.de/exercises/cryptic_clue/index.php?exc=voltage

Here you embed your code before Prototype. And it's generally a bad idea
to include scripts inline.

Matt

 

[Thomas 'PointedEars' Lahn]

[...] And it's generally a bad idea to include scripts inline.

Nonsense. "Embedding scripts inline" avoids the overhead created by
additional HTTP requests. Of course, it makes maintenance harder, so if
that approach is followed it should be done through a server-side script.

It is generally a bad idea to use Prototype.js, though.

And the OP's markup is not Valid.


PointedEars

 

[Gregor Kofler]

Daniel Breitner meinte:

[snip]

This all is based on prototype framework.

Here is the problem.

Why should Element
here be undefined?? (And not at the other domain with the same code?)

Not only the code - I assume the markup should be identical, too.

Thank you very much!!!

You are welcome.

BTW Firebug tells me:

Element.addMethods is not a function
http://bbold.de/exercises/cryptic_clue/index.php?exc=voltage
Line 652

Selector is undefined
http://bbold.de/exercises/cryptic_clue/index.php?exc=voltage
Line 4099


Gregor

 

[Jorge]

[...] And it's generally a bad idea to include scripts inline.

Nonsense.  "Embedding scripts inline" avoids the overhead created by
additional HTTP requests. (...)

.... and precludes the benefits of caching.

 

[Daniel Breitner]

On Fri, 24 Jul 2009 13:52:54 +0200, "Matthias Reuter"


uh. thank u. i will check that out soon. if you are right (which i
dont doubt), how could this happen... (question just to myself =)

*************

Marty - it's perfect! You're just not thinking fourth dimensionally!
[Emmett "Doc" Brown]

If you wish to email me, please use newsreply at wuwei minus webservices dot de

 

[Daniel Breitner]

On Fri, 24 Jul 2009 14:00:14 +0200, Thomas 'PointedEars' Lahn

| Of course, it makes maintenance harder, so if
|that approach is followed it should be done through a server-side script.
|

which is the case, btw. (Reason for this decision was to avoid
cross-domain problems, iirc. Scripts reside on different domains but
on same machine.)

|It is generally a bad idea to use Prototype.js, though.

Because... ?

Everyone here agrees to PointedEars?



*************

Marty - it's perfect! You're just not thinking fourth dimensionally!
[Emmett "Doc" Brown]

If you wish to email me, please use newsreply at wuwei minus webservices dot de

 

[Gregor Kofler]

Daniel Breitner meinte:

|It is generally a bad idea to use Prototype.js, though.

Because... ?

Search this group. Has been discussed more than once.

Everyone here agrees to PointedEars?

The majority.

*************
[snip]

Please use a correct sig separator.

Gregor

 

[Thomas 'PointedEars' Lahn]

Thomas 'PointedEars' Lahn wrote:
| Of course, it makes maintenance harder, so if
|that approach is followed it should be done through a server-side script.

The `|' character should be reserved for quotations from third-party sources
(like documentation). Use `>' for in-thread quotations.

which is the case, btw. (Reason for this decision was to avoid
cross-domain problems, iirc. Scripts reside on different domains but
on same machine.)

There are no cross-domain problems with script resources, though; you may
include scripts from different domains (as you may include images from
different domains), the SOP does not apply here as it is about documents.

|It is generally a bad idea to use Prototype.js, though.

Because... ?

See my sig (not so random this time).

Everyone here agrees to PointedEars?

Probably not everyone, but many.

*************

Marty - it's perfect! You're just not thinking fourth dimensionally!
[Emmett "Doc" Brown]

I like that quote (one of my favorites), but I would like it better in a
properly delimited signature (so that it would be recognized as such). Use
dash-dash-space-newline instead of asterisks-newline, and keep your
signature to 4 lines (not counting the delimiter).

If you wish to email me, please use newsreply at wuwei minus webservices dot de

If you wish to participate in Usenet, learn about the rules that apply here.
Home-improvement-like descriptions on how to reach you are not included.
Use the Reply-To header, but make sure that the From header of your posting
also specifies a mailbox (see RFCs 1036 and 2822).


PointedEars

 

[Dr J R Stockton]

In comp.lang.javascript message <[email protected]>, Tue,

The `|' character should be reserved for quotations from third-party sources
(like documentation). Use `>' for in-thread quotations.

In which current RFC is that use of "|" to be found?

I like that quote (one of my favorites), but I would like it better in a
properly delimited signature (so that it would be recognized as such). Use
dash-dash-space-newline instead of asterisks-newline, and keep your
signature to 4 lines (not counting the delimiter).

With which current RFC are your sigs compliant?

If you wish to participate in Usenet, learn about the rules that apply here.
Home-improvement-like descriptions on how to reach you are not included.
Use the Reply-To header, but make sure that the From header of your posting
also specifies a mailbox (see RFCs 1036 and 2822).

And also, Daniel, learn to disregard chronic control-freakery; Usenet
attracts certain of the psychologically disturbed.

 

[Garrett Smith]

[...] And it's generally a bad idea to include scripts inline.

Nonsense. "Embedding scripts inline" avoids the overhead created by
additional HTTP requests. (...)

... and precludes the benefits of caching.

Just what I was thinking.

Inline scripts are useful for dynamically generated server values that
don't fit semantic meaning of the page.

Garrett

 

[Thomas 'PointedEars' Lahn]

Matthias Reuter wrote:
[...] And it's generally a bad idea to include scripts inline.
Nonsense. "Embedding scripts inline" avoids the overhead created by
additional HTTP requests. (...)

... and precludes the benefits of caching.

Rubbish.

Just what I was thinking.

Think again.


PointedEars

 

[Garrett Smith]

On Jul 24, 2:00 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
Matthias Reuter wrote:
[...] And it's generally a bad idea to include scripts inline.
Nonsense. "Embedding scripts inline" avoids the overhead created by
additional HTTP requests. (...)
... and precludes the benefits of caching.

Rubbish.

Just what I was thinking.

Think again.

Assuming a real application, not a static HTML file.

 

[Thomas 'PointedEars' Lahn]

Jorge wrote:
On Jul 24, 2:00 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
Matthias Reuter wrote:
[...] And it's generally a bad idea to include scripts inline.
Nonsense. "Embedding scripts inline" avoids the overhead created by
additional HTTP requests. (...)
... and precludes the benefits of caching. Rubbish.

Just what I was thinking.

Think again.

Assuming a real application, not a static HTML file.

So what? It does _not_ "preclude the benefits of caching" in any case.


PointedEars

 

[Jorge]

Garrett Smith wrote:
Jorge wrote:
On Jul 24, 2:00 pm, Thomas 'PointedEars' Lahn <[email protected]>
wrote:
Matthias Reuter wrote:
[...] And it's generally a bad idea to include scripts inline.
Nonsense.  "Embedding scripts inline" avoids the overhead createdby
additional HTTP requests.  (...)
... and precludes the benefits of caching.
Rubbish.
Just what I was thinking.
Think again.

Assuming a real application, not a static HTML file.

So what?  It does _not_ "preclude the benefits of caching" in any case.

Of course it does. If you embed the same <script> in 3 separate .htmls
it gets downloaded 3 times. If, instead, you embed <script
src="xxx.js"> in 3 separate .htmls, it gets downloaded just *once*.

 

[Evertjan.]

Jorge wrote on 30 jul 2009 in comp.lang.javascript:

Of course it does. If you embed the same <script> in 3 separate .htmls
it gets downloaded 3 times. If, instead, you embed <script
src="xxx.js"> in 3 separate .htmls, it gets downloaded just *once*.

So what, if the page has an [yes, cachable but moreoften new] image of
150kB and a js of 10kB?

The overhead of seperate loading of that extra file could be far more time
and cpu ticks consuming than the inclusion.

<script type='text/javascript'>
<!--#include file ="myJs.js"-->
</script>

vs:

<script type='text/javascript' src='myJs.js'></script>

I prefer the first one! [given that you have serverside includes]

========

The caching of js files in the debugging fase is a pain in the neck.

 

[Mike Duffy]

The caching of js files in the debugging fase is a pain in the neck.

For js debugging, I usually configure FF to clear its cache on exit without
asking, and set up its home page to be the one I am currently debugging.

If you need to test IE, you need to explicitly clear the cache, and I do it
via a batch file that uses DEL, COPY, etc. commands in a CMD file to
restore the cache to an "empty" state. It can also include a "START"
command to run IE after.

 

[Evertjan.]

Mike Duffy wrote on 31 jul 2009 in comp.lang.javascript:

For js debugging, I usually configure FF to clear its cache on exit
without asking, and set up its home page to be the one I am currently
debugging.

If you need to test IE,

Much to my distaste, it usually is.

you need to explicitly clear the cache, and I
do it via a batch file that uses DEL, COPY, etc. commands in a CMD
file to restore the cache to an "empty" state. It can also include a
"START" command to run IE after.

Indeed, and all these extreme measures are not necessary by including the
js in the primary html file.

<script type='text/javascript'>
<!--#include file ="myJs.js"-->
</script>

 

[Jorge]

For js debugging, I usually configure FF to clear its cache on exit without
asking, and set up its home page to be the one I am currently debugging.

If you need to test IE, you need to explicitly clear the cache, and I do it
via a batch file that uses DEL, COPY, etc. commands in a CMD file to
restore the cache to an "empty" state. It can also include a "START"
command to run IE after.

In my Mac, just typing command-option-e empties the caches... then
command-r to reload.

 

[Mike Duffy]

Mike Duffy wrote on 31 jul 2009 in comp.lang.javascript:

.... extreme measures are not necessary by including the js

<script type='text/javascript'>
<!--#include file ="myJs.js"-->
</script>

I asked my ISP for SSI. The response was basically that my question was not
on the list of those for which they had perpared an answer.

Their clients are mostly residential "amateurs" like myself who sign up for
their broad band service (via the TV cable), and the web page hosting
service they provide is primarily just so that they can legally advertise
that they provide such a service. It is subcontracted to a subsidiary and
consists of a limited (5 Meg) space with no possibility of talking to
someone who knows more than how to reset your password.

Once I sent them a $0.01 piece to pay for my share to double our disk
quotas, but they did not find it amusing. They simply reminded me that the
fine print in the contract says they can suspend this service without
notice at any time when it becomes "in their best interests".