|
necrotic posted:The Library object (and subsequently Q.fn) is created one time; I'm confused, how is Library being created once in this case? It looks like whenever you call Q() the Library constructor function is run and a new object is returned.
|
# ? Nov 4, 2014 00:59 |
|
|
# ? May 16, 2024 18:33 |
|
CuddleChunks posted:I'd love some help with learning how to pull data from a remote JSON API into my silly little page. On my phone, so somewhat guesswork, but typically the callback parameter is the name of the function that the returned script will invoke with the JSON data. In your case you're giving it ? which isn't a legal function name, nor do you have a function defined to receive it. Furthermore, JSONP isn't JSON, so getJSON will likely choke on the script file that comes back. Typically JSONP is used to avoid cross-site woes, by putting the URL in a <script> tag. When the script is loaded, it calls the specified — and hopefully defined!—function with the desired data. If the API server works with cross-site XHR then you don't need to use JSONP (which would be preferable), but if it doesn't then getJSON isn't going to fly either.
|
# ? Nov 4, 2014 03:23 |
|
That's just how jQuery.getJSON works. It looks for "callback=?" in your query and generates a function name for the callback to hit. (Actually, I think it looks for just "=?" so you can name the parameter whatever you want.) I'd check to make sure your endpoint is really JSONP. Check the network pane. You should see that jQuery generated a request that looks like: GET http://www.macvendorlookup.com/api/v2/00026f123456?callback=jsonp1249635980723 And that you get a response that looks something like: JavaScript code:
HTML code:
If you don't see that, the endpoint doesn't support JSONP and that's not going to work. Checking the API docs you linked to, it looks like it in fact doesn't support JSONP. So just remove the ?callback=? part and what (hopefully) will happen is that it does support CORS and regular AJAX will work without the need for JSONP.
|
# ? Nov 4, 2014 03:35 |
|
Oh! That's a...delightful bit of magic. Thanks, sorry for the noise.
|
# ? Nov 4, 2014 03:38 |
|
It doesn't support JSONP or CORS. You're poo poo out of luck, outside of emailing the guys.
|
# ? Nov 4, 2014 05:12 |
|
Well, or writing a local proxy running on the same domain. The great traditional solution to a problem that by all rights shouldn't exist in the first place. gently caress you, SOLR. Er, what were we talking about again?
|
# ? Nov 4, 2014 05:56 |
|
Xenoveritas posted:Well, or writing a local proxy running on the same domain. The great traditional solution to a problem that by all rights shouldn't exist in the first place. gently caress you, SOLR. Er, what were we talking about again? You could always just roll with --disable-web-security in Chrome or enabling access to datasource across domains in IE security settings if this is just a personal thing.
|
# ? Nov 4, 2014 14:20 |
|
Suspicious Dish posted:It doesn't support JSONP or CORS. You're poo poo out of luck, outside of emailing the guys. Thanks to everyone who peeked at this. I was going nuts trying to get it to work and am too new to this JSON stuff to know the difference between my own messup and the remote site. Sheesh. "Here's our API! You can totally use it duders!" HOW???? I'll send them a message. Thanks again for the info everyone.
|
# ? Nov 4, 2014 17:08 |
|
Bruegels Fuckbooks posted:You could always just roll with --disable-web-security in Chrome or enabling access to datasource across domains in IE security settings if this is just a personal thing. It is not. The whole cross-domain origin restriction is so stupid. Especially when it leads to things like JSON-P. "Well, we can't get raw text from another domain for 'security reasons,' so let's instead inject arbitrary code from that other domain because that we are allowed to do!" (I could see restricting cross-domain requests to GET, but the whole AJAX cross-domain restriction is so pointlessly stupid.) CuddleChunks posted:Sheesh. "Here's our API! You can totally use it duders!" HOW???? I'll send them a message. Thanks again for the info everyone. Presumably the intention is that you do it from code that's outside the browser, which doesn't have to deal with cross-domain restrictions.
|
# ? Nov 4, 2014 17:17 |
|
The cross domain stuff is pretty important, so that I don't make a bunch of XHRs from my random blog and use your established Facebook/gmail/bank/intranet credentials to act on your behalf.
|
# ? Nov 4, 2014 18:17 |
|
Opulent Ceremony posted:I'm confused, how is Library being created once in this case? It looks like whenever you call Q() the Library constructor function is run and a new object is returned. A new object is allocated, but the prototype of that object is already allocated in the IIFE. If you did the entire thing in Q() the object and the prototype would be allocated for each call.
|
# ? Nov 4, 2014 18:36 |
|
CuddleChunks posted:Sheesh. "Here's our API! You can totally use it duders!" HOW???? I'll send them a message. Thanks again for the info everyone. JSON isn't restricted to Javascript. I've accessed JSON endpoints with Python and PHP. It's such an established format that every language has libraries for handling it.
|
# ? Nov 4, 2014 19:11 |
|
CuddleChunks posted:Thanks to everyone who peeked at this. I was going nuts trying to get it to work and am too new to this JSON stuff to know the difference between my own messup and the remote site. Save this as passthrough.php in the same folder you have your html: php:<? echo file_get_contents('http://www.macvendorlookup.com/api/v2/'. preg_replace('/[^a-z0-9\:\-\.]/i', '', $_GET['mac'])); ?> JavaScript code:
|
# ? Nov 4, 2014 19:46 |
|
Subjunctive posted:The cross domain stuff is pretty important, so that I don't make a bunch of XHRs from my random blog and use your established Facebook/gmail/bank/intranet credentials to act on your behalf. So don't send cookies on cross-domain requests. That's not what it's intended to protect against anyway, the cross-domain restriction is intended to prevent me from reading data on other sites using your credentials. I can send any GET request to any URL I want anyway, I just can't read the results. Really I can do the same thing with POSTs using embedded <iframe>s and forms. CORS is an acceptable solution, it's just annoying it took so long to arrive. (Although it's old enough now that pretty much every browser supports it.)
|
# ? Nov 4, 2014 20:09 |
|
Being able to read data is a pretty big deal, it's not about destructive GET. Even if dropping cookies/basic-auth/client certs/etc for all cross-domain XHR was desirable, which it's not really, lots of intranet content is protected simply by network perimeters and not additional auth. Microsoft randomly invented XDomainRequest to do anonymous requests, but even then they needed a positive signal from the server that the response was allowed to be exposed to the requesting script.
|
# ? Nov 5, 2014 04:55 |
|
I've been searching around on this with little success and figured I might as well ask here: is there any amount of Javascript/JQuery trickery (or PHP if it's really necessary, I GUESS) which would allow me to set an element which is inside an iframe to stay in a fixed position relative to the browser window? All the usual methods appear to just make things stay in one position relative to the iframe rather than to the window, which doesn't help. I've fooled around with the idea of using JQuery to spit the object's markup into the parent document, but that's not a good solution since the iframe's content comes from a different server than the outer document and there's a lot of code on that server which the elements are reliant on and which I really don't want to have in two different places.
|
# ? Nov 5, 2014 23:22 |
|
loquacius posted:I've fooled around with the idea of using JQuery to spit the object's markup into the parent document, but that's not a good solution since the iframe's content comes from a different server That won't work, either, since you can't read the contents of an iframe on another server.
|
# ? Nov 5, 2014 23:33 |
|
You can if they share a common eTLD+1 and they both set document.domain.
|
# ? Nov 5, 2014 23:55 |
|
Which frame do you have control over and why do you want to do this in the first place? I suspect that if you have control over both frames the answer is "yes." You can use window.postMessage to send messages between a parent document and iframes within it. From this you could either play around with keeping the element inside the iframe by updating scrolling positions or simply have the iframe send a message to the parent with the data necessary to recreate the element itself. I don't remember what properties are accessible via window.frameElement but that's another thing that might be useful.
|
# ? Nov 5, 2014 23:55 |
|
Yeah, I control both frames. The reason I'm trying to do this is that there's a UI element which I want to always be in one place on the screen, but the fact that it's located inside the iframe (and dependent on code hosted on the iframe's server) is kind of making that surprisingly difficult to pull off. Passing messages back and forth between the windows is a possible solution (which I'll check into when I get into work tomorrow); thanks!
|
# ? Nov 6, 2014 02:09 |
|
Can someone explain to me how Chai's chained assertion stuff works? I don't see how a line of JavaScript code like expect(false).to.not.be.ok; can actually do anything without making ok() into a function call.
|
# ? Nov 7, 2014 11:39 |
|
qntm posted:Can someone explain to me how Chai's chained assertion stuff works? I don't see how a line of JavaScript code like expect(false).to.not.be.ok; can actually do anything without making ok() into a function call. They've defined a getter on the "ok" property that actually runs the assertion when you get its value. It seems unnecessary to me (much like that whole programming style), but it does "work". Just so long as no-one goes around inspecting any of those intermediate values in a debugger.
|
# ? Nov 7, 2014 12:50 |
|
Dang, I didn't know that just getting a property could have side-effects like that. Now I have to think carefully before even removing seemingly dead code like if(thing.property) { /* empty block */ }.
|
# ? Nov 7, 2014 15:35 |
|
qntm posted:Dang, I didn't know that just getting a property could have side-effects like that. Now I have to think carefully before even removing seemingly dead code like if(thing.property) { /* empty block */ }. Welcome to the wonderful world of getters and setters!
|
# ? Nov 7, 2014 16:38 |
|
I really dislike when frameworks do "cute" stuff like that without immediately explaining what they're doing behind the scenes. One example is Angular using toString() on functions and then parsing the function arguments to determine the dependencies to inject.
|
# ? Nov 7, 2014 17:09 |
|
If I can have an array and want to check the previous two elements, what's the correct way to assign a value of 0 to those indexes that are potentially out of bounds? JavaScript code:
|
# ? Nov 9, 2014 03:59 |
|
If you can be sure that all the valid values in your array are numbers, then you can do (homeValues[i-2] || 0);
|
# ? Nov 9, 2014 04:06 |
|
I'm trying to write a little chrome extension that will simply open a new tab and load a webpage into it. Can anyone show me what my manifest and js file should look like to get me started?
|
# ? Nov 9, 2014 15:25 |
|
Edit: guess I didn't understand what he was trying to do.
CuddleChunks fucked around with this message at 00:05 on Nov 11, 2014 |
# ? Nov 9, 2014 18:05 |
|
enthe0s posted:If I can have an array and want to check the previous two elements, what's the correct way to assign a value of 0 to those indexes that are potentially out of bounds? I'm curious because what you asked for doesn't quite match up with your code. Suppose your array has four elements [3, 16, 28, 399], do you want to iterate like this ("previous two elements"): code:
code:
In the first case, following Suspicious Dish's advice, you want: JavaScript code:
JavaScript code:
|
# ? Nov 9, 2014 19:06 |
|
Is there a good JavaScript library to scrape web/date data? I want to scrape this drop-in hockey calendar. Since it doesn't look like I can get it in JSON, I'm going to have to parse the HTML table manually. My first inclination is to turn the HTML into JSON and then parse it that way, but I was curious if there's a better way or a library that will do this for me. The plan is to write all my various web scrapers in Node (one for each hockey rink that doesn't provide JSON), then turn the data into JSON that I serve up with Angular, if that matters. This is one of my "learn JavaScript" projects.
|
# ? Nov 10, 2014 03:33 |
|
Dangerllama posted:Is there a good JavaScript library to scrape web/date data? I want to scrape this drop-in hockey calendar. Since it doesn't look like I can get it in JSON, I'm going to have to parse the HTML table manually. Have you looked at http://cheeriojs.github.io/cheerio/? It's basically jQuery for the server.
|
# ? Nov 10, 2014 09:15 |
|
ostills posted:Have you looked at http://cheeriojs.github.io/cheerio/? It's basically jQuery for the server. This looks exactly like what I need. Thanks!
|
# ? Nov 10, 2014 17:10 |
|
Wheany posted:I really dislike when frameworks do "cute" stuff like that without immediately explaining what they're doing behind the scenes. For me the key thing is if it's immediately obvious that they're doing something cute when reading code using it. It doesn't matter how well documented something is if the code doesn't give me any reason to think I need to look at the documentation. IMO the Chai example is pointlessly clever, but it's not something I'm going to blow four hours on trying to figure out why some perfectly ordinary operation isn't working before discovering that it's because of well-hidden magic.
|
# ? Nov 12, 2014 06:47 |
|
Another question related to my previous issue: I have scroll event listeners in place that make changes to the page depending on where the user has scrolled. If I scroll around using a laptop touchpad (or tablet touchscreen), the scroll event fires and the listeners do their job as long as my fingers are still touching the pad/screen. If I "flick" my way around the page with a quick swipe, though, neither the "scroll" event nor the "touchmove" event seems to fire. Is there another event I should be listening on to deal with swipes or am I SOL?
|
# ? Nov 12, 2014 19:51 |
|
loquacius posted:Another question related to my previous issue: I have scroll event listeners in place that make changes to the page depending on where the user has scrolled. If I scroll around using a laptop touchpad (or tablet touchscreen), the scroll event fires and the listeners do their job as long as my fingers are still touching the pad/screen. If I "flick" my way around the page with a quick swipe, though, neither the "scroll" event nor the "touchmove" event seems to fire. Is there another event I should be listening on to deal with swipes or am I SOL? Probably SOL? I have had an awful time trying to interact with touchpads/screens and scroll/touch events.
|
# ? Nov 12, 2014 20:25 |
|
You can always do the tried-and-true method of setInterval and constantly polling the scroll position. Although I still have to ask: why does this element need to be fixed? Is the iframe really necessary? Are you sure you can't move everything to one page and use REST+CORS to get whatever data you need for the other domain? Because position:fixed is far superior to trying to duplicate it in JavaScript.
|
# ? Nov 12, 2014 23:21 |
|
Yeah, for the record I ended up just declaring defeat there and setting the size of the iframe and outer frame relative to the window size such that the user never gets too lost and it minimized the negative effects of things scrolling at the wrong times. In closing, dealing with legacy code is a huge pain in the rear end.
|
# ? Nov 13, 2014 22:21 |
|
I guess this isn't strictly a Javascript question, but it is related: When using Spy-JS in Idea, is there a way to find traces that have executed a particular line?
|
# ? Nov 14, 2014 16:24 |
|
|
# ? May 16, 2024 18:33 |
|
This is maybe a more vague best-practices related question, but I'm having some trouble organizing my code for a particular feature. I have an input text box that a user can fill in that's also controlled by a list on checkboxes/customer names. The functionality I have is that when the user clicks on a checkbox/customer name, that value is added to the input box - multiple customers can be selected, with commas as a delimiter. I also allow the user to type in a customer name manually, and update the checkboxes if he has typed a valid name. My issue is that right now, I'm basically making a form with a bunch of click handlers going back and forth. It's not particularly reusable, and I am going to be adding several more controls like this to the page, so I'd like this JS not to turn into like 50 "$(elt).on('click', ...)" lines. Any tips?
|
# ? Nov 15, 2014 06:18 |