We have been using our own (non fancy) ajax framework till now. Now that Microsoft itself published these controls I thought of checking them out.
The first thing is the much talked about UpdatePanel.
I noticed when some client interaction happens the Panel actually calls the Page_Load event every time including initialization of variables. It basically loads the entire code behind page (class) instead of just calling the method which should have been written to be self sufficient like a Web Method in web services. This is like let the server reload the page but the client will get only filtered content.
Is this how AJAX works? If so I have never seen a technology which such a big blunder being accepted so fast.
Its a known fact that the page load is used to load content into the page so if it calls this event it would also get all the datasources even though the ajax function does not deserve it.
This shall never work in an enterprise scenario.
Atleast just like isPostBack there should have been an isAjaxPostBack so that we can avoid reloading unwanted stuff. Even having a provision for a separate page would do.
For those of you who develop enterprise applications please develop your own frameworks.
To recreate this scenario:
Do a Debug.WriteLine under Page_Load Event and run in debug mode. You can try calling some private methods in Page_Load and having Debug.WriteLine there too. You would be surprised that these events are called though the update panel requires the event which happened inside of it.
ASP.NET AJAX partial postbacks work with Page.IsPostBack in the same way that a full postback would.
antonpious:
Atleast just like isPostBack there should have been an isAjaxPostBack so that we can avoid reloading unwanted stuff. Even having a provision for a separate page would do.
What aboutIsInAsyncPostBack property of the scriptmanager? 
What aboutIsInAsyncPostBack property of the scriptmanager?
Yes this seems to have solved the problem of code structure and can prevent unwanted methods from being called.
with this type we now have to code like this on the Page_Load
!isPostBack && !scriptManagerInstance.IsInAsyncPostBack
isPostBack && !scriptManagerInstance.IsInAsyncPostBack
!isPostBack && scriptManagerInstance.IsInAsyncPostBack
Still it does not stop it from initializing the entire controls in a page together with global variable declarations. They have cleverly hidden the designer when using the default web project but if you installed VS 2005 SP1 you can create a web project which creates a designer file with all the controls present in a page. Typically the pages would be pressed for realestate with every available space being used. Loading all the controls when a partial render is required does not scale. This when compounded with initilization of Typed DataSets as DTO is bound to be a big failure. We then have to go back to implementing classic OOPs with classes as DTOs.
Still it does not stop it from initializing the entire controls in a page together with global variable declarations
Partial page rendering works this way, check the doc:Partial-Page Rendering Overview, from that page:
"An asynchronous postback behaves much like a synchronous postback. Allthe server page life-cycle events occur, and view state and form dataare preserved. However, in the rendering phase, only the contents oftheUpdatePanel control are sent to the browser. The rest of the page remains unchanged."
"An asynchronous postback behaves much like a synchronous postback. All the server page life-cycle events occur, and view state and form data are preserved. However, in the rendering phase, only the contents of theUpdatePanel control are sent to the browser. The rest of the page remains unchanged."
Thanks for your inputs.
Yes it sends the contents of the UpdatePanel together with changes to the ViewState, but lets say if I have 50 controls (textboxes, dropdownlist etc) not to mention global variables in a page out of which the UpdatePanel has 10 why does these 50 controls have to be loaded on the server side and then filtered to get content for the 10 controls UpdatePanel to be sent to the client browser. The problem becomes bigger as more and more controls are added to the page.
Guess now that the source code is available this has to be extended to have the content come from a separate page.
1. If your code wasn't using IsPostBack to avoid reinstantiating unneeded objects on every postback, it probably didn't scale without AJAX either anyway.
2. If you want a leaner way of implementing ASP.NET AJAX callbacks, check out web methods (not web services). You don't have to use the UpdatePanel. It's just the training wheels they give us to get started with.
Hi,
Just to inform you that Asp.net Ajax Framework is not about Update Panel.
Asp,net Ajax Framework there are two development model:
Server Centric or UpdatePanel
I appreciate your passion.
easy to make an ajax version of a page without writing a single line of code.
yes this is why we are in this profession. Its one thing making life easy and another thing tricking us into it.
The sample that came with AJAX 1.0 should have included the details of how it works together with what stmarti pointed out. The Page_Load event should have had the if statements to distinguish what code is called with AJAX. I am pretty sure many out there would not have made the 3 part distinction. I assume they did this to make your "no single line of code" compliant.
We are not comparing web service. If you have written your own AJAX framework, one way to do it is to call a separate page with the required information with a seed to prevent caching in browser. This returns the xml or html markup which is used by the client side to populate the partial rendering div element. We are not talking about 1000 of lines once the functions are in place no one needs to write the code again just like you are doing with this framework where all the scripting is done by Microsoft.
If you are really wants to develop an enterprise level application follow the Client Centric Model. FYI Both Live.com and Pageflakes.com are developed in MS Ajax and they are serving millions of users each day following the Client Centric Model
With regard to the live.com I have seen so many of you who fall for this trick. This was there even at the time of hotmail when they said hotmail is written in PERL so its Enterprise specific.
Please understand that the web technology is not about a particular technology its about the combination of technologies. You may not know how many servers live.com is run on to get that speed you are talking about.
Even the maintainers of this forum had to add extra servers and hardware to take care of the load.
The point is if there is a flaw it has to be told upfront not hidden in fine print.
You can continue to use it but do understand its limitations.
If you have written your own AJAX framework .
I am not sure did you mean to create a Framework from Scratch or a Framework which works on top of MS Ajax? Certainly you can create your application specifc frameowork which does lots of plumbing things for you. But if your are recommending to develop a framework from a scratch then it is nothing but a poor advice.
With regard to the live.com I have seen so many of you who fall for this trick. This was there even at the time of hotmail when they said hotmail is written in PERL so its Enterprise specific.
Th reason behind mentioning the two sites was to inform you that it is possible to develop large application with Asp.net Ajax. Certainly there are lots things behind the scene including load balancing which makes the application scalable.
The point is if there is a flaw it has to be told upfront not hidden in fine print.
You can continue to use it but do understand its limitations.
I think you are again stuck with the UpdatePanel. Ms Ajax is not about the Update Panel. If you are following it from beta version the Client vs Server centric development model has been discussed so many times in different articles and blog posts. Of course you have to know the ins and out of a technology for a successful implementation and this applies to all including MS Ajax.
But if your are recommending to develop a framework from a scratch then it is nothing but a poor advice.
It again goes back to the common saying "Web Services is not SOA" but "what is left of SOA if we remove Web Services".
Here is a comparison of the coding that was done to make both your Client and Server Centric Models.
Used by xml-script a Client-Centric model
AtlasUIMap.js
containing 823 lines of code with some lines extending to 2168 character and single alphabet variables with a file size of 105KB
Not to mention the code added by xml-scipt block. With xml-script accepted by many as not an easy language to master.
used both by Client-Centric and Server-Centric
Atlas.js - Atlas Framework
AtlasRuntime.js - Atlas Runtime Framework
containing 11392 lines of code with a file size of 360KB
This throws a challenge if anyone can write a framework with less number of code. Since the framework one writes is customized to a single system without having to take all parameters into consideration it would always outsmart MS AJAX.
No comments:
Post a Comment