>> Actually, I have a question. How is a site like this even physically 
>> possible in the first place? How can you send a request to the server 
>> and receive a response without reloading the entire page? 
> 
> The term you're looking for is AJAX, which is a method of programming 
> web pages that uses the XMLHttpRequest function. If you understand 
> generally how XMLHttpRequest works, you'll understand how this works.

Right, so... if I'm understanding this right, XMLHttpRequest allows a 
mere script to instruct the browser to send an HTTP request, and return 
the body of the response as data, which the script can then further 
manipulate? (Rather than, say, just nagivating to another page, in which 
case the script can't process the data because the script won't even 
*exist* any mroe...)

I had no idea that you can actually do that...

(Then again, Wikipedia's example code seems to show JavaScript doing 
exception handling too, which I had no idea was possible.)

Post a reply to this message

Invisible wrote:

> Right, so... if I'm understanding this right, XMLHttpRequest allows a 
> mere script to instruct the browser to send an HTTP request, and return 
> the body of the response as data, which the script can then further 
> manipulate?

http://www.w3.org/TR/XMLHttpRequest/#the-xmlhttprequest-interface

Seems reasonably clear...

Post a reply to this message

> http://tryhaskell.org/

The tutorial was good up until step 7, then the line:

> let villain = (28,"chirs") in fst villain

Made no sense at all.  I get it returns 28, but it's confusing what's going 
on, why the need for a variable (I assume villain is a variable name?).  I 
would have thought that writing 'fst (28,"chirs")' would be the thing to do 
to return 28? (I guess that fst returns the first element of a list?)

A lot of guessing and confusing on my part without much explanation...

Post a reply to this message

scott wrote:
>> http://tryhaskell.org/
> 
> The tutorial was good up until step 7, then the line:
> 
>> let villain = (28,"chirs") in fst villain
> 
> Made no sense at all.

I agree. Several concepts introduced at once without much explanation.

(Apparently the author also agrees, and is looking at trying to do 
better...)

Post a reply to this message

Invisible wrote:
> Right, so... if I'm understanding this right, XMLHttpRequest allows a 
> mere script to instruct the browser to send an HTTP request, and return 
> the body of the response as data, which the script can then further 
> manipulate? (Rather than, say, just nagivating to another page, in which 
> case the script can't process the data because the script won't even 
> *exist* any mroe...)

Exactly, yes.

> I had no idea that you can actually do that...

Well, there ya go. MS actually invented that technique with ActiveX for 
their Outlook web thing, and everyone else picked up on it and turned it 
into a standard.

> (Then again, Wikipedia's example code seems to show JavaScript doing 
> exception handling too, which I had no idea was possible.)

Huh. I don't remember ever doing that, but I guess if the browser can tell 
you about errors, then there's probably some way to catch them.

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

Darren New wrote:

>> I had no idea that you can actually do that...
> 
> Well, there ya go. MS actually invented that technique with ActiveX for 
> their Outlook web thing, and everyone else picked up on it and turned it 
> into a standard.

Looking at the W3C standard spec, there seems to be *huge* abouts of 
tricky processing and non-obvious behaviour which strongly looks as if 
it's only there for backwards compatibility (i.e., because this is the 
ad hoc way the first implementation happened to do it).

Man, web stuff is messy...

Post a reply to this message

Invisible wrote:
> ad hoc way the first implementation happened to do it).

Yeah. You want to know who started the browser wars? Look at your agent 
string. :-)

There are also a lot of standards that got changed in subtle ways that broke 
a lot of stuff, because the first spec was basically "here's how we do it." 
For example, Netscape said "Here's how we do cookies.  Yadda yadda only save 
20 per site yadda yadda."  IE did the same thing.  W3C comes along and makes 
a standard that says any number of cookies per site. Lots of web sites that 
for some stupid reason depended on only having 20 cookies fail with 
W3C-compliant browsers, continuing to work with IE *because* MS won't follow 
the standards and instead wants the web pages to work right for their 
customers, even when the pages on the server are stupidly coded. Launch 
complaining in 3... 2... 1....

-- 
Darren New, San Diego CA, USA (PST)
   The question in today's corporate environment is not
   so much "what color is your parachute?" as it is
   "what color is your nose?"

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> I had no idea that you can actually do that...

  You clearly haven't used gmail.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> I had no idea that you can actually do that...
> 
>   You clearly haven't used gmail.

Indeed. But I have, at least, heard of it. ;-)

Post a reply to this message

> Right, so... if I'm understanding this right, XMLHttpRequest allows a mere 
> script to instruct the browser to send an HTTP request, and return the 
> body of the response as data, which the script can then further 
> manipulate?

What happens when the user presses the back button after such a process? 
Can the script intercept this and provide its own "back" functionality?

I've definitely got annoyed by some sites where you hit the back button and 
it takes you to a site you were looking at 10 minutes ago, because all the 
things you've been doing on this site haven't actually loaded a new page...

Post a reply to this message