DevConn Highlights--Browsers, Script, and Callbacks

Published 09 November 05 06:47 PM | despos

A few questions arisen yesterday in the lounges of ASP.NET DevConnections. 

After seeing the wonders of Atlas, is server-side programming dead?

No. Atlas is still based on server controls. How could it be otherwise? If not, we'll all be coding an enriched Javascript dialect in the next 12 months.

What about downlevel browsers?

What downlevel? Ajax-like features are now supported by 90% and more of the browsers today. Some quick (and hopefully not random) numbers that I've read somewhere. (OK it's not exactly a scientific method.) IE and Firefox alone approximately reach the critical mass of 95% (85+10). Plus Netscape 6 and higher, plus Safari 1.2 and higher, plus Opera 8 and higher. All considered, isn't it about 90% of the current audience?

Why ASP.NET Script Callbacks post the viewstate?

There should be a reason. There's certainly a reason. But it's currently beyond me.

Comments

# Ron Buckton said on November 9, 2005 02:20 PM:

ASP.NET 2.0 callbacks are designed to augment the existing server-side postback behavior. For all of the callback aware controls that ship with 2.0 (GridView, TreeView, etc.), having the page state during the callback is necessary for server-side event handlers to process the code in an expected manner. Callbacks in most cases are enabled when a control written to use mostly server-side code has its "EnableCallbacksForX" property set.

When you are working with Atlas however, you are expecting to make tradeoffs between client-side functionality and what you expect to be able to do on the server. The expected behavior in these cases is not to have the viewstate (and as a result the state of all controls), available on the client as in most cases you are using atlas (or AJAX) to hook into a web service or the like where viewstate is not of consequence.

My major concern with callbacks in 2.0 is that while viewstate is necessary to restore the page state, values of controls that have changed may not be. If you were to implement a search form with a gridview that had client callbacks enabled, the expected behavior is that the results when paging shouldn't change until I click "search" again on the form, however with client callbacks if the search button is merely used to wire up a DataSource control and that control uses a ControlParameter to get values to supply to the search method then any change to any field on the form between two callbacks would change the criteria for the DataSource control's Select method. This odd behavior isn't very obtrusive but can sometimes lead to confusion.

I've taken to stuffing fields for any type of search operation in an asp:hiddenfield or in some kind of viewstate and using a ControlParameter which points to those fields. The "seach" button would then cache the values from the visible fields into the hidden fields then hook up the DataSource control.

# Sergio Pereira said on November 9, 2005 05:44 PM:

The viewstate is posted back by the callbacks so that you can use the controls' properties in your callback code. You can do stuff like statesDropdown.SelectedItem, etc. To get the control properties working correctly you need the viewstate.

# Oliver Martin said on November 9, 2005 05:54 PM:

...but do you get the values of all changed controls? If you i.e. change the text value of two textboxes and invoke a client script callback, do I get the new values of both of the elements? As I can remember, it does not.

I'm using AJAX.Net and using separate classes for the methods I want to call. I see this as a different way, not to access the page. My application is working with a lot of DHTML code, so the controls are changing in the client page livecycle, and this I do not get back on the server, never - not without a complete postback.

# RichB said on November 10, 2005 05:50 AM:

> Why ASP.NET Script Callbacks post the viewstate?

ASP.Net is about sending the description of a user interface between server and client. Thus, the server needs to perfectly be able to model the state of the client.

AJAX is about sending data between server and client. Thus the client has to be totally in control of its user interface, not the server.

Put another way, ASP.Net is like a green screen, dumb terminal, remote desktop. Whereas AJAX is like web services.

# Allen Guest said on December 2, 2005 10:39 AM:

In a recent project, I decided to jump into AJAX 100% and the model basically came to writing .NET controls that rendered dynamic javascript that was smart enough to update/render itself from AJAX query results. In the end, the properties and methods exposed by the server view of the .NET control determined what javascript to render as part of an initial setup state as well as future control behavior.

It does complicate the code as far as writing the .NET controls but simplifies the usage as well as increases the performance and enriches the user experience. I am frankly tired of the monolothic viewstate postback approach as it really had an impact on large, complex applications.

Leave a Comment

(required) 
(required) 
(optional)
(required)