Well, my problems with ASP.Net go much deeper than simple OO concepts (I've
got at least 3 different threads addressing 3 different multi-day issues
within a single functional problem). I've run into problems with manually
calling a request while staying in an existing session. I've run into
problems using ASP.Net to simply POST data (and searching on that shows more
than a few people have issues with it). I've run into ASP not using its own
Request params consistently. I've run into problems with having the
System.Net HTTP stuff interact with the System.Web HTTP stuff (the parallel
namespace/class stuff drives me NUTS). Maybe it's OO stuff or API design at
its heart, but honestly, I haven't run into these issues with the design of
the API or its behavioral quirks anywhere to this degree anywhere else in
the BCL. And I've also been further frustrated in that in researching
solutions, I too often find "Oh, yeah, that's being fixed in ASP.Net 2.0"
That'd be all fine and dandy if ASP.Net 2.0 was coming out soon or those
fixes would be merged over into a 1.1 service pack, but it's not, and I'm
left wondering if I should wait on the fabled fix (and after getting burned
holding development on an object layer for the at-one-time impending
ObjectSpaces, I have no faith in the "release date fix") or devise some
scheme of hacks to get around it or tell the customer, "Uhh, it seems the
best solution from newsgroups/blogs is to run ASP.Net 2.0 beta, even though
running beta software in production is terrible and all"
I need some magic pill that zonks me out into Betaland.
Steve C. Orr said:
We haven't been talking about much more than basic object oriented
concepts here, so you're likely to encounter similar issues in virtually
any modern language or platform.
However, the ASP.NET page lifecycle does tend to throw some complex timing
issues into the mix, so perhaps your frustrations are centered around
that.
Here are some links that may help in that regard:
http://msdn.microsoft.com/library/d...guide/html/cpconcontrolexecutionlifecycle.asp
http://www.15seconds.com/issue/020102.htm
http://msdn.microsoft.com/library/d...on/html/vbconWebFormsPageProcessingStages.asp
Keith Patrick said:
Yeah, that looks to be about my only option. It's odd...I've been
running into more walls with regards to ASP.Net, whether it be
consistency (or lack thereof) or a ridiculous # of hoops to get through
to do some simple HTTP things, and it has been absolutely driving me
nuts. I guess after being so productive with it for so long, I just
expected it to expose certain things to make more advanced things
possible (a form of an inductive UI, if you will), but the deeper I dig,
the more I get let down with regards to my expectations.
Steve C. Orr said:
The user control could expose a public property that specifies the
button that was clicked.
I have a web page that has a bunch of usercontrols, each declaring a
Button called "GoButton". Now, my parent page has to be able to
determine which button triggered the event. The catch is: I'd like to
use the same algorithm for every control, and right now, my algorithm is
"sender = this.FindControl(Request["__EVENTTARGET"]", but the problem is
that those buttons always get rendered as type="submit", even if I
assign a CommandName and/or CommandArgument, leading the
Request["__EVENTTARGET"] for Button presses to be String.Empty.
The event itself has the sender, but that code is in the usercontrol,
not the page. What this means for me is that I could hack in a
solution via temporary variables or passing a sender ID in the
QueryString, but I'd much rather find a way to crack the Button
rendering and just have it render as type="button" where
onclick="javascript:__doPostBack(...)" just like every other control
I've got to handle.
