Opinions: Is Remote Scripting Worthwhile?

[lisa]

One of the things I hate the most about ASP.NET is the postback of an
entire page just to update a single field. So I was looking around,
and I came across Remote Scripting.

See, when I write ASP pages, I usually have a hidden iframe on the page
that I post to. And onload, that hidden page copies the results back
up to the parent. I work in an IE only environment, so I can get away
with that.

And it's nice. Seamless. It's nice for the user, and I don't have to
deal with refilling fields unnecessarily.

But the same trick doesn't work with ASP.NET, because it's server
based. Remote Scripting, in theory, should do much the same thing.

So here are my questions:

* Have any of you worked with Remote Scripting in your ASP.NET apps?

* Is it worth it? Is it a mess? If I decide to jump into the deep
end, am I going to regret it, or is this a practical solution?

Opinions for and against are welcome. I'm wholly ignorant on the
subject.

[Scott Allen]

There is a feature in ASP.NET by the name of script callbacks that
will do what I think you need. Dino has a good article explaining the
details of the feature, and also how you could implement the feature
with today's 1.1 apps:
http://msdn.microsoft.com/msdnmag/is...8/CuttingEdge/

HTH,

--
Scott
http://www.OdeToCode.com/blogs/scott/

On 22 Apr 2005 07:08:02 -0700, li**@starways.net wrote:

One of the things I hate the most about ASP.NET is the postback of an
entire page just to update a single field. So I was looking around,
and I came across Remote Scripting.

See, when I write ASP pages, I usually have a hidden iframe on the page
that I post to. And onload, that hidden page copies the results back
up to the parent. I work in an IE only environment, so I can get away
with that.

And it's nice. Seamless. It's nice for the user, and I don't have to
deal with refilling fields unnecessarily.

But the same trick doesn't work with ASP.NET, because it's server
based. Remote Scripting, in theory, should do much the same thing.

So here are my questions:

* Have any of you worked with Remote Scripting in your ASP.NET apps?

* Is it worth it? Is it a mess? If I decide to jump into the deep
end, am I going to regret it, or is this a practical solution?

Opinions for and against are welcome. I'm wholly ignorant on the
subject.

[Patrice]

I don't see why it would work wiht ASP but not with ASP.NET (actually we
used this in one of our ASP.NET page to update a dropdownlist).

As a side note ASP.NET 2.0 will include these kind of features (I believe
it's called server side callbacks and based on XMLHTTP).

Try for example :
http://msdn.microsoft.com/msdnmag/is...8/CuttingEdge/

Patrice

--

<li**@starways.net> a écrit dans le message de
news:11**********************@l41g2000cwc.googlegr oups.com...

One of the things I hate the most about ASP.NET is the postback of an
entire page just to update a single field. So I was looking around,
and I came across Remote Scripting.

See, when I write ASP pages, I usually have a hidden iframe on the page
that I post to. And onload, that hidden page copies the results back
up to the parent. I work in an IE only environment, so I can get away
with that.

And it's nice. Seamless. It's nice for the user, and I don't have to
deal with refilling fields unnecessarily.

But the same trick doesn't work with ASP.NET, because it's server
based. Remote Scripting, in theory, should do much the same thing.

So here are my questions:

* Have any of you worked with Remote Scripting in your ASP.NET apps?

* Is it worth it? Is it a mess? If I decide to jump into the deep
end, am I going to regret it, or is this a practical solution?

Opinions for and against are welcome. I'm wholly ignorant on the
subject.

[Bruce Barker]

the approach is making a comeback. there are more modern approaches then asp
RS (whioch used a java applet or iframe for backend communication). most
modern browsers support calling webservices (IE requires a behavior as its
not built in like other browser), and most support a low level object
XMLHTTP (oddly enough first stolen from IE by netscape, but now common) that
can be used to pass xml back

asp.net 2.0 and google maps use this approach (though google uses iframes,
and the httpxml object to parse xml)

-- bruce (sqlwork.com)

<li**@starways.net> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

One of the things I hate the most about ASP.NET is the postback of an
entire page just to update a single field. So I was looking around,
and I came across Remote Scripting.

See, when I write ASP pages, I usually have a hidden iframe on the page
that I post to. And onload, that hidden page copies the results back
up to the parent. I work in an IE only environment, so I can get away
with that.

And it's nice. Seamless. It's nice for the user, and I don't have to
deal with refilling fields unnecessarily.

But the same trick doesn't work with ASP.NET, because it's server
based. Remote Scripting, in theory, should do much the same thing.

So here are my questions:

* Have any of you worked with Remote Scripting in your ASP.NET apps?

* Is it worth it? Is it a mess? If I decide to jump into the deep
end, am I going to regret it, or is this a practical solution?

Opinions for and against are welcome. I'm wholly ignorant on the
subject.

[clintonG]

The latest implementation is being called AJAX, a term which seems to be
catching on.
A(synchronous) JA(vascript) X(ml).

--
<%= Clinton Gallagher
METROmilwaukee (sm) "A Regional Information Service"
NET csgallagher AT metromilwaukee.com
URL http://metromilwaukee.com/
URL http://clintongallagher.metromilwaukee.com/
<li**@starways.net> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

One of the things I hate the most about ASP.NET is the postback of an
entire page just to update a single field. So I was looking around,
and I came across Remote Scripting.

See, when I write ASP pages, I usually have a hidden iframe on the page
that I post to. And onload, that hidden page copies the results back
up to the parent. I work in an IE only environment, so I can get away
with that.

And it's nice. Seamless. It's nice for the user, and I don't have to
deal with refilling fields unnecessarily.

But the same trick doesn't work with ASP.NET, because it's server
based. Remote Scripting, in theory, should do much the same thing.

So here are my questions:

* Have any of you worked with Remote Scripting in your ASP.NET apps?

* Is it worth it? Is it a mess? If I decide to jump into the deep
end, am I going to regret it, or is this a practical solution?

Opinions for and against are welcome. I'm wholly ignorant on the
subject.

[clintonG]

The latest implementation is being called AJAX, a term which seems to be
catching on.
A(synchronous) JA(vascript) X(ml).

--
<%= Clinton Gallagher
METROmilwaukee (sm) "A Regional Information Service"
NET csgallagher AT metromilwaukee.com
URL http://metromilwaukee.com/
URL http://clintongallagher.metromilwaukee.com/
<li**@starways.net> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

One of the things I hate the most about ASP.NET is the postback of an
entire page just to update a single field. So I was looking around,
and I came across Remote Scripting.

See, when I write ASP pages, I usually have a hidden iframe on the page
that I post to. And onload, that hidden page copies the results back
up to the parent. I work in an IE only environment, so I can get away
with that.

And it's nice. Seamless. It's nice for the user, and I don't have to
deal with refilling fields unnecessarily.

But the same trick doesn't work with ASP.NET, because it's server
based. Remote Scripting, in theory, should do much the same thing.

So here are my questions:

* Have any of you worked with Remote Scripting in your ASP.NET apps?

* Is it worth it? Is it a mess? If I decide to jump into the deep
end, am I going to regret it, or is this a practical solution?

Opinions for and against are welcome. I'm wholly ignorant on the
subject.

[Shahid Siddiqui]

We have been using REmote Scripting with a very large ASP.Net application
using -the free implementation from thycotic.com. It was nice and smooth

Shahid Siddiqui
Information Solutions Deptt.
E & Y Pakistan

"clintonG" <cs*********@REMOVETHISTEXTmetromilwaukee.com> wrote in message
news:O8**************@TK2MSFTNGP12.phx.gbl...

The latest implementation is being called AJAX, a term which seems to be
catching on.
A(synchronous) JA(vascript) X(ml).

--
<%= Clinton Gallagher
METROmilwaukee (sm) "A Regional Information Service"
NET csgallagher AT metromilwaukee.com
URL http://metromilwaukee.com/
URL http://clintongallagher.metromilwaukee.com/
<li**@starways.net> wrote in message
news:11**********************@l41g2000cwc.googlegr oups.com...

One of the things I hate the most about ASP.NET is the postback of an
entire page just to update a single field. So I was looking around,
and I came across Remote Scripting.

See, when I write ASP pages, I usually have a hidden iframe on the page
that I post to. And onload, that hidden page copies the results back
up to the parent. I work in an IE only environment, so I can get away
with that.

And it's nice. Seamless. It's nice for the user, and I don't have to
deal with refilling fields unnecessarily.

But the same trick doesn't work with ASP.NET, because it's server
based. Remote Scripting, in theory, should do much the same thing.

So here are my questions:

* Have any of you worked with Remote Scripting in your ASP.NET apps?

* Is it worth it? Is it a mess? If I decide to jump into the deep
end, am I going to regret it, or is this a practical solution?

Opinions for and against are welcome. I'm wholly ignorant on the
subject.