What's beyond Rails?

[James Toomey]

Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general. I've done web development with PHP,
ColdFusion, and ASP, and being able to use Ruby in doing so (especially
with Rails' well-designed database interactivity) is certainly a
welcome change. However, the general model is still the same, in terms
of using code to write out HTML to an essentially-static page. The HTML
interface is still such a far cry from the things you can do with a
rich client. For ordering airline tickets on Travelocity or books on
Amazon, the web works great, but imagine trying to emulate Adobe
Photoshop via a web browser, or a spreadsheet like Excel.
It seems to me that there needs to be a next-generation of HTML that
enables web apps to truly be like rich client apps, and
I don't think the solution needs to be a faster connection that sucks
down the entire application in the form of massive Java applets every
time I want to use the program. Perhaps the solution does need to be a
"computer" that's designed from the ground up as a web-enabled dumb
terminal, but that has forms and controls optimized so that they
require minimal data inflow to tell them what to do.
To me, this would make the web incredibly more useful (and would put
serious potential into the claim that Google wants to become a web
operating system). If I've purchased Adobe Photoshop (or rented it, as
I'm sure will be the more likely model), instead of loading it on every
computer I use, why can't I get to Photoshop at any computer in the
world merely by logging into my personal website and getting access to
every software program I own or am renting? Why would it need to be
reloaded at every computer? This is particularly annoying when you're
visiting a friend in another city for a weekend, and jump onto his
computer to check email or show him how to do something useful, and
think, "I wish I had App X loaded on here right now."
I was disappointed to see Google Suggest being touted as innovative; it
seems to indicate that Google's going to stay within the existing web
realm and not try anything really new (as I read on the web somewhere,
"for a web app, Google Suggest is neat; for a desktop app, it's so
1995"). For all of Google's deep pockets and reputation as innovative,
I expected to see them partner up with a hardware manufacturer and try
something dramatically different.

 

[Douglas Livingstone]

Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general.

That's what Macromedia is trying to sell you!

Flash MX with Flash Communication Server.

It isn't quite fast enough to write photoshop in it, but that's what
people are trying to do.

On the other end, if we could get programmable SGV (imo we need a
"canvas" of some sort to get close to excel apps) there might be
something there, or you could try XBL/XUL of some sort. (I'd love to
be able to do client side Ruby XBL interfaces...)

Douglas

 

[B. K. Oxley (binkley)]

That's what Macromedia is trying to sell you!

What about interpreting XUL in Ruby? A Google search on <<ruby xul>>
does turn up some material. There is this intersting blog post about a
fellow experimenting with Rails + XUL:

http://www.zedshaw.com/blog/programming/ruby_xul.html

Or one could use a YAML version of XUL, I suppose.


Cheers,
--binkley

 

[Francis Hwang]

There's an inherent trade-off: Compared to desktop apps, web apps are
pretty crappy interaction-wise, but you can use web apps in a lot more
places. There are lots of efforts to bring more rich interactivity to
web apps: Java, Flash, AJAX, XForms, even Mozilla's XUL might count
depending on how you look at it. There's no clear standard for how to
do these things, so there's a lot of messiness and it might take some
time for everything to get sorted out.

Personally I'm also a little concerned about how highly dynamic sites
push back against other web efforts. AJAX-y sites are hard to make
accessible to the blind, and from what I've seen they tend to break
REST, as well. REST used to be a largely academic concern, but it's
only now that we're starting to pass around URIs as permanent tokens
(technorati, del.icio.us, etc.) and that's a big part of REST. If I
never see another session variable in a URI it'll be too soon ...

Anyway, getting Photoshop in an online app is going to take some doing.
When you're running a gaussian blur on a 2 MB image, you want to be as
close to the metal as possible. You wouldn't want to do that in
Javascript.

p.s. Rich Kilmer's Flash app Alph was supposed to help with this whole
issue, Rich are you still working on it?

Somewhat off-topic rant: This isn't so much a dig at Rails but a
critique of HTML in general. I've done web development with PHP,
ColdFusion, and ASP, and being able to use Ruby in doing so (especially
with Rails' well-designed database interactivity) is certainly a
welcome change. However, the general model is still the same, in terms
of using code to write out HTML to an essentially-static page. The HTML
interface is still such a far cry from the things you can do with a
rich client. For ordering airline tickets on Travelocity or books on
Amazon, the web works great, but imagine trying to emulate Adobe
Photoshop via a web browser, or a spreadsheet like Excel.
It seems to me that there needs to be a next-generation of HTML that
enables web apps to truly be like rich client apps, and
I don't think the solution needs to be a faster connection that sucks
down the entire application in the form of massive Java applets every
time I want to use the program. Perhaps the solution does need to be a
"computer" that's designed from the ground up as a web-enabled dumb
terminal, but that has forms and controls optimized so that they
require minimal data inflow to tell them what to do.
To me, this would make the web incredibly more useful (and would put
serious potential into the claim that Google wants to become a web
operating system). If I've purchased Adobe Photoshop (or rented it, as
I'm sure will be the more likely model), instead of loading it on every
computer I use, why can't I get to Photoshop at any computer in the
world merely by logging into my personal website and getting access to
every software program I own or am renting? Why would it need to be
reloaded at every computer? This is particularly annoying when you're
visiting a friend in another city for a weekend, and jump onto his
computer to check email or show him how to do something useful, and
think, "I wish I had App X loaded on here right now."
I was disappointed to see Google Suggest being touted as innovative; it
seems to indicate that Google's going to stay within the existing web
realm and not try anything really new (as I read on the web somewhere,
"for a web app, Google Suggest is neat; for a desktop app, it's so
1995"). For all of Google's deep pockets and reputation as innovative,
I expected to see them partner up with a hardware manufacturer and try
something dramatically different.

Francis Hwang
http://fhwang.net/

 

[Jeffrey Moss]

Yeah we all hate HTML I'm sure, us programmer types (ruby programmers no
less). SGML is the worst man, but thats what we're stuck with, it aint going
away any time soon.

You share my same vision, of applications like photoshop being written for a
web browser, a subscription model, those are the kind of apps I'm interested
in developing. Use google maps as an example of an innovative application.
Get real good at Javascript.

I have a DHTML version of lemmings bookmarked on my browser at home. Its
pretty impressive for a DHTML only app but it runs slow as hell, for
LEMMINGS! Lemmings ran faster on my old sega game gear as a kid. It's a real
shame we're stuck with this mess of semi-interoperable technologies. Flash
seems to be the best thing to use if you want to write a truly immersive
app, credit goes to the last guy to mention this.

-Jeff

----- Original Message -----
From: "James Toomey" <[email protected]>
Newsgroups: comp.lang.ruby
To: "ruby-talk ML" <[email protected]>
Sent: Wednesday, April 13, 2005 1:24 PM
Subject: What's beyond Rails?

 

[Richard Kilmer]

Yes indeed I am...but first...

I am working on implementing on open-source set of components in Flash (
http://actionstep.org ). Its a port of Cocoa/NextStep/OpenStep to
ActionScript. Its a big project, but its going to be the focus of my
efforts (in my day job) so IT IS going to advance quickly.

Alph will bridge into this component set (rather than Macromedia's
bug-ridden slow set). If we implement NIBs (serialized user interfaces) and
an Interface Builder type of app, then it would be possible to load a remote
UI and control it from a rails app via Alph...that would be a kick-ass long
term solution for RIAs.

Best,

Rich

 

[Matt Pelletier]

The underlying issue is that HTTP was never designed to do what it is
being used to do. Much like HTML is now doing things it was never
designed to do. Designers took HTML and starting using it for layouts,
like they were used to with Desktop publishing tools. After the mess of
nested tables and FONT tags, CSS came around and became an elegant
solution. HTTP is being asked to pretend it's not stateless. Fortunately
people have spent a lot of time thinking about this. Unfortunately not
all of the ideas are good.

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.

2. Ajax
Ah, asynchronous requests, in-page, you say? Beautiful. No more posting
back (at least not continuously)? Great. I can see the faces of a
thousand web developers as they anxiously got their invite to gmail
(back before they were being given away in wheelbarrows), and watched in
awe as the 'view source' command produced not much more than a gigantic
javascript library. We've since seen other things like Google maps, and
Tada list, and so on. Beyond giant companies dedicating teams of people
for specific apps like Google does, I expect RoR to be the 'platform'
pushing the envelope with this.

Unfortunately, Javascript is not going to be doing Photoshop-like work
anytime soon.

3. RIA
Macromedia has been pushing what it calls 'Rich Internet Applications'.
The idea is simple. 99% of browsers have Flash installed, with PLENTY of
spare CPU cycles to do the graphics work. Flash can make asynchronous
calls like Ajax's HTTPXmlRequest.

Recent versions of Flash (MX, MX 2004) have moved in the direction of
App development, with form controls, theming, and more powerful
ActionScript. You can either write directly in Actionscript, or you can
also use it's developer IDE Flex to write in an XML spec Macromedia
developed (cleverly dubbed MXML). The RIA platform is setup like so
(correct me if I'm wrong here): You get Flex Server running, and develop
RIAs using MXML (MacromediaXML), and Flex server turns them into Flash
forms. Neat. It's still maturing, but I think ultimately it's quite
promising.

Macromedia even has a desktop wrapper for flash RIA apps called Central.
You can download modules like a weather checker, etc. It sort of has an
OS X Expose widget look about it. It's a resource pig and it's slow, but
again, so was (er.. is) Java. That's what happens when you build your
own graphics layer.

4. Dumb Terminals / Thin Clients
This one has been tried again and again and there's no great solution.
Microsoft released a version of Windows for thin clients. IBM dumped a
ton of money into this. Ultimately people don't want to have just thin
clients. They want a hard drive, music, etc. Google's ability to make
cheap server farms is just as important as their ability to make
searches effective. I wouldn't rule them out from trying anything right
now, but I don't think they're after desktop software like photoshop.
Their position seems to be that the overall paradigm has changed from
desktop-run to Internet run. Just read Paul Graham's 'The Other Road
Ahead').

http://www.paulgraham.com/road.html

So what comes after? I don't know. HTTP is an inherently flawed way to
use the Internet if you want desktop-like apps like photoshop, but the
web has such saturation that people have and will continue to try to
make it work.

 

[Luke Renn]

The underlying issue is that HTTP was never designed to do what it is
being used to do. Much like HTML is now doing things it was never
designed to do. Designers took HTML and starting using it for layouts,

I've been real impressed with the mozilla framework. I wonder if
anyone has gotten around to writing ruby binding yet. I'm suprised
more application aren't written using it to be honest.

 

[Curt Hibbs]

I've been real impressed with the mozilla framework. I wonder if
anyone has gotten around to writing ruby binding yet. I'm suprised
more application aren't written using it to be honest.

It was started, but it has not been active for a couple years. From what
I recall, it was to the point where you could write XPCOM components in
Ruby. What was still needed was to be able to use Ruby along with
JavaScript in handling the XUL UI scripting.

Curt

 

[Juraci Krohling Costa]

------=_Part_4436_21895812.1113426385196
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

*brain search: web os*

1 Result found: myWebOs.com <http://myWebOs.com>

Does somebody remembers something about mywebos.com <http://mywebos.com>? I=
t=20
was a project to develop an "entire" OS web-based. Obviously, you still=20
needs a "real OS" to boot, but everything was on myWebOs: spreasheets,=20
"word" documents, email client, etc etc etc. I don't know when exactly they=
=20
were gone, and where exactly they stopped, but that was a great idea.
Some URL's that I found on google, to make sure I'm not nuts =3D)

http://www.xent.com/nov99/0465.html
http://www.pcworld.com/news/article/0,aid,14077,00.asp

regards,
juca

=20
The underlying issue is that HTTP was never designed to do what it is
being used to do. Much like HTML is now doing things it was never
designed to do. Designers took HTML and starting using it for layouts,
like they were used to with Desktop publishing tools. After the mess of
nested tables and FONT tags, CSS came around and became an elegant
solution. HTTP is being asked to pretend it's not stateless. Fortunately
people have spent a lot of time thinking about this. Unfortunately not
all of the ideas are good.
=20
1. Post-backs
I have wasted plenty of time trying to work around ASP.NET<http://ASP.NET=
's=20
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.
=20
2. Ajax
Ah, asynchronous requests, in-page, you say? Beautiful. No more posting
back (at least not continuously)? Great. I can see the faces of a
thousand web developers as they anxiously got their invite to gmail
(back before they were being given away in wheelbarrows), and watched in
awe as the 'view source' command produced not much more than a gigantic
javascript library. We've since seen other things like Google maps, and
Tada list, and so on. Beyond giant companies dedicating teams of people
for specific apps like Google does, I expect RoR to be the 'platform'
pushing the envelope with this.
=20
Unfortunately, Javascript is not going to be doing Photoshop-like work
anytime soon.
=20
3. RIA
Macromedia has been pushing what it calls 'Rich Internet Applications'.
The idea is simple. 99% of browsers have Flash installed, with PLENTY of
spare CPU cycles to do the graphics work. Flash can make asynchronous
calls like Ajax's HTTPXmlRequest.
=20
Recent versions of Flash (MX, MX 2004) have moved in the direction of
App development, with form controls, theming, and more powerful
ActionScript. You can either write directly in Actionscript, or you can
also use it's developer IDE Flex to write in an XML spec Macromedia
developed (cleverly dubbed MXML). The RIA platform is setup like so
(correct me if I'm wrong here): You get Flex Server running, and develop
RIAs using MXML (MacromediaXML), and Flex server turns them into Flash
forms. Neat. It's still maturing, but I think ultimately it's quite
promising.
=20
Macromedia even has a desktop wrapper for flash RIA apps called Central.
You can download modules like a weather checker, etc. It sort of has an
OS X Expose widget look about it. It's a resource pig and it's slow, but
again, so was (er.. is) Java. That's what happens when you build your
own graphics layer.
=20
4. Dumb Terminals / Thin Clients
This one has been tried again and again and there's no great solution.
Microsoft released a version of Windows for thin clients. IBM dumped a
ton of money into this. Ultimately people don't want to have just thin
clients. They want a hard drive, music, etc. Google's ability to make
cheap server farms is just as important as their ability to make
searches effective. I wouldn't rule them out from trying anything right
now, but I don't think they're after desktop software like photoshop.
Their position seems to be that the overall paradigm has changed from
desktop-run to Internet run. Just read Paul Graham's 'The Other Road
Ahead').
=20
http://www.paulgraham.com/road.html
=20
So what comes after? I don't know. HTTP is an inherently flawed way to
use the Internet if you want desktop-like apps like photoshop, but the
web has such saturation that people have and will continue to try to
make it work.
=20
=20

=20
=20

--=20
juraci krohling costa
http://jkcosta.info

------=_Part_4436_21895812.1113426385196--

 

[Ezra Zygmuntowicz]

--Apple-Mail-6--172866516
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
charset=US-ASCII;
format=flowed

You could take a peek at amf4r. It's on the raa. This lib lets you
write your front end in flash and use ruby on the server instead of
macromedia's proprietary communication server. amf stands for action
message format and its a binary format used to ferry objects back and
forth between actionscript and ruby. You can pass just params or arrays
or hashes but the coolest thing is you can basically instantiate your
server side ruby objects in actionscript and call methods on them from
flash. It's pretty cool because of the flexibility of flash interfaces.
It's not going to let you write server side photoshop any time soon but
its a huge leap forward as far as interfaces go above html.

-Ezra

That's what Macromedia is trying to sell you!

Flash MX with Flash Communication Server.

It isn't quite fast enough to write photoshop in it, but that's what
people are trying to do.

On the other end, if we could get programmable SGV (imo we need a
"canvas" of some sort to get close to excel apps) there might be
something there, or you could try XBL/XUL of some sort. (I'd love to
be able to do client side Ruby XBL interfaces...)

Douglas

-Ezra Zygmuntowicz
Yakima Herald-Republic
WebMaster
509-577-7732
(e-mail address removed)

--Apple-Mail-6--172866516--

 

[Francis Hwang]

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/

 

[Peter Suk]

You could take a peek at amf4r. It's on the raa. This lib lets you
write your front end in flash and use ruby on the server instead of
macromedia's proprietary communication server. amf stands for action
message format and its a binary format used to ferry objects back and
forth between actionscript and ruby. You can pass just params or
arrays or hashes but the coolest thing is you can basically
instantiate your server side ruby objects in actionscript and call
methods on them from flash. It's pretty cool because of the
flexibility of flash interfaces. It's not going to let you write
server side photoshop any time soon but its a huge leap forward as far
as interfaces go above html.

What would be really cool would be a way for a server-side Ruby program
to instantiate Flash GUIs. (Maybe written as a TK emulation.)

--Peter

 

[James Britt]

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.

I take it you either do not use the XmmlHttpRequest object, or are paid
to read about it?




Actually, from poking around MSDN, I get the sense that postbacks are
mix of XMlHtppRequest calls (or the like) and DHTML. Client-side form
objects send HTTP posts back to the server, where request handlers reply
with some data, and the page is then updated. Remote scripting, again.

James

 

[James Britt]

What would be really cool would be a way for a server-side Ruby program
to instantiate Flash GUIs. (Maybe written as a TK emulation.)

I believe this thread has already mentioned the Alph project. And you
could use Laszlo with Ruby.


James

--

http://www.ruby-doc.org
http://www.rubyxml.com
http://catapult.rubyforge.com
http://orbjson.rubyforge.com
http://ooo4r.rubyforge.com
http://www.jamesbritt.com

 

[Mark Roseman]

What would be really cool would be a way for a server-side Ruby program
to instantiate Flash GUIs. (Maybe written as a TK emulation.)

Yes, this would be great!

A while back I did a similar thing, using Tcl (with a Tk emulation
layer) on the server to create and drive a Java applet GUI. Worked very
well for what it did, but would be nicer to see the client piece done in
Flash instead of Java for all kinds of reasons.

For the curious, there's an old paper about it (the work itself wasn't
open source) at http://www.markroseman.com/pubs/proxytk.pdf.

Mark

 

[Matt Pelletier]

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

 

[Stephen Haberman]

Actually, from poking around MSDN, I get the sense that
postbacks are mix of XMlHtppRequest calls (or the like)
and DHTML.

Microsoft does have some docs on remote scripting, but "postback" in ASP.NET
terminology has nothing to do with Ajax technologies.

In ASP.NET, "postback" means someone GETs a page and then POSTs the form
back to the same page. It simply means the user has POSTed back to the same
page they were just viewing.

The purpose (or perhaps just a side effect), is that ASP.NET can then
serialize the page object's state into a hidden form field behind the
scenes.

1) A user GETs FooPage.aspx, an HTML file with ASP.NET markup, that also has
a FooPage.cs "codebehind" .NET class with relevent business/display logic,
etc.

2) FooPage.cs does some stuff and can put anything it wants to keep/persist
into this ViewState hash table

3) FooPage.html is written out to the browser - and the ViewState hash table
is base64 encoded into a hidden HTML form field

4) User does some stuff and hits submit to POST back into FooPage.html

5) ASP.NET sees the hidden HTML form field, and says "oh, this is a
postback!", and deserializes it into the ViewState for the request's
instance of FooPage.cs

So, summarizing, postback allows ASP.NET to have this magic ViewState hash
table that persists across requests, not via a session, but by riding along
in the HTML.

ASP.NET developers frequently do "super.isPostBack()" (or is it
"base.isPostBack()"? -- too many languages) calls in their Page_OnLoad
method to tell whether their ViewState is brand new and they should do
initialization and put stuff in it, or if it already has stuff in it from
the previous request.

Also, just FYI, on the few ASP.NET projects I've done I've found the
ViewState/postback stuff to be pretty slick. Its pretty well hidden behind
the scenes. And from what I've seen, successfully leveraged by a whole lot
of their built-in ASP.NET controls/widgets/etc. That being said, I didn't do
anything too complicated, so given the original posters frustrations with
postback, it seems like YMMV.

- Stephen

 

[James Britt]

Here goes.

Postbacks do not, unfortunately, use XMLHttpRequest (comment to James)
Ah.
...
I hope I've explained this clearly.

Yes. Yow.

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).

Indeed, and it seems the sort of thing that encourages poor Web app
design because it masks certain difficulties.

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

Thanks for the explanation.


James

 

[James Britt]

Microsoft does have some docs on remote scripting, but "postback" in ASP.NET
terminology has nothing to do with Ajax technologies.

In ASP.NET, "postback" means someone GETs a page and then POSTs the form
back to the same page. It simply means the user has POSTed back to the same
page they were just viewing.

The purpose (or perhaps just a side effect), is that ASP.NET can then
serialize the page object's state into a hidden form field behind the
scenes.

<snip/>

Thanks for the explanation. This is handy to know if I ever get around
to more C#/ASP.net coding.

James