From Sarabjot_Nannar at infosys.com Fri Aug 7 01:42:19 2009 From: Sarabjot_Nannar at infosys.com (Sarabjot Singh Nannar) Date: Fri, 7 Aug 2009 12:12:19 +0530 Subject: [Javascript] access child windows Message-ID: Hi, Here is the scenario I have: I have one parent window and this window is popping up messaging windows based on a timer using window.open(). Now my problem is to access these windows from parent window for pasting messages in it and closing them. I saw one article at: http://lists.evolt.org/pipermail/javascript/2005-December/009868.html but this doesn't seem to help as it throws an error when accessing the array. Can anybody help on this? Regards, Sarab From trojani2000 at hotmail.com Fri Aug 7 03:37:53 2009 From: trojani2000 at hotmail.com (Troy III Ajnej) Date: Fri, 7 Aug 2009 08:37:53 +0000 Subject: [Javascript] access child windows In-Reply-To: References: Message-ID: Why dont you drop pop-ups completely, and pop-up a styled DIV instead, since more than 80% of pop-ups are being blocked anyway. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Troy III progressive art enterprise ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > From: Sarabjot_Nannar at infosys.com > To: javascript at lists.evolt.org > Date: Fri, 7 Aug 2009 12:12:19 +0530 > Subject: [Javascript] access child windows > > Hi, > > Here is the scenario I have: > > I have one parent window and this window is popping up messaging windows based on a timer using window.open(). > Now my problem is to access these windows from parent window for pasting messages in it and closing them. I saw one article at: > > http://lists.evolt.org/pipermail/javascript/2005-December/009868.html > > > but this doesn't seem to help as it throws an error when accessing the array. > > Can anybody help on this? > > Regards, > Sarab > > _______________________________________________ > Javascript mailing list > Javascript at lists.evolt.org > http://lists.evolt.org/mailman/listinfo/javascript _________________________________________________________________ Get your vacation photos on your phone! http://windowsliveformobile.com/en-us/photos/default.aspx?&OCID=0809TL-HM From paul at juniperwebcraft.com Fri Aug 7 14:33:14 2009 From: paul at juniperwebcraft.com (Paul Novitski) Date: Fri, 07 Aug 2009 12:33:14 -0700 Subject: [Javascript] access child windows In-Reply-To: <11782857.1249630713144.JavaMail.root@n13> References: <11782857.1249630713144.JavaMail.root@n13> Message-ID: At 8/6/2009 11:42 PM, Sarabjot Singh Nannar wrote: >I have one parent window and this window is popping up messaging >windows based on a timer using window.open(). >Now my problem is to access these windows from parent window for >pasting messages in it and closing them. I saw one article at: > >http://lists.evolt.org/pipermail/javascript/2005-December/009868.html > > >but this doesn't seem to help as it throws an error when accessing the array. As to your technical question, the window.open() method returns a value that represents the child window that's been opened: var oChildWindow = window.open(); oChildWindow.close(); If you need to create more than one child window, you can keep each instance separate, for example in an array: var aChildWindows = new Array(); ... // create a new window aChildWindows[aChildWindows.length] = window.open(); // create another separate new window aChildWindows[aChildWindows.length] = window.open(); // close all for (var i = 0; i < aChildWindows.length; i++) { aChildWindows[i].close(); } The expression arrayName[arrayName.length] points to a new, as-yet-uncreated item in the array. However, I'd like to criticize your strategy. First, Troy is right that many people run with pop-ups blocked, a pop-up window being a window created by a script without explicitly being asked by the human user. Don't use a technique for communicating important messages to the user that some users won't see. If the error results from an action that can only be taken when JavaScript is running, using JavaScript to display an error message is appropriate. However, if the problem situation is one that anyone can run into even if they're not running JavaScript, then using JavaScript to communicate with them is fundamentally flawed. Consider writing your application to take place entirely between a server-side script and the user, and then add JavaScript to enhance the experience for those with scripting enabled. (Google 'progressive enhancement' for more on this topic.) Second, a web page that creates an unceasing series of pop-up windows sounds so irritating that I would personally avoid using the website at all. If you must use a pop-up, why not continue to use the same one with repeat messages? Third, creating new windows without warning and without the cooperation of the user can really frustrate users of assistive technology such as screen readers. When a new window appears, suddenly the page changes without their having clicked on a link and the Back button is "broken" because it can't take them back where they'd been. This is a very poor usability & accessibility scenario. Don't do it. I think your best bet is to a) use something like an alert() dialog or as Troy suggests a CSS div, b) re-use the same dialog instead of creating new ones, c) make sure that all of your users can read the message, and d) make sure that all of your users know how to make the message go away to return them to the page at hand. Regards, Paul __________________________ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com From dwayne.conyers at hp.com Mon Aug 10 16:40:43 2009 From: dwayne.conyers at hp.com (Conyers, Dwayne) Date: Mon, 10 Aug 2009 21:40:43 +0000 Subject: [Javascript] access child windows In-Reply-To: References: Message-ID: <769907F0D19EFA45BD6F04FC6E896D6D1F16C1C7D0@GVW0538EXC.americas.hpqcorp.net> Troy III Ajnej post toasted: > Why dont you drop pop-ups completely, and pop-up a styled DIV instead, > since more than 80% of pop-ups are being blocked anyway. The OverLib JS (http://www.bosrup.com/web/overlib) library is good for styled pop-ups. There are a few side-sites with add-ons and extensions to Eric's API... and I have also seen some OverLib copies that seem to simplify the code-base to give the same basic functionality without the "bloat" -- but even a D.I.Y. pop-up div is a good option. A different option might be to use an alert() to pop-up a modal window that the user would have to click to dismiss... or perhaps use similar coding to add some interactivity? One final option (more labor intensive) would be to exploit the capabilities of specific browsers to manage a pop-up... not quite a "hack" like some advertisers user to override the popup blocker, but to legitimately open that window. -- I made magic once. Now, the sofa is gone. http://blog.dwacon.com http://www.twitter.com/dwacon From trojani2000 at hotmail.com Tue Aug 11 21:29:56 2009 From: trojani2000 at hotmail.com (Troy III Ajnej) Date: Wed, 12 Aug 2009 02:29:56 +0000 Subject: [Javascript] access child windows In-Reply-To: <769907F0D19EFA45BD6F04FC6E896D6D1F16C1C7D0@GVW0538EXC.americas.hpqcorp.net> References: <769907F0D19EFA45BD6F04FC6E896D6D1F16C1C7D0@GVW0538EXC.americas.hpqcorp.net> Message-ID: Nice joke! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Troy III progressive art enterprise ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Troy III Ajnej post toasted: > > > Why dont you drop pop-ups completely, and pop-up a styled DIV instead, > > since more than 80% of pop-ups are being blocked anyway. > > The OverLib JS (http://www.bosrup.com/web/overlib) library is good for styled pop-ups. There are a few side-sites with add-ons and extensions to Eric's API... and I have also seen some OverLib copies that seem to simplify the code-base to give the same basic functionality without the "bloat" -- but even a D.I.Y. pop-up div is a good option. > > A different option might be to use an alert() to pop-up a modal window that the user would have to click to dismiss... or perhaps use similar coding to add some interactivity? > > One final option (more labor intensive) would be to exploit the capabilities of specific browsers to manage a pop-up... not quite a "hack" like some advertisers user to override the popup blocker, but to legitimately open that window. > > > -- > I made magic once. Now, the sofa is gone. > http://blog.dwacon.com > http://www.twitter.com/dwacon > > > > > > > > > > > _______________________________________________ > Javascript mailing list > Javascript at lists.evolt.org > http://lists.evolt.org/mailman/listinfo/javascript _________________________________________________________________ Get free photo software from Windows Live http://www.windowslive.com/online/photos?ocid=PID23393::T:WLMTAGL:ON:WL:en-US:SI_PH_software:082009 From paul at juniperwebcraft.com Thu Aug 20 13:05:24 2009 From: paul at juniperwebcraft.com (Paul Novitski) Date: Thu, 20 Aug 2009 11:05:24 -0700 Subject: [Javascript] defining functions before they're called Message-ID: Can you think of a reason why one shouldn't call a function before it's declared in the source code? For example: window.onload = initialize; function initialize() { ... } I can certainly understand why one might choose, stylistically, to always define functions before calling them. However, I have never experienced any problem using JavaScript by putting the call before the function being called. It's my personal preference to put the call first because I like to read scripts top-down, seeing how a function is used before reading the details of exactly what the function does. But I'm curious to know if any of you has ever encountered a problem doing so. Regards, Paul __________________________ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com From peter at brunone.com Thu Aug 20 13:53:03 2009 From: peter at brunone.com (Peter Brunone) Date: Thu, 20 Aug 2009 11:53:03 -0700 Subject: [Javascript] defining functions before they're called Message-ID: <6d56f114$6cfc1ee7$640005be$@com> Hi Paul, In the code below, you are not calling the function before it is defined. You're simply assigning a pointer to it from an event handler; this event won't fire before the function is loaded, so you should never see a problem. However, if your code looked like this: initialize(); function initialize() { ... } ...then I'd be willing to bet five bucks that you'll find a JavaScript error at run time. Cheers, Peter ---------------------------------------- From: "Paul Novitski" Sent: Thursday, August 20, 2009 1:38 PM To: "JavaScript List" Subject: [Javascript] defining functions before they're called Can you think of a reason why one shouldn't call a function before it's declared in the source code? For example: window.onload = initialize; function initialize() { ... } I can certainly understand why one might choose, stylistically, to always define functions before calling them. However, I have never experienced any problem using JavaScript by putting the call before the function being called. It's my personal preference to put the call first because I like to read scripts top-down, seeing how a function is used before reading the details of exactly what the function does. But I'm curious to know if any of you has ever encountered a problem doing so. Regards, Paul __________________________ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com _______________________________________________ Javascript mailing list Javascript at lists.evolt.org http://lists.evolt.org/mailman/listinfo/javascript From john at jwarner.com Thu Aug 20 13:54:21 2009 From: john at jwarner.com (John Warner) Date: Thu, 20 Aug 2009 14:54:21 -0400 Subject: [Javascript] defining functions before they're called In-Reply-To: References: Message-ID: <01b001ca21c7$a0e98ef0$e2bcacd0$@com> You can run into a problem if the browser has not yet loaded or 'processed' that portion of the page that contains your function. Aside from that I think it is a matter of what you prefer and think most readable and maintainable John Warner > -----Original Message----- > From: javascript-bounces at lists.evolt.org [mailto:javascript- > bounces at lists.evolt.org] On Behalf Of Paul Novitski > Sent: Thursday, August 20, 2009 2:05 PM > To: JavaScript List > Subject: [Javascript] defining functions before they're called > > Can you think of a reason why one shouldn't call a function before > it's declared in the source code? For example: > > window.onload = initialize; > > function initialize() > { > ... > } > > I can certainly understand why one might choose, stylistically, to > always define functions before calling them. However, I have never > experienced any problem using JavaScript by putting the call before > the function being called. It's my personal preference to put the > call first because I like to read scripts top-down, seeing how a > function is used before reading the details of exactly what the > function does. But I'm curious to know if any of you has ever > encountered a problem doing so. > > Regards, > > Paul > __________________________ > > Paul Novitski > Juniper Webcraft Ltd. > http://juniperwebcraft.com > > _______________________________________________ > Javascript mailing list > Javascript at lists.evolt.org > http://lists.evolt.org/mailman/listinfo/javascript From xandercoded at gmail.com Thu Aug 20 14:01:56 2009 From: xandercoded at gmail.com (Alexander Freiria) Date: Thu, 20 Aug 2009 15:01:56 -0400 Subject: [Javascript] defining functions before they're called In-Reply-To: <01b001ca21c7$a0e98ef0$e2bcacd0$@com> References: <01b001ca21c7$a0e98ef0$e2bcacd0$@com> Message-ID: +1 for Paul On Thu, Aug 20, 2009 at 2:54 PM, John Warner wrote: > You can run into a problem if the browser has not yet loaded or > 'processed' that portion of the page that contains your function. Aside > from that I think it is a matter of what you prefer and think most > readable and maintainable > > John Warner > > > > -----Original Message----- > > From: javascript-bounces at lists.evolt.org [mailto:javascript- > > bounces at lists.evolt.org] On Behalf Of Paul Novitski > > Sent: Thursday, August 20, 2009 2:05 PM > > To: JavaScript List > > Subject: [Javascript] defining functions before they're called > > > > Can you think of a reason why one shouldn't call a function before > > it's declared in the source code? For example: > > > > window.onload = initialize; > > > > function initialize() > > { > > ... > > } > > > > I can certainly understand why one might choose, stylistically, to > > always define functions before calling them. However, I have never > > experienced any problem using JavaScript by putting the call before > > the function being called. It's my personal preference to put the > > call first because I like to read scripts top-down, seeing how a > > function is used before reading the details of exactly what the > > function does. But I'm curious to know if any of you has ever > > encountered a problem doing so. > > > > Regards, > > > > Paul > > __________________________ > > > > Paul Novitski > > Juniper Webcraft Ltd. > > http://juniperwebcraft.com > > > > _______________________________________________ > > Javascript mailing list > > Javascript at lists.evolt.org > > http://lists.evolt.org/mailman/listinfo/javascript > > > _______________________________________________ > Javascript mailing list > Javascript at lists.evolt.org > http://lists.evolt.org/mailman/listinfo/javascript > -- Regards! Alexander Freiria - Programmer\Web Developer http://www.xandercs.com/ xandercoded at gmail.com 954.549.3666 From blmatthews at gmail.com Thu Aug 20 14:26:59 2009 From: blmatthews at gmail.com (Brian L. Matthews) Date: Thu, 20 Aug 2009 12:26:59 -0700 Subject: [Javascript] defining functions before they're called In-Reply-To: References: Message-ID: <4A8DA383.1000108@gmail.com> On 8/20/09 11:05 AM, Paul Novitski wrote: > Can you think of a reason why one shouldn't call a function before > it's declared in the source code? For example: > > window.onload = initialize; > > function initialize() > { > ... > } > > First, you're not calling the function. Second, that won't work, JavaScript will complain that initialize is not defined. You have to define any identifier before you use it, except the case where you're assigning to it, in which case it's made a global if not already defined (and although it works, it's considered bad practice). Brian From xandercoded at gmail.com Thu Aug 20 14:50:00 2009 From: xandercoded at gmail.com (Alexander Freiria) Date: Thu, 20 Aug 2009 15:50:00 -0400 Subject: [Javascript] defining functions before they're called In-Reply-To: <4A8DA383.1000108@gmail.com> References: <4A8DA383.1000108@gmail.com> Message-ID: Your wrong Brian that will work. On Thu, Aug 20, 2009 at 3:26 PM, Brian L. Matthews wrote: > On 8/20/09 11:05 AM, Paul Novitski wrote: > > Can you think of a reason why one shouldn't call a function before > > it's declared in the source code? For example: > > > > window.onload = initialize; > > > > function initialize() > > { > > ... > > } > > > > > > First, you're not calling the function. Second, that won't work, > JavaScript will complain that initialize is not defined. You have to > define any identifier before you use it, except the case where you're > assigning to it, in which case it's made a global if not already defined > (and although it works, it's considered bad practice). > > Brian > _______________________________________________ > Javascript mailing list > Javascript at lists.evolt.org > http://lists.evolt.org/mailman/listinfo/javascript > -- Regards! Alexander Freiria - Programmer\Web Developer http://www.xandercs.com/ xandercoded at gmail.com 954.549.3666 From xandercoded at gmail.com Thu Aug 20 14:52:17 2009 From: xandercoded at gmail.com (Alexander Freiria) Date: Thu, 20 Aug 2009 15:52:17 -0400 Subject: [Javascript] defining functions before they're called In-Reply-To: References: <4A8DA383.1000108@gmail.com> Message-ID: Where does it stipulate that this is bad practice? On Thu, Aug 20, 2009 at 3:50 PM, Alexander Freiria wrote: > Your wrong Brian that will work. > > On Thu, Aug 20, 2009 at 3:26 PM, Brian L. Matthews wrote: > >> On 8/20/09 11:05 AM, Paul Novitski wrote: >> > Can you think of a reason why one shouldn't call a function before >> > it's declared in the source code? For example: >> > >> > window.onload = initialize; >> > >> > function initialize() >> > { >> > ... >> > } >> > >> > >> >> First, you're not calling the function. Second, that won't work, >> JavaScript will complain that initialize is not defined. You have to >> define any identifier before you use it, except the case where you're >> assigning to it, in which case it's made a global if not already defined >> (and although it works, it's considered bad practice). >> >> Brian >> _______________________________________________ >> Javascript mailing list >> Javascript at lists.evolt.org >> http://lists.evolt.org/mailman/listinfo/javascript >> > > > > -- > Regards! > > Alexander Freiria - Programmer\Web Developer > http://www.xandercs.com/ > xandercoded at gmail.com > 954.549.3666 > -- Regards! Alexander Freiria - Programmer\Web Developer http://www.xandercs.com/ xandercoded at gmail.com 954.549.3666 From david at dorward.me.uk Thu Aug 20 15:01:04 2009 From: david at dorward.me.uk (David Dorward) Date: Thu, 20 Aug 2009 21:01:04 +0100 Subject: [Javascript] defining functions before they're called In-Reply-To: <4A8DA383.1000108@gmail.com> References: <4A8DA383.1000108@gmail.com> Message-ID: <01F0695F-90E5-4F61-A918-A17FB3072589@dorward.me.uk> On 20 Aug 2009, at 20:26, Brian L. Matthews wrote: > On 8/20/09 11:05 AM, Paul Novitski wrote: >> Can you think of a reason why one shouldn't call a function before >> it's declared in the source code? For example: >> >> window.onload = initialize; >> >> function initialize() >> { >> ... >> } > > First, you're not calling the function. Second, that won't work, > JavaScript will complain that initialize is not defined. No, it won't. It uses a function declaration, not a function statement or function constructor. -- David Dorward http://dorward.me.uk From paul at juniperwebcraft.com Thu Aug 20 15:58:51 2009 From: paul at juniperwebcraft.com (Paul Novitski) Date: Thu, 20 Aug 2009 13:58:51 -0700 Subject: [Javascript] defining functions before they're called In-Reply-To: <11604324.1250796558037.JavaMail.root@n13> References: <11604324.1250796558037.JavaMail.root@n13> Message-ID: >On 8/20/09 11:05 AM, I rather sloppily wrote: > > Can you think of a reason why one shouldn't call a function before > > it's declared in the source code? For example: > > > > window.onload = initialize; > > > > function initialize() > > { > > ... > > } > > Thanks for your comments. I apologize for saying 'call' when my example wasn't a call; that was the result of changing my example at the last second and not proofreading the supporting text. However, the example I gave still holds because my onload assignment did refer to a function not yet defined in the source. And the onload assignment example above runs just fine. So does this (an actual call this time!): showme(); function showme() { alert('hi'); } I'm not getting a runtime error in either case, which means that the compiler, as I would expect, assembles a namespace of all the functions in the script before starting execution. At 8/20/2009 12:26 PM, Brian L. Matthews wrote: >First, you're not calling the function. Second, that won't work, >JavaScript will complain that initialize is not defined. Not in my browsers (Firefox 3.5 and IE 8). Do you know of a browser that gacks on it? >You have to define any identifier before you use it What exactly do you mean by "have to"? The following example (of referring to an undefined variable) doesn't faze the JavaScript interpreter: // first and only instance of 'something' in the script alert(something); All it does is alert 'undefined'. The entire script is compiled and the entire script is executed without any abort, a clear indication that it's legal syntax. >, except the case where you're >assigning to it, in which case it's made a global if not already defined Another exception appears to be function declarations. >(and although it works, it's considered bad practice). This is the very point I'm questioning. Why is it considered bad practice if it always works? Can you point to an example of it failing? Or can you find any JavaScript or ECMAScript documentation that cautions against it, and if so what's the rationale? To emphasize my assertion that it's syntactically legal to call a function before it's declared in the source, I need only point out that we can run a script in which two functions call each other: function a() { b(); } function b() { a(); } It wouldn't be possible even to compile such a script if every function had to be declared before it was called because one of those functions must occur before the other in the source code. (If written without limiting conditions, two mutually-calling functions could result in a stack overflow during execution, but that's beside the point. I'm not recommending such logic, I'm just saying it's legal syntax.) And if it's not a requirement of the language interpreter, whose requirement is it? Is it possible that the proscription against calling-before-declaring originates in other languages in which doing so would result in aborted compilation or erroneous execution? The reason I'm belaboring this point is that I'm writing a JavaScript language tutorial and I don't want to give bad advice. If anyone can demonstrate why source order matters I'll reconsider my position, which is currently that it doesn't matter and thus I'm free to promulgate my personal preference for top-down source order. Thanks, Paul __________________________ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com From paul at juniperwebcraft.com Thu Aug 20 17:18:18 2009 From: paul at juniperwebcraft.com (Paul Novitski) Date: Thu, 20 Aug 2009 15:18:18 -0700 Subject: [Javascript] defining functions before they're called In-Reply-To: <4750431.1250802958302.JavaMail.root@n13> References: <11604324.1250796558037.JavaMail.root@n13> <4750431.1250802958302.JavaMail.root@n13> Message-ID: At 8/20/2009 01:58 PM, I wrote: > showme(); > > function showme() > { > alert('hi'); > } To follow up, I've successfully tested this example of calling a function before it's declared in these Windows browsers: Firefox 3.5 IE 8 IE 7 IE 6 IE 5.5 IE 4.01 Opera 9.6.4 Safari 4.0.3 I don't have a functional copy of IE 3 (which used JavaScript 1.0) so I can't test it on this. IE 4 (copyright 1995-97) contains JavaScript 1.2 (which, aside, is close to the level Microsoft supports today!). I'd be willing to bet a big fat nickel that any browser functioning today will execute this example script. If I'm right, where's the rationale for the declare-before-you-call scripting style? I think it has nothing to do with JavaScript functionality and has arisen because function source order matters or once mattered in other and/or older programming languages and has been erroneously superimposed on JavaScript usage. Regards, Paul __________________________ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com From blmatthews at gmail.com Thu Aug 20 17:52:02 2009 From: blmatthews at gmail.com (Brian L. Matthews) Date: Thu, 20 Aug 2009 15:52:02 -0700 Subject: [Javascript] defining functions before they're called In-Reply-To: References: <4A8DA383.1000108@gmail.com> Message-ID: <4A8DD392.4070308@gmail.com> On 8/20/09 12:50 PM, Alexander Freiria wrote: > Your wrong Brian that will work. > Ok, I'm an idiot. I had a typo in my test program, once I fixed that it works. You still have to define things, you evidently don't have to do so before using them. Learn something new every day! Sorry! Brian From riegel at clearimageonline.com Thu Aug 20 18:04:39 2009 From: riegel at clearimageonline.com (Terry Riegel) Date: Thu, 20 Aug 2009 19:04:39 -0400 Subject: [Javascript] defining functions before they're called In-Reply-To: <4A8DD392.4070308@gmail.com> References: <4A8DA383.1000108@gmail.com> <4A8DD392.4070308@gmail.com> Message-ID: > Ok, I'm an idiot. Don't be so hard on yourself :) I think we all have been there before. Thanks for being humble about it. Terry Riegel From paul at juniperwebcraft.com Thu Aug 20 19:03:01 2009 From: paul at juniperwebcraft.com (Paul Novitski) Date: Thu, 20 Aug 2009 17:03:01 -0700 Subject: [Javascript] defining functions before they're called In-Reply-To: <5807702.1250808841116.JavaMail.root@n13> References: <4A8DA383.1000108@gmail.com> <5807702.1250808841116.JavaMail.root@n13> Message-ID: At 8/20/2009 03:52 PM, Brian L. Matthews wrote: >On 8/20/09 12:50 PM, Alexander Freiria wrote: > > Your wrong Brian that will work. > > > >Ok, I'm an idiot. I had a typo in my test program, once I fixed that it >works. You still have to define things, you evidently don't have to do >so before using them. Learn something new every day! Totally not a problem, don't worry about it. Can you recall where you learned that calling before declaring a function was bad form? I'd love to trace that back to see where it comes from and whether it ever pertained to JavaScript. Thanks! Paul __________________________ Paul Novitski Juniper Webcraft Ltd. http://juniperwebcraft.com From riegel at clearimageonline.com Thu Aug 20 19:19:32 2009 From: riegel at clearimageonline.com (Terry Riegel) Date: Thu, 20 Aug 2009 20:19:32 -0400 Subject: [Javascript] defining functions before they're called In-Reply-To: References: <4A8DA383.1000108@gmail.com> <5807702.1250808841116.JavaMail.root@n13> Message-ID: I am pretty sure Pascal was taught (and required) to me that way. Terry Riegel On Aug 20, 2009, at 8:03 PM, Paul Novitski wrote: > At 8/20/2009 03:52 PM, Brian L. Matthews wrote: >> On 8/20/09 12:50 PM, Alexander Freiria wrote: >>> Your wrong Brian that will work. >>> >> >> Ok, I'm an idiot. I had a typo in my test program, once I fixed >> that it >> works. You still have to define things, you evidently don't have to >> do >> so before using them. Learn something new every day! > > > Totally not a problem, don't worry about it. > > Can you recall where you learned that calling before declaring a > function was bad form? I'd love to trace that back to see where it > comes from and whether it ever pertained to JavaScript. > > Thanks! > > Paul > __________________________ > > Paul Novitski > Juniper Webcraft Ltd. > http://juniperwebcraft.com > > _______________________________________________ > Javascript mailing list > Javascript at lists.evolt.org > http://lists.evolt.org/mailman/listinfo/javascript From msd005 at gmail.com Fri Aug 21 10:10:13 2009 From: msd005 at gmail.com (Mike Dougherty) Date: Fri, 21 Aug 2009 10:10:13 -0500 Subject: [Javascript] defining functions before they're called In-Reply-To: References: <4A8DA383.1000108@gmail.com> <5807702.1250808841116.JavaMail.root@n13> Message-ID: <59bedf280908210810m5f457aa9gcce965fb0c3badec@mail.gmail.com> On Thu, Aug 20, 2009 at 7:03 PM, Paul Novitski wrote: > Can you recall where you learned that calling before declaring a > function was bad form? I'd love to trace that back to see where it > comes from and whether it ever pertained to JavaScript. I think I understand what you saying about a technical detail, however I think there is another consideration... Maintenance of a project/program is easier if declarations are easy to find. I'm not saying they must be first, but they probably should be obvious and consistent. Declaration first is one style of managing that. VB's "option explicit" prevents on-the-fly assignment of new variables when a coder mistypes a name, so variables must be declared before use in that case. Rather than having declarations strewn through code, they usually are put at the top/start of a procedure so they can be easily found by the debugging/maintenance programmer. Perhaps this convention is so ingrained that it became a general unquestioned rule? The fact that browsers seem to first read all the javascript in a page to find function declarations doesn't mean you are calling a function before it is defined - the browser implementation is doing a pre-emptive step of looking for functions before running the code. Function declaration anywhere in code is a special case of environment setup. It's not fair to say you can call code by name before it's been named; ex: we can't call closures before creating them: var a = 1; var result = myfunction( 2 ); // this can't work since myfunction doesn't exist yet var myfunction = function(p){ return a + p }; Sorry for so much (wandering) narrative - my point was (more succinctly) that function declaration first is one style to keep code organized and easier to find. As long as everyone on a project understands the convention, any style that works should be fine. From trojani2000 at hotmail.com Sun Aug 23 17:34:24 2009 From: trojani2000 at hotmail.com (Troy III Ajnej) Date: Sun, 23 Aug 2009 22:34:24 +0000 Subject: [Javascript] defining functions before they're called In-Reply-To: References: <11604324.1250796558037.JavaMail.root@n13> <4750431.1250802958302.JavaMail.root@n13> Message-ID: Hi Paul It is true that you can point to the function variable name before the actual function is created, because you can decide on the name of your child months before its actually borned. There's nothing wrong with it. It's only a reserved name for some function; therefore, there should be no error. Since the name is in fact a pointer and will gain its meaning only after the moment that the planned kid come to life. But this: showme(); var showme = function(){alert('hi');} ...won't work! (since it's not a predefined empty Function Object, but a variable that will require its exact value while being read) About following issue: > I don't have a functional copy of IE 3 (which used JavaScript 1.0) so > I can't test it on this. IE 4 (copyright 1995-97) contains JavaScript > 1.2 (which, aside, is close to the level Microsoft supports today!). In fact you can force the browser to use any JavaScript version you like so you won't have to go looking for IE3.11 out there! This will do the trick: That would mean: "Javascript v1.0". Higher versions will require version numbers. But no harm if you try them both ('javascript" and "javascript1.0"). You can also run these tests, (just for fun and curiosity): The latest really supported JS by Opera is 1.5. Well W3C spoiled this capability and compatibility too. Regards. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Troy III progressive art enterprise ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > Paul Novitski > Juniper Webcraft Ltd. > http://juniperwebcraft.com _________________________________________________________________ Get back to school stuff for them and cashback for you. http://www.bing.com/cashback?form=MSHYCB&publ=WLHMTAG&crea=TEXT_MSHYCB_BackToSchool_Cashback_BTSCashback_1x1 From and-babble at doxdesk.com Mon Aug 24 18:49:51 2009 From: and-babble at doxdesk.com (And Clover) Date: Tue, 25 Aug 2009 01:49:51 +0200 Subject: [Javascript] defining functions before they're called In-Reply-To: References: <11604324.1250796558037.JavaMail.root@n13> <4750431.1250802958302.JavaMail.root@n13> Message-ID: <4A93271F.7070904@doxdesk.com> Paul Novitski wrote: > where's the rationale for the declare-before-you-call scripting style? > I think it has nothing to do with JavaScript functionality and has arisen > because function source order matters [...] other programming languages Well, yes... but it also makes a kind of sense. Program execution order is top-to-bottom in JavaScript, so in you would not expect to be able to refer to something you haven't defined yet. Some static progamming languages allow forward-declaration by treating functions as a completely different namespace, not interacting with the run-time (variable) namespace at all. But that's not how JavaScript does it; JS functions are first-class objects, whose references are stored in perfectly normal variables. The trick is: in JavaScript, the 'function' statement is magic. When a block* is entered, the first thing it does is parse all the syntax in the block. Then it looks for 'function' statements and lets those run to define their functions first, before executing the rest of the block. So if you write: var x= alert; function x(s) { alert('hello'); }; x('bye'); the JS interpreter internally re-orders that into: var x; function x(s) { alert('hello'); }; x= alert; x('bye'); and hence you get 'bye', not 'hello' as you might have expected. The ECMAScript-262 standard explains this in section 10.1.3. Well I say 'explains', but this is ECMAScript we're talking about, a document that makes absolutely no concessions to clarity. This only applies to the function statement, and not the function expression! So if you changed the first example in a seemingly trivial way: var x= alert; x= function x(s) { alert('hello'); }; x('bye'); you now have 'hello' instead of 'bye'! *: what's a block, in this context? Well, a script file, a script element, an inline event handler, a function body, a condition or loop... for example this: var x= alert; if (true) { function x(s) { alert('hello'); }; } x('bye'); keeps the definition of the function inside the 'if' instead of reordering it out before the 'alert' assignment. So you get 'hello'. For a dynamic scripting language this is all really incredibly spooky and confusing; I can't think of another language that does anything like this. It's another in the long-running series of JavaScript Strangenesses. So, back to the question. Should you rely on forward-declaration in JavaScript? Well... if you are reassigning and passing around functions/methods as objects, then probably you shouldn't because the order-of-execution is then not what it looks like and you'll get weird errors. If you are treating them purely as classic static functions, you can probably get away with it. But even in this case you have to be careful to keep them in the same block; put an if round them, or split the script element into two, and they'll suddenly stop working. All in all I would probably avoid it. In any case, it's very rarely actually useful -- And Clover mailto:and at doxdesk.com http://www.doxdesk.com/ From del at delweg.com Sat Aug 29 10:17:40 2009 From: del at delweg.com (Del Wegener) Date: Sat, 29 Aug 2009 10:17:40 -0500 Subject: [Javascript] Javascript and FF Message-ID: <4B92B2C4E6594671A192A9624CF685D3@delweglaptop> Good Morning; I have a Javascript calculator http://www.edi-cp.com/products_a_series_at_estimator.php Which works as intended in IE and I believe it worked in earlier versions of FF. However nothing happens when I use it in FF Version 3.5.2 nor with Version 3.0.11 When I initially installed the calculator FF was probably at Version 2.xxx. I am sure it worked then. What has changed? What must I do to my JavaScript to make FF 3.5.2 play nicely? Thanks for any help. Del From hassan at webtuitive.com Sat Aug 29 10:31:16 2009 From: hassan at webtuitive.com (Hassan Schroeder) Date: Sat, 29 Aug 2009 08:31:16 -0700 Subject: [Javascript] Javascript and FF In-Reply-To: <4B92B2C4E6594671A192A9624CF685D3@delweglaptop> References: <4B92B2C4E6594671A192A9624CF685D3@delweglaptop> Message-ID: <4A9949C4.7050900@webtuitive.com> Del Wegener wrote: > I have a Javascript calculator > http://www.edi-cp.com/products_a_series_at_estimator.php > Which works as intended in IE and I believe it worked in earlier versions of > FF. However nothing happens when I use it in FF Version 3.5.2 nor with > Version 3.0.11 No, something happens -- it's called an "error" :-) I don't know if it's available for 3.5.x but on 3.0.x you should install the Firebug developer extension. It exposes error messages and jumps you right into the applicable part of the code. HTH! -- Hassan Schroeder ----------------------------- hassan at webtuitive.com webtuitive design === (+1) 408-621-3445 === http://webtuitive.com twitter: @hassan dream. code. From nan at nanharbison.com Sat Aug 29 10:22:09 2009 From: nan at nanharbison.com (Nan Harbison) Date: Sat, 29 Aug 2009 11:22:09 -0400 Subject: [Javascript] Javascript and FF In-Reply-To: <4B92B2C4E6594671A192A9624CF685D3@delweglaptop> References: <4B92B2C4E6594671A192A9624CF685D3@delweglaptop> Message-ID: <6B4B9E9DF3A2447994A98367B4B9CFCF@nancyb0bda4ba6> Here is what the w3 validator says: #################################################### # Error Line 23, Column 30: required attribute "TYPE" not specified