UpdatePanel - no performance benefit?

Hiya,

Just started playing with Atlas and have been blown away by some of the functionality.

However I was surprised to read that that UpdatePanel necessarily effects a full postback, event handlers and all, and that the only 'remote scripting' element is at the rendering phase. Surely this takes away all the performance benefits of remote scripting? The point is not just to avoid a white flash in the browser on page load (although it's certainly nice not to have it), but to avoid unnecessary processing, no? Does Atlas offer functionality for calling and handling server methods without the need for running the whole page event cycle?

Sorry if I've missed something obvious in the tutorials (and I appreciate it's still relatively early stages...)

Thanks,
CarlosNote: just had a quick cup of coffee and it occured to me that, obviously, the rendering in question would take place on the server, and hence UpdatePanel gives the considerable performance benefit of not having to send lots of unnecessary information to the browser! Oops...

Still, I do think functionality to call methods directly without simulating a postback on the server would be useful, but perhaps a better design is to set such operations up as asmx, as described at http://atlas.asp.net/docs/Walkthroughs/GetStarted/Basic.aspx ?

Thanks,
Carlos

Updatepanel effectively routes traditional post-backs through an asynchronous stack to avoid the flicker in the browser. The page that receives the post-back still operates in a manner that thinks it's a post-back so that your investments in server-side event handling (post-back handling) and so on work as expected in an ASP.NET world. The rendering of the page however, is delegated and handled by the scriptmanager in this case.

You can however, make data/service calls from your client framework using the 'network layer' in Atlas. As you see in the QuickStarts this means that you can call on ASMX as that ASMX is proivided through a JS proxy in the client. You can also call on PageMethods, if you still want some contecxt from the page, for exampole the page will load forms data/viewstate so that your page method has access to the data/context of the page too.

Cool, thanks for the comprehensive reply. I certainly have appreciated being able to use UpdatePanel with an absolute minimum of changes to my existing code! This feature is really well demonstrated in ScottGu's todo-list video.

Have people found the PageMethods technique to be effective? I'm assuming the initialisation of a page instance from viewstate/http is not all that efficient in comparison with using ASMX...

Will have a try this afternoon.

Thanks again for the reply,
Carlos
Is there any example to call a page method using the 'network layer'?

hello.

yes, the usage of pagemethods is a little more "heavy" that the call of asmx methods. so, you should use pagemethods with care.

My controls are flashing on update panels. they turn 'grey' then are filled.

Also - the first callbacks are slower - which gives a pause to the user. This is troublesome. I have a page with 5 update panels. I'd like to have 5 different progress indicators, but all 5 fire at once.

I hope that is fixed.

Most of my use of update panels is used with dropdownlists, and selection of checkbox, etc... where in the past I would have had to postback to have a change. It's super fast locally of course, but when I move it to the server - it's too slow. This will be a problem for others as well, especially with dial up.

I think the development team needs to really investigate ways to let the user know there is activity - a good start would be only firing a progress indicator if it is in the updatepanel being called.

I'll post this in another thread, but I wanted to note that I see a 'performance problem' (although I understand it's the same 'postback')

hello.

if you want to refresh each panel then you should set the mode property to conditional.

It is set to conditional.

But progress indicators in different panels are updating regardless - so all 5 are firing even though only one panel is set to fire conditionally.

The client does not know which update panels are going to be updated in any particular request (esp. when Mode is Conditional). Server-side logic may cause a panel to be updated.

Hence UpdateProgress isn't per UpdatePanel - it is per page. We will provide ways to customize the content of the progress UI depending on what caused the postback, but its still per page.