Here goes.

Postbacks do not, unfortunately, use XMLHttpRequest (comment to James)

Postback allows you to treat form controls similarly to those in desktop 
apps, in that they appear to maintain 'state'. Say you're on a shipping 
address page, with a country dropdown and province dropdown. When you 
change the country dropdown, you want it to load the provinces in that 
country.

Barring the obvious alternatives in this simple example (AJAX, JS 
preloading, etc.), the form has to go back to the server to get the new 
list of provinces, but you want to do this without losing the 'state' of 
the page (which mostly means the current state/value of all the controls 
in the page), or force unecessary trips to the database for dynamic data 
  on the page that is not affected (i.e. a shopping cart list). So when 
you change the country, the 'onchange' event triggers a javascript 
function that submits the form. ASP.NET will read in this POSTed form, 
determine what you were trying to do (which I explain below), do it, 
then send the page back with the state restored, minus the changes 
caused by your action (new provinces in the dropdown).

ASP.NET is able to maintain state by storing a 'snapshot' of the initial 
page state (when it was first sent to you based on an HTTP GET). This 
snapshot is just a hidden input with an encoded, concatenated set of 
name/value pairs, called the PostBackData. When a control triggers the 
page to post back, ASP.NET will recognize it is doing so, and will read 
in that page's PostBackData field. It uses this to determine what it 
sent to you BEFORE you changed any fields. It then reads in the CURRENT 
values from the POST variables, allowing it to see what is different 
(the country field changed). Then, for any control that changed, it 
raises an event. This is where you can do your magic and tell it to 
affect the *new* resulting state (in this case different provinces). 
Right before it sends you the new page, it takes a new snapshot and 
stores it in the same PostBackData field. Continuity.

The value for this technique is less obvious when you're dealing with 
simple forms (by this point even firefox remembers text fields and 
checkbox fields for you). It's more useful when dealing with things that 
technically are not form fields, such as a table of data that was 
generated by one of ASP.NET's WebControls (i.e. the shopping cart). If 
you're changing the country dropdown, you don't want ASP.NET to go and 
pull the rest of the database-driven data fields all over again (i.e. if 
you keep a shopping cart list stored in one of these). Saving yourself a 
database trip is nice, but beside the point. The main idea is that the 
PostBackData's hidden input value tells ASP.NET what the page looked 
like BEFORE it posted back. And, since it's looking at this BECAUSE it 
posted back, it can compare them and take action based on the difference.

I hope I've explained this clearly.

Generally speaking, Postback is a good idea, and it works, but I don't 
think it's necessarily the most elegant solution to maintaining state. 
The postback string can get very long, and overall it's a band-aid to a 
larger problem (statelessness).

Incidentally, there is a postback generator for RoR, by Tobias Leuke, 
which I have not looked at.

http://wiki.rubyonrails.com/rails/show/Generators

There is a good explanation of ASP.NET's Postback here. This is by far 
the most straightforward explanation I've ever read (and I've read 
plenty), and even here it seems like a big hassle to deal with.

http://www.15seconds.com/issue/020102.htm

Matt


Francis Hwang wrote:
> 
> On Apr 13, 2005, at 4:38 PM, Matt Pelletier wrote:
> 
>> 1. Post-backs
>> I have wasted plenty of time trying to work around ASP.NET's postback 
>> architecture. For simple apps it indeed will ostensibly work like a 
>> WinForm. For anything moderately complex, you can get into a mess of 
>> issues when designing controls and components. Blech. I think the 
>> entire premise of postbacks is flawed (hopefully I'm not naively 
>> soured just by MS's implementation). Rather, relying on a postback 
>> paradigm to mimic statefulness is flawed.
> 
> 
> For those of us who don't know, care to post a quick explanation of what 
> a post-back is? I Googled it but only got a bunch of ASP.NET pages. And 
> if I'm gonna read about Microsoft APIs, somebody better be paying me.
> 
> Francis Hwang
> http://fhwang.net/
> 
> 
> 
>