I completely disagree

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
 
R

Raterus

Thanks for your opinion, and I must say there are many other web technologies available if asp.net isn't to your liking, nobody is forcing asp.net down your throat. Personally, I've never had a problem with the event model, have you ever given any thought that you are going about your design the wrong way? How long have you bee programming to know absolutely there is no other way to do this? If I was doing this, my usercontrol would expose it's own event which my webform would handle, and make the appropriate changes to the form. I see no need to use a session variable in this situation.

--Michael
 
C

Cowboy \(Gregory A. Beamer\) [MVP]

I disagree with you, but my disagreement comes from completing the trip
through the valley of frustration and coming to an understanding of the new
model.

I see frustration as a normal part of the process of change in methodology.
Most ASP devs, myself included, try to make ASP like pages in ASP.NET. This
mix of paradigms makes it extremely hard. Often times, it is easy to shift
language syntax to get through the paradigm shift than it is to continue in
a familiar language. You can then go back to your old language. I did this
by moving from VBScript ASP to C#. I now do both C# and VB .NET.

Let's examine a few things:

Page_Load - designed to set a page when it loads. For optimal efficiency and
minimal hair pulling, this sets up a page on first load only. If your
Page_Load is more than a few lines, you are most likely doing it wrong.
Example of bad Page_Load:

protected void Page_Load(object sender, EventArgs e)
{
if(!Page.IsPostBack)
{
//Do a lot of stuff, checking for numerous QueryString vars
}
else
{
//Do a lot of different stuff, as the form is being submitted
}
}

Proper:

protected void Page_Load(object sender, EventArgs e)
{
if(!Page.IsPostBack)
{
//Do only what is necessary for initial state of page
}
}

protected void Button_Click(object sender, EventArgs e)
{
//Do what is necessary for this page when this button is
//clicked. If you have some postback controlled in Page_Load
//move it to another routine and call it from here instead
//Do not run any postback code in Page_Load UNLESS it
//is run on EVERY postback. If it is conditional, run it from here
//Refactor your code to fit this model
}

Controls controlling controls:

You have a couple of choices here, each can be painful:
1. Run it through client script
2. Run it on the server side

For small lists, client side is a perfectly viable option to the postback
model, as it avoids a trip to the server. This trip is not really heavy, but
heavier than setting a short list. If the list is long, however, client side
script is a bulky solution. For example, pick a country, country sets states
list. Pick a state, state sets city or county list. To do this all client
side, you download MBs of script, which makes the app unusable in anything
other than extreme broadband. A server trip is in order.

One Methodology:
I prefer to build up a page from nothing. This comes from my paranoia over
inaccurate data. Turn everything off as state 1 and turn things on based on
specific conditions. If a user has to pick from one list first, only show
list 1. When list 1 changes, you can show the rest of the form, after
choices are painted in. This follows the event driven model rather nicely as
you can hit specific events to paint in specific parts of the form. A
step-by-step process is easy for the user to follow and makes events rather
easy to use, without being cumbersome.

Summary:
ASP to ASP.NET requires a paradigm shift in many ways. Once you are used to
it, you wonder why you did not see how easy it was. Until then, you are
likely to beat your head against the wall. I did!

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************
Dimitris Pantazopoulos said:
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.
 
S

Scott Allen

-The web form has to ... WAIT.... for the usercontrol ... SOMEHOW.

Hi Dimitris:

There are two decent approaches I think you could take.

1) Have the user control "bubble" the event up to the page. Now if the
page is interested in what is happening in the user control it can
subscribe to the event and know exactly when it happens.
http://odetocode.com/Code/94.aspx

2) Give the user control a public property for the Page to examine.
This cuts the Session collection out of the loop and you'll go right
to the source of the information you need.

Does this help?
 
P

Patrice

On the other hand, it would be quite strange to have a user control that is
loaded before its parent container...

For this particular problem, I would just access to the control value rather
than using a session variable (the control has always the correct and
current value unlike the session variable you set at some point). You can
expose this value as a property of your user control (or/and you could
expose event(s) if needed).

More generally i would say we all tend to perform too much things in the
load event at least at first...

Patrice

--

"Dimitris Pantazopoulos" <[email protected]> a
écrit dans le message de
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.
 
K

Kevin Spencer

You are free to use another platform, or to write your own. Disagreeing with
5 years and thousands of programmers, including some of the most famous and
powerful developers in the world, and billions of dollars spent in R&D isn't
likely to make an impact.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

Dimitris Pantazopoulos said:
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.
 
D

darrel

Example of bad Page_Load:

Dang...I still have a lot of learning to do. ;o)

-Darrel
 
D

darrel

You are free to use another platform, or to write your own. Disagreeing
with
5 years and thousands of programmers, including some of the most famous and
powerful developers in the world, and billions of dollars spent in R&D isn't
likely to make an impact.

....especially with egos like that.

;o)

-Darrel
 
K

Kevin Spencer

You like to judge people, don't you? Gregory's answer is acceptable, mine is
arrogant, etc. Did you ever stop to consider that being critical of all
those people and all that talent is arrogant? I am not one of those people.
Therefore, my remarks are not arrogant, but based in logic (how can all
those experts be wrong?).

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

Dimitris Pantazopoulos said:
While Gregory's answer was most suitable I find yours to be an arrogant one.

sure it won't but that's what ms takes for granted all these years, right?
On the other hand, .NET is out for at least 3 years now and yet not so
warmly accepted. did you ever wonder why?
Visual Studio is out for almost a decade now, is broadly accepted but when
it comes to programmer-2-programmer discussions it brings up thousands of
flaws. Still, dbgrid and comboboxes are semi-functional, buttons and menus
cannot have images on them, controls won't autosize to their containing
form, error handling is a joke, data binding is a dream-we-never-saw, setup
and deployment is a story full of tears (and no smile) and so on. VB 4 was a
major disappointment and even at that time there were much more powerfull
tools ahead of Visual Studio.
Thousands of people are using all those tools though but that does n-o-t
mean they are n-o-t fed up with bugs, patches, updates, limitations and
various other frustrating obstacles of ms dev tools and certainly it does
n-o-t mean that they are willing to easily digest yet another new platform
(i.e. .net) at least without critisism, discussion and exchange of opinions
and/or experiences.
 
C

Cowboy \(Gregory A. Beamer\) [MVP]

It is a definite paradigm shift from ASP to ASP .NET. Once you get there, it
just clicks and makes sense. Until that point? Well, I don't have much hair
left. ;->

You have to learn to program more like a desktop dev, realizing the
limitations of web dev. Once you get there, it is easy.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA

************************************************
Think Outside the Box!
************************************************
Dimitris Pantazopoulos said:
couldn't understand you more!



excellent demonstration! Point taken!


I agree. I guess this is exactly the case for every web developer.
Actually, if web developers were to start win programming UI would become
much more stable and reliable. Web developers are far more cautious with
data because all they can initially assume is that they have n-o-n-e between
round trips (well, at least with ASP).
Your reply was great. Especially since I now know that I am not the only
one hitting his head against (a really thick) wall.
 
K

Kevin Spencer

Perhaps you should quote the salient points. I didn't see any that were
pertinent to this discussion regarding "the ASP.NET Event Handling model."

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,898
Latest member
BlairH7607

Latest Threads

Top