IWETHEY v. 0.3.0 | TODO
1,095 registered users | 1 active user | 0 LpH | Statistics
Login | Create New User
IWETHEY Banner

Welcome to IWETHEY!

New Getting the owning window of an HTMLElement?
Heya, using Javascript. Woo.

Let's say I have a DOM object... an HTMLElement.

I can get the owning Document with the owningDocument property, but how do I get the Frame or Window that owns that document?
Regards,

-scott anderson
New *sigh*
Heya, using Javascript. Woo.

Really moving up in the world, eh? Well..I guess it pays the rent, but...

:)
Jay O'Connor

"Going places unmapped
to do things unplanned
to people unsuspecting"
New You're a lot of help. ;-)
Actually, I'm finding that Javscript isn't that bad. It's a lot like Python in some ways; you can add and remove methods from class definitions on the fly, for example. This is v. 1.4+, of course.

With that and the DOM, it's actually fairly rational.
Regards,

-scott anderson
New thanks!
"Friends don't let friends code Javascript"

I used Javascript whenI was with Zelerate and it's abhorant, even if I knew the answer, I probably wouldn't tell you :)

Actually, I'm finding that Javscript isn't that bad.

Wait 'til you got to the fun opf autocasting between strings and numbers :)

It's a lot like Python in some ways;

I'm only mildy liking Python as it is...no points for that :)
Jay O'Connor

"Going places unmapped
to do things unplanned
to people unsuspecting"
New Re: thanks!
Autocasting I can deal with.

"I only mildly like Python"

Yeah, yeah, I knew you'd say that. Would you rather be programming in Perl? I wouldn't. :-)
Regards,

-scott anderson
New Re: thanks!
Yeah, yeah, I knew you'd say that.

Really? I thought the last impression I gave was that I thought Python was really cool....


Would you rather be programming in Perl? I wouldn't. :-)

Been there, don't that. Ugh! :)
Jay O'Connor

"Going places unmapped
to do things unplanned
to people unsuspecting"
New Last impression
Basically, the last impression you gave was that you were completely down on any file-based product, and Python particularly because it was good enough to be frustrating that it wasn't as powerful as Smalltalk.
Regards,

-scott anderson
New Ahh....forgot that
Basically, the last impression you gave was that you were completely down on any file-based product,

A year with text editors (including Emacs) and CVS has strengthened my feelings in that direction

Python particularly because it was good enough to be frustrating that it wasn't as powerful as Smalltalk.

Python now frustrates me because I see it as being just more of the same, and making the same mistakes many other languages have made. It's still pretty immature, but as it's trying to grow up, it's doing so in the wrong direction. It's not learning from other's past mistakes.

I use it a lot at home (most of my check balancing/money management is done with a set of Python modules and scripts I put together), but it's not something I see as being ready for big application development yet. (Which, coincidentally, is my job :)
Jay O'Connor

"Going places unmapped
to do things unplanned
to people unsuspecting"
New Have you considered telling people?
The Python developers, in particular?

They might be receptive to your ideas.
Regards,

-scott anderson
New Are you kidding?
After the comp.lang.python flame fest over what type the result of "/" shold be and some of the other recent exchanges, the last thing I think I want to do is go suggest that the fundmental thinking that leads to iterators and list comprehnsions is misguided
Jay O'Connor

"Going places unmapped
to do things unplanned
to people unsuspecting"
New Well...
... then don't complain when the thinking doesn't change.
Regards,

-scott anderson
New Excuse me?
Yes I would rather be programming in Perl. OK, I like Perl. I would rather be programming in Python. Oh, you like Python. Well I would rather be coding in VB, PL/SQL, or even go and learn COBOL. All are preferable to JavaScript.

As for the autocasting in JavaScript, trust me. It is a bad mistake.

The basic rule is that variables are untyped, and every function and operator will enforce that by casting arguments between strings and numbers for you. If there are multiple arguments, it will cast depending on what the arguments are. But the operators are also untyped, so you need to guess by some rules. However different operators use different and distinctly incompatible sets of rules for autocasting.

Add in different browser behaviour, and you have a recipe for a nightmare.

I will let you discover the joys of getting event handling to work properly. Suffice it to say that IE uses a bottom-up model (the most specific element gets the even first) while Netscape uses a top-down model (the outermost container gets first shot at the event). The fun quickly progresses from there...

And it isn't just me. The following quote [link|http://www.crynwr.com/cgi-bin/ezmlm-cgi?mss:5054:200008:bccjlknabhieegbnegof|from Kragen Sitaker] may give you a sense of what you are getting into:

I'd rather write bare-metal programs in 8086 machine code in DEBUG.COM. I'd rather edit programs in the Bourne shell on a machine whose only output was a speaker. I'd rather write Perl on my 2.5"x1.5" pager's two-thumb QWERTY keyboard and mail it to myself for remote batch execution.

I have done all of these, in fact.

They are all easier and more fun than writing portable JavaScript code.


Cheers,
Ben
New Well, they're wrong.
I wrote this stuff in a day (complete with unit testing). The application scans a page for updatable elements. It receives updates from a back-end process and automatically updates the page elements with the new data. All the HTML coder needs to know is a few attributes to tag an updatable element with. Everything else is handled. They can choose text, number, or script call as update types.

And it runs perfectly well in both Mozilla and IE. Pre-DOM browsers, yes, there are tons of compatibility issues. Not so with the stuff I'm working with. This type of dynamic application is exactly what the DOM and Javascript were designed for.

I'm not using browser events with this application. And I'm perfectly aware of the different event propagation models (and how you get around those different models). Those issues simply do not come into play with what I am doing.

The alternative was a Java applet and HTTP tunneling, both of which leave much more to be desired for various reasons than does a Javascript solution for this application.

I suspect that you are simply willing to completely disregard my comments without giving me the courtesy of the consideration that an expert developer like myself deserves, as opposed to asking why first.
Regards,

-scott anderson
New Everything has its place
Use the right tool for the job and all that.

There are definitely times when JavaScript is the right tool for the job. It tends to be the right tool more often for simple things and things that only need to be used in tightly controlled environments. It sounds like it is the right tool for your job.

Somehow I am not surprised. As you say, you are very competent.

But even so for general purpose programming (particularly, though not only, in a mixed environment) JavaScript reaches the end of its rope well before a decent programmer reaches the end of their ability to tell it things it should be able to do. For instance in your application if you are running JavaScript simultaneously from within multiple frames (you did mention frames) and they interact, you will have race conditions and aperiodic crashes. There is no support in the language for getting around these races. To me that makes JavaScript a seriously broken tool.

Which is why I agree with Jay's quote that friends don't let friends program in JavaScript.

Cheers,
Ben
New Your horse is getting taller by the minute.
But even so for general purpose programming (particularly, though not only, in a mixed environment) JavaScript reaches the end of its rope well before a decent programmer reaches the end of their ability to tell it things it should be able to do. For instance in your application if you are running JavaScript simultaneously from within multiple frames (you did mention frames) and they interact, you will have race conditions and aperiodic crashes. There is no support in the language for getting around these races. To me that makes JavaScript a seriously broken tool.


Sorry to descend into analogy, here, but that's like saying the tire iron is a seriously broken tool because you can't manufacture an entire Audi out of it. We are in the scripting forum, are we not? Nobody's talking about using Javascript for "general purpose programming" (which appears to be your euphemism for Big Projects) except you. JS is a small, client-side tool for use in web-based applications, and in that environment, has no real substitute. Nobody is trying to tell you to build your business on it, and certainly not on it alone.

Which is why I agree with Jay's quote that friends don't let friends program in JavaScript.


Uhhh... yeah. Scott, you're my friend, and you have my permission to continue using Javascript where needed.

Oh, and good to have you back, Ben. Don't recall if I've had a chance to say that yet or not. :)
That's her, officer! That's the woman that programmed me for evil!
New What is a scripting language?
To me a scripting language is a language which is explicitly intended to make it easy to put together small but very useful programs. For instance in Perl:
perl -MLWP::Simple -e 'getprint("[link|http://z.iwethey.org/")'|http://z.iwethey.org/")']

is a complete working program that does something useful.

On the surface this has absolutely nothing to do with what we think of as "real programming". However if you look at popular scripting language after popular scripting language, you will find some sort of support for real programming techniques in most of the successful ones.

Why?

Well quite simple, really. We live in a world where you need complex interactions with the outside world for common tasks. To successfully script those common tasks you need access to a convenient interface which allows you to simply say what you want done. Those interfaces can be built into the language, built into additional libraries written in the language, or can be interfaced from other languages. (That order is in what I believe to be descending order of convenience to the user.)

Unfortunately a language can reasonably contain only so much functionality. Certainly far less than what users want, and it is guaranteed to omit things that will be considered important in a few years. Therefore successful scripting languages emphasize extensibility. Either the ability to extend the language from within the language, or from external interfaces. (Or both.) For instance the above program is only simple because I loaded an external library that itself loaded a series of libraries which did a lot of work on my behalf.

However JavaScript has a poor story to tell on extensibility either from within or outside of the language. If you want to do what it does on the client side, you have no real choice but to use it. But as far as scripting languages go, it is not very good.

Some of that is not its fault. It is inherent in the problems of a client-side language. However some of it could be done much better. My theory as to the real problem is simply that you don't get client-side choice. If you had many competing client-side languages, then the best would win and ones with some of the horrible mistakes that JavaScript makes would go away. But the barriers to becoming a widely used client-side language are so high that JavaScript is likely to remain widely used for the indefinite future. No matter what its faults are.

Cheers,
Ben
New Good and bad scripting.
I think we - as in, us in IWETHEY - are expecting perhaps a little too much from the term "scripting language". DOS Batch files are a scripting language. Not very powerful, true, but they script the running of several programs one after the other, with some logic direction. WordBASIC (as used in Word 2) is a scripting language. Not spectacular, I'll admit, but it easily replaces long key sequences and has some decent if not fantastic logic control. Perl, OTOH, is a scripting language on steroids. Is there anything it can't do? Of course, that is it's attraction.

Wade.

"All around me are nothing but fakes
Come with me on the biggest fake of all!"

New Unix scripting...
To my way of thinking, Perl is an amalgamation of scripting languages - shell, awk, grep, and sed come to mind, with a lot of C syntax thrown in for good measure. If you use Perl for a number of other things, you don't have to drop into these lower level scripting languages, though it certainly helps to be fluent in them as well.
New That is partly how it was designed
It has been said that, Perl is the Cliff-notes of Unix.

Intentionally so. What Larry Wall did is take a lot of useful things from Unix and tried to put them into one package, with somewhat tighter integration. (For instance Unix pipelines are list-oriented with lists being designated as lines. Perl is list-oriented with lists being scalars.)

Larry Wall will be the first to tell you that he isn't very original. But he is a great integrator. And personally I would say that whether you like or dislike Perl, you have to admit that he changed the face of scripting languages...

Cheers,
Ben
New would scripting languages be anything with an interpreter?
as opposed to a standalone compiled executable? If a file may be run natively it is a program. If a file must call an interpreter it is a script.
Scripting languages
Perl
Basic
xbase
C#
compiled programs
c++
pascal
forth
assembler
not to say simplicity and power as well as ease of use is granted to either class
thanx,
bill
Our bureaucracy and our laws have turned the world into a clean, safe work camp. We are raising a nation of slaves.
Chuck Palahniuk
New Yup, IMO. Oh, and you forgot one: Java.
New Not necessarily.
Most BASIC interpreters actually execute a sort of p-code version of the program. Even Visual BASIC did that until quite recently. Those found in home computers of the '80s actually wrote a tokenised version into memory, which it translated as you entered lines. OTOH, BASIC compilers have been around a long time, too. So.

In fact, the line is blurry: Perl is translated into an internal p-code version before it executes it. This is much like what happens with virtual machine languages like Java and Icon, but without the explicit step of "compiling" (Icon's "compiler" is actually called a translator, incidentally). Interestingly, SNOBOL functions like Perl, with an implicit translation prior to execution.

Wade.

"All around me are nothing but fakes
Come with me on the biggest fake of all!"

New I wouldn't draw the line there
And even if you did you would have various cases on the boundary.

For instance Forth and Pascal both have had incarnations as interpreted languages.

Python and Lisp are examples of languages which are often run both as interpreted languages and as compiled programs.

As I said, I would draw the line at the point that a scripting language is one which has as a significant design consideration that it should be possible to write useful programs with very little code. Of course that doesn't make that the only design consideration for the language, and it doesn't mean that such languages are only useful for short programs...

Cheers,
Ben
New Try '.parent'
I won't swear to any consistency of implementation, or how it works on different elements. But it should work in some cases. Don't you love the confidence I place in JavaScript?
This is my sig. There are many like it, but this one is mine.
New Nope.
That just gives the parent DOM element. I need the Frame or Window, which isn't represented in the DOM other than as the owning Document. I need a Javascript-specific method on it though, and the DOM object doesn't have it.

What I'm trying to do is call a script in the owning window of a particular DOM element. The calling script is in the root context, so it doesn't know anything in the Frame scope. Window has execScript() on it, but I can't get the Window object given the HTMLElement object.
Regards,

-scott anderson
New Either call from the element itself or pass params
Ideas:

1) How does the root script know which element it is? Pass the window object in the same argument list.

2) Use the trappable events system to call the (for example) onClick event of the element.

3) Otherwise, you have to make the call from the element itself.

Wanna post pseudocode? I work in client-side JS a lot (with frames), you can email me if you want: ts under_score eliot at pacbell.net
That's her, officer! That's the woman that programmed me for evil!
New I passed params.
I'm traversing the entire window, and picking out elements with certain attributes. I fixed my problem by passing the beginning window into the (recursive) traversal function, and setting it on the element placeholder when I get one I want to keep.
Regards,

-scott anderson
New My stuff's not in front of me...
...I vaguely recall having been down that road before. It's possible to get the enclosing window. What is regulated though, is the ability of one frame to call a function in another frame - some security issues get involved.

Anyhow, if you haven't found it by then, I'll try to look it up.
New We own all of the frames.
So security shouldn't be an issue.

If you can find your code that gets the enclosing window and let me know, I'd appreciate it. The method I'm using now (passing the window as a parm) works, but it's a bit inelegant.
Regards,

-scott anderson
New hmmm...
Found some really old stuff for Navigator 3, but it just set up a frame level property that was stored as the page was being created.

Don't know if this is what you are aiming at, but here's a stab:

main.html
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "[link|http://www.w3.org/TR/html4/frameset.dtd|http://www.w3.org/T...frameset.dtd]">
<html>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=ISO-8859-1' />
<title>Main</title>
<script language='JavaScript' type='text/javascript'>
function justForGrins(myparam) {
alert(myparam);
}
</script>
</head>
<frameset border="3" rows="50%,*">
<frame src="framea.html" name="bodya"
frameborder="1" marginheight="80" marginwidth="120" />
<frame src="frameb.html" name="bodyb"
frameborder="1" marginheight="80" marginwidth="120" />
</frameset>
</html>


framea.html
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=ISO-8859-1' />
<title>Frame A</title>
<script language='JavaScript' type='text/javascript'>
function tryThis(obj) {
obj.document.frames.parent.justForGrins("fred was here");
alert(obj.document.frames.parent.window);
}
</script>
</head>
<body>
Frame A Contents
<form name='myform' action='framea.html'>
<input name='fred' type='button' value='say' onclick='tryThis(this);' />
</form>
</body>
</html>


frameb.html
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=ISO-8859-1' />
<title>Frame B</title>
</head>
<body>
Frame B Contents
</body>
</html>


New No dice.
Apparently when you walk the DOM to get to an object, it's not the same object as the one referred to by "this".

I just get "node.document has no properties".
Regards,

-scott anderson
New Non standard
Not sure if there is a standard way to get there, but here's a non-standard technique that works with ie & ns differences built into the code. The dump routine just dumps all the properties and methods so I could try to track my way throw the collections (thought it might be useful).

<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
<html>
<head>
<meta http-equiv='Content-Type' content='text/html; charset=ISO-8859-1' />
<title>Frame A</title>
<script language='JavaScript' type='text/javascript'>
function tryThis(node) {
if (node.document) {
node.document.frames.parent.justForGrins("Internet Exploder");
alert(node.document.frames.parent.window);
} else if (node.ownerDocument) {
node.ownerDocument.defaultView.parent.justForGrins("NetScrape");
alert(node.ownerDocument.defaultView.parent.window);
} else {
alert("SOL");
}
}

function dump(myObj) {
if (myObj == null) {
document.write("null<br>");
} else {
document.write("<table border=\\"3\\">");
document.write("<tr><th>Property</th><th>Value</th><th>Type</th></tr>");
for (var i in myObj) {
document.write("<tr>");
document.write("<td width=\\"200\\">" + i);
document.write("<td width=\\"200\\">");
if (myObj[i] != null) {
if (typeof(myObj[i]) == "string") {
document.write("\\"" + myObj[i] + "\\"");
} else {
document.write(myObj[i]);
}
} else {
document.write("null");
}
document.write("<td width=\\"100\\">" + typeof(myObj[i]));
}
document.write("</table>");
}
document.write("<br>");
}
</script>
</head>
<body>
Frame A Contents
<form name='myform' action='framea.html'>
<input name='fred' type='button' value='say' onclick='tryThis(this);' />
</form>
<script language='JavaScript' type='text/javascript'>
var node = document.getElementsByName("fred").item(0);
dump(node);

if (node.document) {
dump(node.document.frames.parent);
} else {
dump(node.ownerDocument.defaultView.parent);
}
</script>
</body>
</html>
New Yes, that seems to work.
But since I've already written by passing the Window object along during traversal, and this would be the first browser-specific code I'd have had to add, I think I'll stick with what I've got.

Thanks.
Regards,

-scott anderson
New Natch
Figured as much, but just wanted to complete the thought. :-)

Looks like the defaultView property may become a w3c standard sometime down the road. One thing that stuck out, though, is that I couldn't find the ownerDocument property in IE5.5 and that is part of the core DOM standard. And Opera JavaScript still seems to be lagging.

I gather y'all are standardizing on the latest builds of Mozilla. Out of curiosity, what IE version are they using? I still have some apps that have to go back to navigator 2.x and ie 3.x, though I'm not sure anybody is still out there using them.
New Still some problems with DOM in IE 5.5
NOt nearly as bad as the incompatibility problems of the past, but still annoying.

IE treats element attributes completely differently than Mozilla. Mozilla uses the W3C method of treating attributes as child nodes of the element; IE treats the attributes as a mapping on the element.
Regards,

-scott anderson
New "All your frame are belong to us"?
sorry...haven't had my fix in a few weeks. Needed a quick hit of AYBABTU
Jay O'Connor

"Going places unmapped
to do things unplanned
to people unsuspecting"
     Getting the owning window of an HTMLElement? - (admin) - (35)
         *sigh* - (Fearless Freep) - (21)
             You're a lot of help. ;-) - (admin) - (20)
                 thanks! - (Fearless Freep) - (19)
                     Re: thanks! - (admin) - (18)
                         Re: thanks! - (Fearless Freep) - (5)
                             Last impression - (admin) - (4)
                                 Ahh....forgot that - (Fearless Freep) - (3)
                                     Have you considered telling people? - (admin) - (2)
                                         Are you kidding? - (Fearless Freep) - (1)
                                             Well... - (admin)
                         Excuse me? - (ben_tilly) - (11)
                             Well, they're wrong. - (admin) - (10)
                                 Everything has its place - (ben_tilly) - (9)
                                     Your horse is getting taller by the minute. - (tseliot) - (8)
                                         What is a scripting language? - (ben_tilly) - (7)
                                             Good and bad scripting. - (static) - (2)
                                                 Unix scripting... - (ChrisR) - (1)
                                                     That is partly how it was designed - (ben_tilly)
                                             would scripting languages be anything with an interpreter? - (boxley) - (3)
                                                 Yup, IMO. Oh, and you forgot one: Java. -NT - (CRConrad)
                                                 Not necessarily. - (static)
                                                 I wouldn't draw the line there - (ben_tilly)
         Try '.parent' - (drewk) - (12)
             Nope. - (admin) - (11)
                 Either call from the element itself or pass params - (tseliot) - (1)
                     I passed params. - (admin)
                 My stuff's not in front of me... - (ChrisR) - (8)
                     We own all of the frames. - (admin) - (7)
                         hmmm... - (ChrisR) - (5)
                             No dice. - (admin) - (4)
                                 Non standard - (ChrisR) - (3)
                                     Yes, that seems to work. - (admin) - (2)
                                         Natch - (ChrisR) - (1)
                                             Still some problems with DOM in IE 5.5 - (admin)
                         "All your frame are belong to us"? - (Fearless Freep)

Powered by my Gramma!
283 ms