|
Gentle Marmot posted:What if I stored to json file locally would that simplify things? Could I just read and write to it from within the javascript? No, Javascript does not have any sort of file system access* due to it running inside the browser sandbox. * you can use HTML5's localStorage to store data, but this is not filesystem access.
|
# ? Sep 22, 2010 04:07 |
|
|
# ? May 21, 2024 00:56 |
|
dancavallaro posted:What is an example of a use case where it makes sense to use == over ===? The only time I ever had trouble with not being able to use === is if I had to check for "undefined" for some reason. For some reason it always failed (not sure if it still does) One of my former coworkers pissed me off by constantly doing this: code:
|
# ? Sep 22, 2010 18:30 |
|
geeves posted:The only time I ever had trouble with not being able to use === is if I had to check for "undefined" for some reason. For some reason it always failed (not sure if it still does) I can understand wanting to force a type with undefined, integers, floats, booleans, etc... but nothing coerced into a string will ever deliver the correct string. If you try to compare arg1 == "something", if arg1 is an int, there's no way it will ever == "something". It can only ever == "something" if it started out as a string in the first place. So in this case, it seems to me that using === for a non-blank string isn't necessary?
|
# ? Sep 22, 2010 18:51 |
|
Golbez posted:I can understand wanting to force a type with undefined, integers, floats, booleans, etc... but nothing coerced into a string will ever deliver the correct string. If you try to compare arg1 == "something", if arg1 is an int, there's no way it will ever == "something". It can only ever == "something" if it started out as a string in the first place. So in this case, it seems to me that using === for a non-blank string isn't necessary? How does it hurt to use === instead of == ? And since === is actually faster than == , I guess the better question is why wouldn't you use ===?
|
# ? Sep 22, 2010 18:58 |
|
Lumpy posted:How does it hurt to use === instead of == ? And since === is actually faster than == , I guess the better question is why wouldn't you use ===? My question was more along the lines of, why would geeves' coworker even need to do a 'typeof' in this case? The only possible type that can ever == "something" is a string. It's not like == "1", where a string or int could work. I'm slowly moving towards using ===s, though since most of my work is in PHP, and form submissions are always strings, that can sometimes be a little counterintuitive.
|
# ? Sep 22, 2010 19:02 |
|
Golbez posted:My question was more along the lines of, why would geeves' coworker even need to do a 'typeof' in this case? The only possible type that can ever == "something" is a string. It's not like == "1", where a string or int could work. Ah, sorry, I misunderstood your point. Yeah, the typeof is pointless in that case. but
|
# ? Sep 22, 2010 19:30 |
|
Golbez posted:My question was more along the lines of, why would geeves' coworker even need to do a 'typeof' in this case? The only possible type that can ever == "something" is a string. It's not like == "1", where a string or int could work. That's the point. My coworker didn't have to check for typeof because it was already handled in a method that would always return a String or an Integer or Boolean, etc. Even though JavaScript doesn't support real strong typed members, it's just something I've become picky about from my experience in Java and brought into my JS coding and it's also greatly reduced the type I've had to spend debugging.
|
# ? Sep 22, 2010 21:08 |
|
Lumpy posted:No, Javascript does not have any sort of file system access* due to it running inside the browser sandbox. localstorage ended up working out perfectly thanks
|
# ? Sep 25, 2010 06:31 |
|
Is there a good way of traversing an html table with javascript? I cant find anything useful. I can get a list of the table rows using myTable.getElementsByTagName("tr"). This seems to return me a node list, now how can I get to the individual "td"s out of there to read their values?
|
# ? Sep 29, 2010 16:18 |
|
Gentle Marmot posted:Is there a good way of traversing an html table with javascript? I cant find anything useful. I can get a list of the table rows using myTable.getElementsByTagName("tr"). This seems to return me a node list, now how can I get to the individual "td"s out of there to read their values? You'll need to loop inside each tr node to pull out a nodelist of its th/td's, then grab each value from each cell.
|
# ? Sep 29, 2010 16:36 |
|
How do I loop through the tr node to get what I need? I cant call getElementsByTagName on it, and childNodes() does nothing as well. I even tried using row.innerHtml.getElementsByTagName("td"), nada. When I just tried running "for (var i in rows[i]) for example I got a list of methods and other garbage. Javascript really makes this poo poo complicated for no reason.
|
# ? Sep 29, 2010 16:51 |
|
You may want to elaborate on "what I need".
|
# ? Sep 29, 2010 16:54 |
|
Sorry this is just frustrating. I need to get the text out of a certain cell in my table. Then what I want to do is check that text against something and delete the row its found in. Like I said the farthest ive gotten is making a list of all the rows.
|
# ? Sep 29, 2010 16:57 |
|
.textContent on everything but IE, .innerText on it; done via feature testing, of course:code:
|
# ? Sep 29, 2010 17:28 |
|
Gentle Marmot posted:Sorry this is just frustrating. Use jQuery. code:
Lumpy fucked around with this message at 19:26 on Sep 29, 2010 |
# ? Sep 29, 2010 19:23 |
|
I have a page that is working perfectly in Chrome and Firefox, but IE7 a couple of lines are causing errors. Unfortunately the only error message give is the extremely unhelpful "Object expected" and I don't trust the line numbers it's giving me (one of them seems to be referring to a <TR> tag in a table and not actually a script at all). I have to get this working on IE as some of our lab machines only have that installed and we can't put another browser on, so: - Has anyone encountered this error and know what it means? From googling it kind of seems like a generic error thrown out by IE in a lot of different situations that doesn't actually tell us much. - Can anyone recommend a good javascript debugging tool for use with Internet Explorer? The code itself is pretty trivial, one function populates a text box with the current date, formatted a certain way and is called on the page loading, another simple popualtes a text box when it gains focus with values from a couple of other text boxes and a multi-select. I don't even know where to start debugging it since it's working fine in the other two browsers. I'm not even sure if it's my function that's screwing things up, I actually think it might be some code further up the page which I didn't write which is bugging out IE and causing the rest of the scripts not to run properly.
|
# ? Oct 1, 2010 12:53 |
|
chippy posted:I have a page that is working perfectly in Chrome and Firefox, but IE7 a couple of lines are causing errors. Unfortunately the only error message give is the extremely unhelpful "Object expected" and I don't trust the line numbers it's giving me (one of them seems to be referring to a <TR> tag in a table and not actually a script at all). You can try FireBug Lite or IE Developer Toolbar If you post a link to your code, I'm guessing somebody will be able to quickly see what the problem is. EDIT: If you can, test in IE8 and see if the problem happens there: IE8 actually has a not terrible built in console / debugger. Lumpy fucked around with this message at 13:33 on Oct 1, 2010 |
# ? Oct 1, 2010 13:30 |
|
Thanks, I will try that. I can't post a link to the page as it's an internal site. Here is the function I wrote that is working fine in FF/Chrome but not in IE, however I'm not 100% sure that the issue is in this block, I have a feeling it might be further back in the page: (The bit in square brackets is template toolkit markup) code:
|
# ? Oct 1, 2010 13:41 |
|
OK, if anyone's interested in helping, pastebin of the entire page is here: http://pastebin.com/YcCypnPG The lines causing issues according to IE are: Syntax error enter_bug.cgi?product=CS77V1, line 285 character 3 Object expected enter_bug.cgi?product=CS77V1, line 134 character 1 Object expected enter_bug.cgi?product=CS77V1, line 834 character 1 Object expected enter_bug.cgi?product=CS77V1, line 834 character 1 If anyone can shed any light I'd be really grateful, I'm pretty much getting nowhere here.
|
# ? Oct 1, 2010 16:04 |
|
chippy posted:OK, if anyone's interested in helping, pastebin of the entire page is here: http://pastebin.com/YcCypnPG Couple quick things to try: 1. You define the set_assign_to() fuction AFTER the body tag... IE might not like that (although it shouldn't be a problem... but this is IE) 2. On line 285, you call this: code:
There is a lot of "less than best practices" code in there. code:
code:
Lumpy fucked around with this message at 16:30 on Oct 1, 2010 |
# ? Oct 1, 2010 16:26 |
|
Thanks a lot dude, much appreciated. I will have a look at those things, if I can. None of what you quoted is my code, incidentally, this is a Bugzilla installation I'm customising, and that is all stock stuff. I never actually checked if the stock version of this page was fully working before my customisations, I suspect it probably wasn't.
|
# ? Oct 1, 2010 16:36 |
|
Well gently caress a duck, I just had to move the "-->" to the end of the script block instead of half way through it. Retard
|
# ? Oct 4, 2010 11:41 |
|
chippy posted:Well gently caress a duck, I just had to move the "-->" to the end of the script block instead of half way through it. Retard Do yourself a favor and remove those comment things completely. Unless you are supporting Mosaic 0.96, you don't need them.
|
# ? Oct 4, 2010 14:53 |
|
Yeah they're just to hide the script from non-JavaScript supporting browsers aren't they? I'm surprising the closing one being in the wrong place made any difference at all.
|
# ? Oct 4, 2010 16:14 |
|
chippy posted:Yeah they're just to hide the script from non-JavaScript supporting browsers aren't they? I'm surprising the closing one being in the wrong place made any difference at all. Which would imply they're using a browser conclusively pre-1997, right? A glance at Wikipedia shows Netscape and IE both started supporting their scripting solutions around '96, and ECMAScript was standardized in '97. Surely, any modern browser that doesn't handle ECMASript for whatever reason is smart enough to know of its existence and ignore it. Same deal with browsers that don't support frames. If you're using one, you kind of deserve to get a garbled mess on your screen, in the few modern cases where frames are still used. The only valid comments to keep things from being seen by browsers, I figure, are those awesome IE comments that Microsoft helpfully gave us to make up for the fact that they hosed up their CSS implementation.
|
# ? Oct 4, 2010 17:04 |
|
Golbez posted:Which would imply they're using a browser conclusively pre-1997, right? A glance at Wikipedia shows Netscape and IE both started supporting their scripting solutions around '96, and ECMAScript was standardized in '97. Surely, any modern browser that doesn't handle ECMASript for whatever reason is smart enough to know of its existence and ignore it. Oh sure, yeah, I wasn't disagreeing. I'll probably take them out. As I mentioned, most of the code in the page isn't mine, it's from the standard Bugzilla install, all I've done is change the layout a little and add a couple of functions to assist with filling the forms in.
|
# ? Oct 4, 2010 17:34 |
|
chippy posted:Oh sure, yeah, I wasn't disagreeing. I'll probably take them out. As I mentioned, most of the code in the page isn't mine, it's from the standard Bugzilla install, all I've done is change the layout a little and add a couple of functions to assist with filling the forms in. Oh, I wasn't saying you were disagreeing, I was just astonished that anyone would have used such comments at all these days. Bugzilla has no business hiding its Javascript from IE 2.0. It might have made sense during the Clinton administration, but not any longer.
|
# ? Oct 4, 2010 17:40 |
|
Golbez posted:Oh, I wasn't saying you were disagreeing, I was just astonished that anyone would have used such comments at all these days. Bugzilla has no business hiding its Javascript from IE 2.0. It might have made sense during the Clinton administration, but not any longer. It's almost as if Bugzilla is really freakin old
|
# ? Oct 4, 2010 19:11 |
|
So, I'm trying to learn JavaScript objects and making a reusable RSS FeedObject (don't worry about x-browser compatibility) This is what I have right now code:
code:
What am I screwing up here? Ok... I'm confused... I just reimplemented it in a different object form and it's still coming up as undefined code:
umm.. .Ok, so how do I reference items, if this is now something else.? ATLbeer fucked around with this message at 22:03 on Oct 7, 2010 |
# ? Oct 7, 2010 21:24 |
|
The way 'this' works in JavaScript is counter-intuitive: roughly it gets what's to the left of the dot when the call is made. So when you call x.whatever() this is set to value of x... But when XMLHttpRequest calls onreadystatechange, it sets this to itself. What you want to do is something like this: ... var self = this; this.ro.onreadystatechange = function() { self.feed_fetched(); } ... which will take care of setting this properly inside feed_fetched.
|
# ? Oct 7, 2010 22:06 |
|
OddObserver posted:The way 'this' works in JavaScript is counter-intuitive: roughly it gets what's to the left of the dot when the call is made. Yeah... I just realized that "this" is all sorts of not what I thought it was. Is this too hacky? code:
|
# ? Oct 7, 2010 22:10 |
|
ATLbeer posted:So, I'm trying to learn JavaScript objects and making a reusable RSS FeedObject (don't worry about x-browser compatibility) Don't bother with new or this at all..... code:
Lumpy fucked around with this message at 14:01 on Oct 8, 2010 |
# ? Oct 7, 2010 22:15 |
|
To expand on what OddObserver said, the basic gist of "this" is this: "this" refers to the global window object unless explicitly stated otherwise. Here's a bit of code howsabout. (Not using var statements here on purpose, just an example here...) code:
code:
On line 1 of the output, we're doing "withNew = new Container();". By using the "new" keyword, we're creating a new object, so "this" is being explicitly created and referred to. In this case, "this" will refer to a new instance of Container. On line 2, we get an exception raised from trying to call "withoutNew.func()". This is because withoutNew is actually undefined -- since Container was called without the "new" keyword and the function itself has no return value, withoutNew is actually undefined. On lines 3 and 4 we are calling "withNew.func()" and everything is great. withNew is defined as an instance of Container and "this" refers to withNew. For lines 5 and 6 we're calling "func" via apply. Since the first parameter to apply is a pointer to the call's "this" reference, we're really calling "someOtherObject.func()". On lines 7 and 8 we're calling "withNew.func()" in the setTimeout call we're passing a reference to an anonymous function that was referred to in the Container constructor referred to as "func" to setTimeout. This anonymous function in and of itself has no idea what withNew is, so it has no idea how to refer to it as "this". On lines 9 and 10 we create an anonymous function to create a closure around a call to withNew so we can properly call "withNew.func()". This closure keeps the reference to withNew intact and allows the anonymous function referred to as "func" to know what "this" refers to. Lines 11 and 12 are similar, but we create the reference to withNew outside of the closure where we refer to it as "that". So there's the basics of "this". The book mentioned by Lumpy, Douglas Crockford's "The Good Parts", is probably fantastic, as although I have not read it personally, I am a big fan of Crockford's and he's the man when it comes to JavaScript. I highly recommend his video series on JavaScript on YUI Theatre, as they're well worth watching. They're the sort of videos where, yeah, they're focused on JavaScript, but he packs so much history of our industry into the videos that they could have well been about BASIC and been just as interesting. http://developer.yahoo.com/yui/theater/ They're the ones in the middle-left column, bottom-up. Great videos.
|
# ? Oct 8, 2010 03:40 |
|
dark_panda posted:[Good stuff about 'this' and constructors] And that's why I don't bother with prototypical constructors and new. That said, that is an excellent little write-up panda, you should post it somewhere. dark_panda posted:I highly recommend his video series on JavaScript on YUI Theatre, as they're well worth watching. They're the sort of videos where, yeah, they're focused on JavaScript, but he packs so much history of our industry into the videos that they could have well been about BASIC and been just as interesting. These are must-watches for anyone doing JS, and like you said, a really cool history even if you don't.
|
# ? Oct 8, 2010 14:00 |
|
So, I'm working on a virtual desktop-style app using this mochaUI library. Ultimately I plan on using Chrome's Application shortcut thing and distributing some sort of installer to my users that installs chrome if it's not already present with gears stuff baked in (if that's even possible), and sets up the shortcut/puts the link on the desktop (the app is for a small public program and is only accessible on their LAN or by VPN. so, I have the luxury of choosing the browser I'm developing for). With respect to handling the javascript effects and crap employed by the MochaUI interface, Chrome is by far the best browser. Problem: Chrome's garbage collection behavior is doing some weird stuff with respect to freeing up memory after windows are closed in the virtual desktop. In a nutshell, the memory allocated for an opened and subsequently closed window is only freed if the browser is minimized. If the browser is open, the memory useage doesn't change a bit after a given window is closed, and subsequent openings/closings make the memory useage just go up and up. All the virtual desktop windows load their content using iframes (I'm guessing this is a factor, but haven't tested different methods of loading window content). I did this simple test to verify that the memory useage behavior was linked to the open/minimized state of the browser: Step 1. open/close a window 5 times while minimizing browser each time after closing the window before opening it again. Step 2. do the same thing but leave browser open like normal useage/sane person. While my code is clearly leaking memory like crazy and could use a ton of work, there's still an unmistakable difference in memory useage between those two tests: 29560k after the first, 47016k after the second. Question: Is there anything I can do in javascript/gears/a chrome extension that can manually force garbage collection to occur? Or, given that the open/minimized state of the browser seems to be a central factor, does this suggest anything in particular that I should look for in my own code that could be a culprit? Orbis Tertius fucked around with this message at 18:14 on Oct 8, 2010 |
# ? Oct 8, 2010 18:06 |
|
I've installed greasemetal, and put my user script (which works in greasemonkey) in the userjs folder, how do I tie the script to the site(s) its supposed to work on?
|
# ? Oct 8, 2010 18:59 |
|
I don't know if this is a jQuery thing or not, but has anyone every successfully made a variable inside an anonymous function readable outside of it? We did this at my old job so we would avoid collisions amongst us writing lots of JS. But I didn't come up with how it was done and I've been unsuccessful in trying to recreate it from memory. It was something maniacal involving the window object. code:
Any ideas?
|
# ? Oct 9, 2010 03:00 |
|
Can I ask why you want to do this? If you keep variables non-global, they won't conflict with others of the same name, of course.
|
# ? Oct 9, 2010 04:14 |
|
Lamb-Blaster 4000 posted:I've installed greasemetal, and put my user script (which works in greasemonkey) in the userjs folder, how do I tie the script to the site(s) its supposed to work on? You don't need to use greasemetal. Chrome has supported userscripts natively for a while now. Internally, they get converted into extensions when you install them. Be aware, though, that the GM_method API is not fully supported.
|
# ? Oct 9, 2010 06:12 |
|
|
# ? May 21, 2024 00:56 |
|
geeves posted:I don't know if this is a jQuery thing or not, but has anyone every successfully made a variable inside an anonymous function readable outside of it? code:
Nigglypuff fucked around with this message at 16:44 on Oct 9, 2010 |
# ? Oct 9, 2010 06:15 |