G
Guest
Hi all.
I completely disagree with the ASP.NET Event Handling model.
This is a final conclusion I came to after weeks of hard work on a quite-more-realistic-web-app than the MSPetShop
I firmly believe that the Event Handling model is cumbersome, complicated, unefficient and just, well, ...unpredictable! Last but not least, it comes to a complete contrast with the old ASP processing logic.
Here is an example:
-Place a dropdownlist in a user control and fill it with some items. On the SelectedIndexChanged event just save the selected value in a Session variable.
-Add the user control in a couple of web forms.
-Assume that depending on the value of the Session variable you want to display different results in your web forms.
This is a classic example of misjudgement and misunderstanding especially for people migrating from ASP to ASP.NET.
Consider the facts:
-The Load event of each web form fires BEFORE the Load event of the user control.
-Thus you cannot really say what's in your Session var...
-...because the usercontrol will fire its code AFTER the web form does.
-The web form has to ... WAIT.... for the usercontrol ... SOMEHOW.
This is just one of the cases. I believe the Load event is generally handled in the wrong place and time in the processing model.
The IsPostBack is just a last-minute-excuse to prevent hell broke loose.
Of course, I know some of you say this kind of post is pure sarcasm, others may find it just too LOUD or even CRAZY.
But please think about programmers working in software companies in a daily basis (and not at home just for testing and fun !!!) and are simply trying to make things work. They surely do NOT need all this mess.
dimitris
I completely disagree with the ASP.NET Event Handling model.
This is a final conclusion I came to after weeks of hard work on a quite-more-realistic-web-app than the MSPetShop
I firmly believe that the Event Handling model is cumbersome, complicated, unefficient and just, well, ...unpredictable! Last but not least, it comes to a complete contrast with the old ASP processing logic.
Here is an example:
-Place a dropdownlist in a user control and fill it with some items. On the SelectedIndexChanged event just save the selected value in a Session variable.
-Add the user control in a couple of web forms.
-Assume that depending on the value of the Session variable you want to display different results in your web forms.
This is a classic example of misjudgement and misunderstanding especially for people migrating from ASP to ASP.NET.
Consider the facts:
-The Load event of each web form fires BEFORE the Load event of the user control.
-Thus you cannot really say what's in your Session var...
-...because the usercontrol will fire its code AFTER the web form does.
-The web form has to ... WAIT.... for the usercontrol ... SOMEHOW.
This is just one of the cases. I believe the Load event is generally handled in the wrong place and time in the processing model.
The IsPostBack is just a last-minute-excuse to prevent hell broke loose.
Of course, I know some of you say this kind of post is pure sarcasm, others may find it just too LOUD or even CRAZY.
But please think about programmers working in software companies in a daily basis (and not at home just for testing and fun !!!) and are simply trying to make things work. They surely do NOT need all this mess.
dimitris