Developing Rich Web Applications with ASP.NET AJAX

TechEd 2006 : ASP.NET 2.0 & Ajax

I entered this session as triggers were being defined for an UpdatePanel using an UpdateProgress AJAX server control…

Just as a quick aside. The project codenamed “Atlas” was released as Beta in it’s new renamed form. So,  the new names and logical seperation is as follows :

  1. The javascript library is called the Microsoft AJAX Library.
  2. The server-side ‘tags’ (embedded in HTML) that are available within ASP.NET 2.0 are called the ASP.NET 2.0 AJAX Extensions.
    (Note that the ‘atlas :’ prefix is no longer in use. The ‘asp:’ prefix is to be used instead .) 
  3. The Atlas Control Toolkit is renamed to the ASP.NET AJAX Control Toolkit

The latest download is of this is available at : ASP.NET AJAX 1.0 Beta 2

There is a host of Ajax controls being developed by the community. These include everything from a collapsable panel to a filtered textbox.  These controls are available at the ASP.NET AJAX site.

So, with this  much info comes the inevitable question – which method should I use when making an aynchronous ajax call from my web application ? The options are the In-built ASP.NET 2.0 Ajax Extensions or the Microsoft Ajax Library.

 Using ASP.NET 2.0 Ajax Extensions

With this option, you are basically going into the aspx page and without having to write a line of javascript, you can use ajax to communicate to your web service method.

In general , this takes about 5 minutes to apply to an existing web form in your (ASP.NET 2.0)  application. If we take the scenario where you have a gridview on your form and you have paging setup.

Each time that you move to another page, your browser will make a round trip to the server to get the data via your web service and your page is rendered to the client browser each time. This causes the browser to ‘blank’ as the round-trip is being performed.

You can by-pass the ‘blank’ effect by implementing an AJAX call for the data that you request.

To do this using  ASP.NET 2.0 Ajax Extensions, you will need a scriptmanager, then wrap the datagrid in an updatepanel as illustrated here :


< scriptmanager EnablePartialRendering="True" runat="server"  ID="scriptmanager1" />
< asp:UpdatePanel ID="updatePanel1" runat="server">
< contentTemplate">
< asp:gridView...>
columns, etc go here
< /asp:gridView">
< /contentTemplate">
< /asp:UpdatePanel>

 

…and that’s it in it’s simplest form. When you next use your grid, any callback to the server will be executed as an ajax callback with partial rendering.

Using ASP.NET 2.0 Ajax Library

With this option, we will be calling a web method directly from javascript on the client page. As you are writing javascript, then your source will be available to view (i.e. a user can ‘View Source’) by the client.

Given this,  I would recommend using this method to return data that will be displayed on the page in any case (eg. First name, Surname for a Person) – i.e. not a good idea to return full credit card info and primary keys, etc…. Also, in general, I would use the ajax extensions for handling a data control such as a gridview. 

I would then use this (i.e. Ajax library) for updating fields on a screen that represents an instance of a class (eg. the Person class) or for any validation that requires a simple db call.

The one change that you will need to make in the web service source code is to add “[scriptmethod]” below the “[Web Method]” declaration for the method that you wish to expose to the javascript.

After that, it’s up to your javascript to call the web service method and display the data through a javascript function.

An in-depth look at the Microsoft AJAX Library is available at : http://msdn.microsoft.com/msdnmag/issues/07/01/ExtremeASPNET/default.aspx
(why reinvent the wheel !)

So, in conclusion, ASP.NET and Ajax will enhance your web applications through partial postbacks, direct method calls to your code behind/web service and enrich user experience through the implementation of the ASP.NET AJAX Control Toolkit.

  1. #1 by kenneth on January 22, 2007 - 3:03 pm

    any performance issues with the UpdatePanel?

  2. #2 by kenneth on March 22, 2007 - 8:33 am

    i guess not

  3. #3 by Alan Crowley on March 22, 2007 - 9:24 am

    Hi Kenneth,

    I have just checked your 2nd reply – yes i have been away from this blog for too long – Apologies all round !

    To address your question….

    There are time-response differences when using the Update Panel but to say that the differences would warrant a ‘Performance Issue’ is not justified, in my opinion.

    As with any web application, one of the key factors in ensuring good performance is the efficiency in retrieving data from your database (or xml, etc…).

    If you return unused data or too much data, then perfomance will take a hit depending on number of users and available bandwidth which will become noticable to the end-users.

    However, the UpdatePanel is simply adding a layer so as to manage your DB calls asynchronously. This will give the user the impression that the web application is operating in a similar fashion to a desktop app in that it is seemless to the user that the web app is fetching data. i.e. the browser doesn’t ‘blink’.

    I would say that if you manage your data calls efficiently , then there shouldn’t be that much of a difference in response when using the updatepanel.

    If you do have large chunks of data coming back and breaking the call into a number of smaller calls is not possible, then the most common option taken is to use the ‘UpdateProgress’ component to display a ‘Please Wait’ message and/or an animated gif to illustrate a ‘Please Wait – Fetching Data’… as it’s going to take time to retrieve the data in any case!

    Also, a point to note is that a user can only read so much information from a web page in any case…so for example, returning 100,000 records in a gridview is definitely not a good idea – but allowing the user to search before retrieving the data , and then implement paging (if applicable) should allow you to benfit from the use of the UpdatePanel without any visible delay to the user.

    I hope this helps … and again, I’ve been away from this blog for a while so apologies for not getting back to you sooner.

    All the best,

    Alan

  4. #4 by kenneth on March 26, 2007 - 8:27 am

    Hi Alan,

    Thanks for the excellent response and please excuse my 2nd reply. I was having a bad day 🙂 .

    I was at the Ajax seminar Friday and it looks like calling a web service as opposed to the Update Panel seems like the most efficient way. Depends on what your returning I suppose.

    As a aside, on a number of occasions the speaker mentioned what a pain javascript is, makes you wonder why Microsoft didn’t look at how the GWT works in the Java world and auto generate the javascript code on the client side from C# code all under the hood. I didn’t see much Friday that I couldn’t already do very easily in PHP with a couple of handy ajax toolkits. Seems Microsoft are happy to be on a par. They do have the UpdatePanel, UpdateProgress and UpdateTimer controls but they’re probably not the best solutions for designing fast Ajax application, so that leaves you with a Javascript wrapping library that can easily call a web method.

    Thanks again for the detailed reponse,

    Kenneth

  5. #5 by Alan Crowley on March 26, 2007 - 4:36 pm

    No bother Kenneth….

    I didn’t make it to the conference myself, but I have a copy of the documentation that was provided (as you know, DSI sponsored the event)…it covers pretty much everything that you would need to know.

    As you know, the Atlas project, as it was known, was a community project…hence the compatibility with all browser types and php…and yet, not compatible with WCF … hmm ? 🙂

  6. #6 by Rocky on April 16, 2007 - 8:07 am

    Hi guys ,
    I was looking at your discussions. But i have some questions on the same topic what you people are speaking about. I do have a requirement to Use AJAX . But i am in a dilemma whether to user the updatepanel or the calling webservices from client approach. I need a perfect justification on each approach.
    Which is most efficient way. I would say am very much fascinated by the update panels but i dont have a concrete reason for adapting the same approach.. Can somebody help me to make this clear. Any info on this would be appreciated.
    Thanks,

  7. #7 by Sidar Ok on April 17, 2007 - 12:26 am

    Hi Rocky, excuse me Alan for jumping in 🙂

    In my opinion update panels are for quick development, and they provide very easy way for migration. Just putting your existing code into an update panel provides you an instant AJAX. It also has great integration with other controls, such as progress control and AJAX toolkit stuff as you already may know about. The idea of writing 0 lines of javascript is very attractive as well.

    But enough pros 🙂

    If your main concern is to benefit on the wire, as my collegue michael stated in his great blog entry (https://blog.decaresystems.ie/index.php/2007/04/02/ajaxnet-conference-compliments-of-decare-systems-microsoft-and-it-cork/) It does not provide us the heaven we expect.

    It still has serious benefits, such as cropping the response headers(which has also some cons), but in case of most business applications with viewstate nightmares, update panel is not a good solution. It posts back all the page (yes, even the parts outside the update panels) all viewstate (yes, even you turn off the page’s viewstate) and all page lifecycyle is executed from init to unload.

    If you are comfortable with writing a few lines of javascript, calling web service methods via script manager is the way to go. This way is also my favourite because it definitely encourages service orientation behind the scenes 🙂

    You may want to use Nikhil Kothari’s brilliant web app helper to measure the size of request and responses.(www.nikhilk.net)

    Hope this helps.

  8. #8 by Rocky on April 17, 2007 - 6:36 am

    Thank u Sidar ,
    Now I have considered the webservices approach as a relatively better one! for my requirement. But i think i will end up in writing large blocks of Javascript code to bind the data with repeater controls(which is going to have too many user controls inside). One of my collegue is telling that using webservices approach will always have more network traffic. So am still in a dilemma.
    BAsically i do not want to go to server when there is no DB interaction. What i have decided is i will hit the DB whenever is required. Then i will store the data in client side JS objects. will it be feasible?. Can i use JS with update panels to load data??.

    Thank you once again. Am running out of the schedule, any quick turn around would be realy helpful for me.

  9. #9 by Sidar Ok on April 18, 2007 - 10:54 pm

    Hi Rocky, sorry for the 2 days. I was really busy with the release.

    If you are using complex controls such as repeaters, grids or datalists, using web services instead of an update panel could be a total loss in development time. You will have to write an extra javascript code for each new control that you add inside edit item template. But if you do so, try to use Microsoft AJAX library’s client side JS codes which enable some object orientation in javascript.

    If you have enough time this would be the best performance gain on the wire. But if you are running out of time, the bes match is a mixture: Populate non-complex controls with web services (such as getting states and city from zipcode, even it is) and complex controls within update panels.

    Loading some data to client side can be ok if the amount of data does not exceed 100 kb each time, but I do not recommend to make client data-intelligent as the script could alwys be disabled and this may cause a security issue.

    hth,

  10. #10 by Rocky on April 20, 2007 - 11:59 am

    Thanks a lot sidar,
    After considering all ur suggestions i made up my mind to go with a hybrid approach. Am gonna leverage the JavaScript for my req with the advantages of UpdatePanel.

    Moreover if you find some way to get the ID of the updatepanel which got refreshed , post it. I have searched everywhere. But nowhere i could get the answer. But there are ways to get the control which caused the postback(the triggers)..

    I feel the release doesn’t have any solution for this one.

    thanks once again.

  11. #11 by Sidar Ok on April 22, 2007 - 2:00 am

    Hi Rocky,

    You are right, there is no direct solution. There is one way actually, the IsInPartialRendering property but it does not work somehow. I couldn’t manage to indicate true.

    The only solution seems to be writing some extra code for that.

    The guys at asp.net forums have already discussed about this, and here is the link :

    http://forums.asp.net/1653671/ShowThread.aspx

    Both the latter and former approaches there work, the key point is finding whether the trigger of the update panel is the control that caused the update or not…

    Extending update panel approach to expose protected RequiresUpdate property publicly could be a little distracting, but it works quite better than the other apporaches listed on the page. It works even update panels are nested, and even they are inside a user control.

    You may end writing your BaseUpdatePanel that has an “IsUpdating” boolean which is nothing more than the exposure of RequiresUpdate property.

    hth, cheers.

  12. #12 by NWGaEagle on October 16, 2007 - 1:39 pm

    The issue I see with the “IsUpdating” property, is that it seems to always be ‘true’ for me. Any other thoughts? 🙂

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: