11–20 of 45 posts
Nice move! But one thing... The server should get updated first. Only after that should the UI value change. [Right now, its the reverse here.Is there any particular reason for such an implementation?]
I think the answer boils down to this: http://paulbuchheit.blogspot.com/2007/06/wasting-time-on-things-that-really-dont.html
(This is not meant to be a nasty sounding response.)
Earlier quoted context omitted.
Well, look at the code :) I did, it was educational. Node.href contains the values that are linked on the up/down arrows. // ping server var ping = new Image(); ping.src = node.href; return false; // cancel browser nav } The clever part is in using the image object as an ajax-like connection, response isn't check, and I'm not sure if it's async. Question: is this a common javascript idiom? Is it browser portable? Myn…
Er.. So that means it's a GET request, and GET requests which modify state on a website are bad. Things like Google Web Accelerator silently visit all the links on the page and cache the result in case you decide to visit that link. So there might be some problems for people using those (For example, their accelerator might accidentally upvote all the comments in every comment page they visit)
Earlier quoted context omitted.
Er.. So that means it's a GET request, and GET requests which modify state on a website are bad. Things like Google Web Accelerator silently visit all the links on the page and cache the result in case you decide to visit that link. So there might be some problems for people using those (For example, their accelerator might accidentally upvote all the comments in every comment page they visit)
Yep, I just confirmed this by viewing the source code, then visiting http://news.ycombinator.com/a?fnid=oO6e74w9Mq manually. It upvoted the "bandsintown" article. A misbehaved web accelerator could upvote every single article on the front page, and every comment in each comment page that they visit.
Earlier quoted context omitted.
Well, look at the code :) I did, it was educational. Node.href contains the values that are linked on the up/down arrows. // ping server var ping = new Image(); ping.src = node.href; return false; // cancel browser nav } The clever part is in using the image object as an ajax-like connection, response isn't check, and I'm not sure if it's async. Question: is this a common javascript idiom? Is it browser portable? Myn…
Er.. So that means it's a GET request, and GET requests which modify state on a website are bad. Things like Google Web Accelerator silently visit all the links on the page and cache the result in case you decide to visit that link. So there might be some problems for people using those (For example, their accelerator might accidentally upvote all the comments in every comment page they visit)
Earlier quoted context omitted.
Er.. So that means it's a GET request, and GET requests which modify state on a website are bad. Things like Google Web Accelerator silently visit all the links on the page and cache the result in case you decide to visit that link. So there might be some problems for people using those (For example, their accelerator might accidentally upvote all the comments in every comment page they visit)
palish, interesting. Something I've never thought about. Do web accelerators typically not follow POST requests?
Nice move! But one thing... The server should get updated first. Only after that should the UI value change. [Right now, its the reverse here.Is there any particular reason for such an implementation?]
Is there any particular reason for such an implementation? I think the answer boils down to this: http://paulbuchheit.blogspot.com/2007/06/wasting-time-on-things-that-really-dont.html (This is not meant to be a nasty sounding response.)
It probably doesn't matter much for a site like this, but it's one of those things that's just a good habit to get into. Perform validations first, then actions, then UI updates. And do the actions that are most reversible or most likely to fail first. If you have a POST that updates a DB table and sends an e-mail, update the database first, because there's no way to unsend that e-mail.
It's like comparing constants from the left in C or doing "literal".equals(var) in Java - each individual occurrence is trivial, but taken together, it can save you a lot of grief.
Edit: though looking at the source, it's done through an Image update. I don't think there's any way to trap failure with that implementation, so here, it really doesn't matter.
Earlier quoted context omitted.
Well, look at the code :) I did, it was educational. Node.href contains the values that are linked on the up/down arrows. // ping server var ping = new Image(); ping.src = node.href; return false; // cancel browser nav } The clever part is in using the image object as an ajax-like connection, response isn't check, and I'm not sure if it's async. Question: is this a common javascript idiom? Is it browser portable? Myn…
Er.. So that means it's a GET request, and GET requests which modify state on a website are bad. Things like Google Web Accelerator silently visit all the links on the page and cache the result in case you decide to visit that link. So there might be some problems for people using those (For example, their accelerator might accidentally upvote all the comments in every comment page they visit)
Anything that assumes that GET links can be arbitrarily followed will break stuff all over the web. GWA needs all kinds of heuristics to avoid that kind of thing. (maybe they avoid sending cookies or session ids?)
Earlier quoted context omitted.
Er.. So that means it's a GET request, and GET requests which modify state on a website are bad. Things like Google Web Accelerator silently visit all the links on the page and cache the result in case you decide to visit that link. So there might be some problems for people using those (For example, their accelerator might accidentally upvote all the comments in every comment page they visit)
It's just an adaptation of the old, non-js html, in which the arrows were just links, and it's written such that it will work in the old way if the js doesn't work for some reason (like I never bothered to test it with all the browsers). Anything that assumes that GET links can be arbitrarily followed will break stuff all over the web. GWA needs all kinds of heuristics to avoid that kind of thing. (maybe they avoid s…
Nice move! But one thing... The server should get updated first. Only after that should the UI value change. [Right now, its the reverse here.Is there any particular reason for such an implementation?]
Is there any particular reason for such an implementation? I think the answer boils down to this: http://paulbuchheit.blogspot.com/2007/06/wasting-time-on-things-that-really-dont.html (This is not meant to be a nasty sounding response.)
For things that are really important (sending an email or something) I'd check the reply, but for arrow clicking it's probably not worth the effort and delay.
Earlier quoted context omitted.
It's just an adaptation of the old, non-js html, in which the arrows were just links, and it's written such that it will work in the old way if the js doesn't work for some reason (like I never bothered to test it with all the browsers). Anything that assumes that GET links can be arbitrarily followed will break stuff all over the web. GWA needs all kinds of heuristics to avoid that kind of thing. (maybe they avoid s…
Except it's vulnerable to an iframe exploit. See: http://news.ycombinator.com/item?id=27615