Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > I completely disagree

Reply
Thread Tools

I completely disagree

 
 
=?Utf-8?B?RGltaXRyaXMgUGFudGF6b3BvdWxvcw==?=
Guest
Posts: n/a
 
      07-02-2004
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
 
Reply With Quote
 
 
 
 
Raterus
Guest
Posts: n/a
 
      07-02-2004
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

"Dimitris Pantazopoulos" <(E-Mail Removed) > wrote in message news:(E-Mail Removed)...
> 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

 
Reply With Quote
 
 
 
 
Cowboy \(Gregory A. Beamer\) [MVP]
Guest
Posts: n/a
 
      07-02-2004
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" <(E-Mail Removed) >
wrote in message news:(E-Mail Removed)...
> 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



 
Reply With Quote
 
Scott Allen
Guest
Posts: n/a
 
      07-02-2004
On Fri, 2 Jul 2004 05:24:02 -0700, "Dimitris Pantazopoulos"
<(E-Mail Removed) > wrote:

>-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?

--
Scott
http://www.OdeToCode.com
 
Reply With Quote
 
Patrice
Guest
Posts: n/a
 
      07-02-2004
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" <(E-Mail Removed) > a
écrit dans le message de
news:(E-Mail Removed)...
> 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



 
Reply With Quote
 
Kevin Spencer
Guest
Posts: n/a
 
      07-02-2004
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" <(E-Mail Removed) >
wrote in message news:(E-Mail Removed)...
> 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



 
Reply With Quote
 
darrel
Guest
Posts: n/a
 
      07-02-2004
> Example of bad Page_Load:

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

-Darrel


 
Reply With Quote
 
darrel
Guest
Posts: n/a
 
      07-02-2004
> 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


 
Reply With Quote
 
Kevin Spencer
Guest
Posts: n/a
 
      07-02-2004
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" <(E-Mail Removed) >
wrote in message news:(E-Mail Removed)...
> 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.
>
> I like your little, personal quote though
>
> dimitris
>
>
> "Kevin Spencer" wrote:
>
> > 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"

<(E-Mail Removed) >
> > wrote in message

news:(E-Mail Removed)...
> > > 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

> >
> >
> >



 
Reply With Quote
 
Cowboy \(Gregory A. Beamer\) [MVP]
Guest
Posts: n/a
 
      07-02-2004
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" <(E-Mail Removed) >
wrote in message news:(E-Mail Removed)...
> >
> > 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.
> >

>
> couldn't understand you more!
>
>
> >
> > 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:
> >

>
> excellent demonstration! Point taken!
>
> >
> > 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.
> >

>
> 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.
>
> dimitris



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: VOIPfone down completely ... I mean very completely !! cjd UK VOIP 2 10-10-2008 01:17 PM
Different Modelsim versions disagree in same backannotation! spectrallypure VHDL 7 01-23-2007 11:03 PM
readLine on socket works while available() and ready() disagree kevin.osborne@gmail.squirrel.com Java 6 10-22-2005 03:47 AM
Problems parsing, parsers disagree Christophe Vanfleteren XML 2 04-18-2004 08:36 AM
Disagree with proposed 2.4 behavior for %x formatting of signed ints Letbetter, Jason Python 4 09-10-2003 07:57 AM



Advertisments