Some thoughts about server callbacks and Ajax.NET

re: Some thoughts about server callbacks and Ajax.NET

Bertrand Le Roy — Mon, 18 Jul 2005 19:46:00 GMT

Etienne, WebParts and callbacks/ajax sure are interesting scenarios for the Orcas timeframe as well as for Atlas, but at this point we don't want to force WebParts as the infrastructure people would need to use to get these features. Portal features and better callbacks are orthogonal and we're more thinking about a user control or panel, which can be combined with WebParts but do not force one to use them.
It's interesting to consider, though, because of the way WebParts maintain and persist state, which is very different from what ordinary Controls do.
Thanks for the feedback.

re: Some thoughts about server callbacks and Ajax.NET

Etienne Richard — Fri, 15 Jul 2005 21:40:00 GMT

Friday 5:30 pm idea...

> One solution we've been thinking about for Orcas involves making the ViewState
> less monolythic and enabling the page to be broken into smaller mini-pages that
> would have their own isolated state and where local sequentiality of the callbacks
> would be less of a problem. The problem with such a model is that it becomes
> more difficult for these mini-pages to communicate with the rest of the page.

How about implementing better AJAX support for WebParts based solutions using each webpart as granularity? In such a scenario, "breaking pages into smaller mini-pages" = "defining webparts". WebParts communicate with each other using a provider-consumer connection model. The webpartmanager knows all the dependencies that exist between webparts at runtime.

In this model, WebParts would serve as the autonomous logical parts of the UI. The page's postback and state mechanism would be delegated to each webpart. Each webpart would then be responsible for it's own state and for posting back to the server. Upon return of a postback, the webpart's display and state would be updated. Just like a normal page postback, but scoped to a webpart and using AJAX to refresh only part of the UI.

Now, what if a webpart's state is dependent on the state of another webpart. For example, a master webpart and a detail Webpart. When the selection in the master webpart changes, the detail must be updated accordingly. If each webpart acts independently for postback, the detail will never be updated. However, in the webparts framework, dependencies between webparts are declared through a provider-consumer connection model. Therefore, when a webpart posts back, it is possible to know dependent webparts by finding all consumers of any connection provided by the parent webpart. To answer the dependent webparts problem, upon a webpart postback, a simple rule could be to execute postback logic for each dependent webpart as well as for the parent webpart. Upon return, update state and display for all the webparts implicated in the postback.

re: Some thoughts about server callbacks and Ajax.NET

Bertrand Le Roy — Fri, 15 Jul 2005 17:49:00 GMT

(oh, and yes, we know of the Dart controls and of several other similar libraries. They're great and I can only encourage people to use them if they answer their needs.)

re: Some thoughts about server callbacks and Ajax.NET

Bertrand Le Roy — Fri, 15 Jul 2005 17:47:00 GMT

Karl, I agree 100%. You need to check out my RefreshPanel library (follow this link: http://weblogs.asp.net/bleroy/archive/2005/04/08/397761.aspx and read on), especially the serialization stuff and the RefreshProxy. As I've been explaining in previous posts, the callback infrastructure provides you the low-level plumbing to enable out-of-band calls in a server custom control. It is easy to add a higher-level layer on top of that, as I hope I've demonstrated with this library.
I also mostly agree with the object-orientation remark, and this is precisely what we're going to address with Atlas. What I disagree with is the point of JS being OO. It is not really, but you can sort of hack it into being OO. What it has is closures. In Atlas, we're /implementing/, or adding if you prefer the notions of class inheritance, interfaces, strong types, etc. Stay tuned, I think you'll like what we're doing when we unveil it at PDC.

Scott, two things. First, believe me, we would have *loved* to maintain ViewState during callbacks, but it's very difficult for one simple reason that I've explained in a previous post: only one postback for any given page happens at once, whereas callbacks would be pretty much useless if you couldn't have several happening at the same time. So you may know the order in which you send the callbacks, but there's no way you can determine the order in which they'll come back. So which version of the ViewState are you going to choose? To maintain the monolythic ViewState, you need sequentiality. One solution we've been thinking about for Orcas involves making the ViewState less monolythic and enabling the page to be broken into smaller mini-pages that would have their own isolated state and where local sequentiality of the callbacks would be less of a problem. The problem with such a model is that it becomes more difficult for these mini-pages to communicate with the rest of the page. In fact, the ideal granularity is the control itself, so the ideal solution would be for each control to manage its own state, and guess what, that's the current callback model, except that we don't provide many helpers for client-state management in Whidbey, and it can be difficult to reconcile your client-side state with the global ViewState on the next postback. Read the Fun with Callbacks series for more details.
Second, I think you make my point: there are two needs (and solutions), one for custom control developers (callbacks), and one for application or page developers (Ajax.NET and the future Atlas framework). One tool does not fit all...

re: Some thoughts about server callbacks and Ajax.NET

Scott Wisniewski — Fri, 15 Jul 2005 16:31:00 GMT

You should take a look at the "Power Web Controls" provided by Dart.
One thing they do really well is preserve the user's (the app developer) mental model of how ASP.NET works. The client callback support in Whidbey does not do that, however.

In fact, I think you are in a bit of a catch 22.
You want to enable the developer to drop a control on a page and have the control be self contained in order to preserve their mental model for developing web applications.

However, the limitations of the way callback support is implemented break the user's model: callback event handlers cannot change view state, and the current form values are not collected and posted to the page. This means that a callback running inside a page (the simplest, and hence most likely, scenario involving callbacks) doesn't have access to any of the values users have typed in.

I know some people have expressed concern that collecting the form values can cause validation issues, but that can be resolved by requiring the callback mechanism to fire off the validation process.

In order to keep the callback mechanism, as its implemented now, without breaking the user's mental model you need to split it apart from the page. The callbacks don't have full access to the page (or control) on which they reside, and a result shouldn't be there. If a user places two methods on a page, one that responds to a callback event and one that responds to a post back event, he or she will naturally expect both methods to have access to the same state. However, they don't. The post back handler has access to the values the user (of the web app) typed in, where as the callback does not. The reasons behind the discrepancy stem solely from implementation details and are not immediately obvious to the user (the programmer). It's a prime example of the system implementation leaking into the user's mental model. That's not a good thing.

By splitting callback event handlers out into separate http handlers, the user's mental model is not violated in this manner. The handler is separate from the page, so it makes sense that it doesn't have access to the page.

However, separation is not the answer. It still violates the user's mental model. In particular, it flies in the face of modularity, something ASP.NET is really good at enabling. This is where the catch 22 comes in.

I think the solution is simple: enhance the callback mechanism to grab current form values before postback and to automatically update viewstate and control appearance after the callback. I'm not saying that's simple. In fact, I think it will be pretty difficult, and that it really isn't feasible to see something like that in Whidbey. However, I really think you should look into it for orcas.

I'm also not saying that the callback support isn't useful. For custom control developers (expert level ASP.NET users), the callback mechanism provides a great foundation for developing really awesome controls. I think as a result of it you will start to see some really great things come out of the ISV's developing controls for ASP.NET. As expert users, however, custom control developers are willing to "go the extra mile" necessary to maintain the correct user experience.

For the vast majority of "page oriented" ASP.NET developers (intermediate users), however, I think that the callback support in will prove to be a large source of confusion.

re: Some thoughts about server callbacks and Ajax.NET

Karl — Fri, 15 Jul 2005 13:55:00 GMT

Any solution that requires developers to manually serialize their wonderful objects and then do something meaningful in JavaScript with it is gonna fall flat on it's face. Until such time as good tool support for JavaScript exists, and developers learn that JavaScript is actually OO, even poor developers are going to realize that their code is unmanageable and hackish.

Ajax.Net might provide a "leaky abstraction" (thank's joel for that one!), it's still pretty productive:

var ds = response.value;
for (var i = 0; i < ds.Tables[0].Rows.length; ++i)
{
var firstName = ds.Tables[0].Rows[i].FirstName;
var lastName = ds.Tables[0].Rows[i].LastName;
}

for the win!!

Karl

re: Some thoughts about server callbacks and Ajax.NET

AndrewSeven — Thu, 14 Jul 2005 22:00:00 GMT

I'm glad to see both.

I only looked at the Schwartz Interactive AJAX, but it is so simple to use.
You don't need to know about xmlHttp to use it and on the server you could just use an ordinary aspx page with the functions. In pages where you want to use those functions you call a register for ajax method.