pulling data from the server vs from the client

Hi,

I have a general issue which I don't think is addressed by the current ASP.NET Ajax framework. If it is I'd like to know; if not, will it be in the future? Or is it not worth considering?

The issue is this Suppose that we have the page functionality demonstrated in the CascadingDropDown toolkit sample. It seems to me that due to the small amount of the data, and the fact that the data are fairly static, the right thing to do here would be to push up all the data to the client and read them from there, rather than via an Ajax call. I say the 'right thing' because the aim here is to make the application as responsive as possible, and the bottleneck here is the roundtrip to the server (which might become an issue, for instance where the Internet connection is slow or where there is a very heavy viewstate as a result of other stuff on the page).

On the other hand, were the CascadingDropDown sample to be hooked up to a major set of data, then the right thing to do would be the Ajax call. The bottleneck would be pushing up all of the data to the client.

Approaching this in an object oriented frame of mind, it seems to me that the DropDown object doesn't care how it gets updated. So there's room for an Updater object which will do the 'right thing', dependent upon the prevailing circumstances. Such an Updater could have a default behaviour which gets switched by the developer, or it could work off some more fancy intelligence about the amount of data involved.

Now, I guess that I could implement something like this for the CascadingDropDown sample. Javascript updating has been around since forever (I used to do it with hidden frames). But is there any future in having this kind of functionality built into the AJAX framework? The core control in the ASP.NET Ajax framework is the UpdatePanel, which always requires a postback, and always passes back a heap of HTML. It can't work with a different source of data (the client) nor a different method of updating a control than overwriting a section of page HTML. In Dino Esposito's article 'Perspectives on ASP.NET AJAX' he says that alternative approaches are 'far too intrusive for a Web framework such as ASP.NET'. But I'm not sure what would be 'intrusive' about allowing AJAX to make smarter choices about manipulating data.

Working out the details of how this would work wouldn't be simple, of course. But, since it's been annoying me for a while now I'd really appreciate any feedback on the general idea.

You seem to have an underlying assumption that the server controls are the framework. Free your mind. lol. The framework is the server controls + the clientside controls. What you're describing is definitely a good idea, so build it and send it to the *open source project* that's building the toolkit

After doing a bit of reading I've realised that what I'm describing is (at least partly) a browser-side cache, which could be prepopulated. I might have a play with writing such a thing.

I am confused about the relationship between the different bits of ASP.NET Ajax, though. As I see it there's the core Microsoft stuff, which centers round the UpdatePanel. Then there's a bunch of 'control extenders', many of which aren't in the slightest bit AJAX (no asynchronous traffic), and some of which just seem to be inefficient ways of applying styles. In between there are some useful client-side libraries. But when it comes to further improving and extending the actual *AJAX* side of things I'm not sure whether it's supposed to be coming from the Microsoft side or the community side. So I'm not sure I'd want to spend my own time trying to come up with stuff that the MS developers are going to cover (in doubtless far more elegant ways).

I agree that the extenders are often just simple ways to add DHTML type stuff to your ASP.Net controls. I think that the MS focus on the UpdatePanel is incorrect, though. The focus I've seen on the update panel si from *developers* on the MS forums that are entranced with it as an 'easy out' to building their own client layer. It's got its own issues, though, so my path has taken me to try and better understand the other tools available. Among my favorite of those is the way Web Services are made to be more easily accessed w/o the developer explicitly making XmlHttpRequest calls or parsing the reuqest and response to and from objects in the respective client or server code.

If you read through the documentation on the clientside stuff, you'll find that there's some pretty robust support for javascript stuff that allows you to leverage the power of the client script w/o digging into most of the browser inconsistencies that you'd have to if you were rolling your own. I see the whole spectrum of these things (server controls, handlers, extenders, client libraries, etc) as "the Framework". Which is why I think looking at just the Update panel, or even just the server controls (to include the extender toolkit) is selling the overall framework short.

Just my opinion.