Why I hate ASP.net

I didn't want to derail the HTML5 Gaming thread, so here goes.

ASP.NET started out on the wrong path. In "classic" ASP, Microsoft had a serviceable scripting language that allowed dynamic output of HTML. Sure, it was kinda slow, and rife with security issues, and didn't have a lot of tools available to aid in development, but it got the job done. What functionality wasn't made available as part of the platform was available from legions of companies whose business was built upon filling in the gaps. It was the web scripting equivalent of VB6. Better than VB6, though, you could use VBScript or JScript to script the pages. As it turns out JScript actually worked pretty well as a server-side scripting language.

With the introduction of .NET, Microsoft made a big change in several departments. They made their programming languages fully OO and strongly typed. A welcome evolution, as almost anyone will tell you. The use of an interpreter in between the code and the actual OS as arguable, but has worked relatively well (after fixing some stumbles out of the gate). Sure, they haven't bothered to port the interpreter to other platforms (which is basically the whole point of having an interpreted language), but the Mono project has stepped in and done a remarkable job at reverse-engineering the process.

However, the most dramatic change in the shift to .NET was the ASP.net platform. Rather than simply allowing for these new languages to function as a way to dynamically generate HTML, Microsoft took it upon themselves to shoehorn the web platform (html) into a desktop programming paradigm, complete with state and event models. It's an attempt to mask the stateless, markup-driven web environment and instead treat the web as another desktop platform. Perhaps a noble intention, but at the end of the day it falls short -- waaaay short.

ASP.net (at least, in its classic "forms" setup) relies on convoluted hidden inputs on a page to maintain state and handle events. Inputs that are placed on a page are modified (in name and functionality) before actually being output to the browser. This is all done behind-the-scenes; as far as ASP.net is concerned, you create your app in its environment and it will handle the output mechanism. That's fine and dandy, I suppose, but what if it's not working correctly? What if you need to get under the hood and understand why, say, a "event" isn't firing? (I put event in quotes because it's not a REAL event; it's a post-back with specific form parameters.) Well, too bad. You can't. You're relying on a black-box that's inserted between you and the actual environment your user interacts with. It's the same reason so many people hate Flash.

Why not just trust the programmer to know how the web works? They had to with classic ASP, and need to with PHP, Python, Ruby, and other modern web scripting languages. I find it rather insulting that Microsoft feels that they need to hand-hold a desktop programmer through the web programming environment. It's not just training wheels, it's converting the bicycle to a motorized four-wheeler because they think their programmer is used to driving a car. Well, guess what, I know how to ride a bike and I don't want or need that "help."

Speaking of hand-holding, ASP.net has a slew of controls that are supposed to make life easier for developers. For example, the ListView makes it painfully easy to connect to a database and display the data in a table on a web page. It has a cute little wizard that guides you through connecting to the database, choosing your display criteria, and even makes an attempt at some basic formatting. It supports auto-generation of update and delete "code" to make for a quick CRUD interface. Super. But, what if you want to customize what comes back in your result set? If you modify the query (an "advanced" option), guess what -- the "wizard" now only generates your select but won't do your update/delete statements for you! You're forced to go into the inner workings of the generated "code" (I put that in quotes because it's a mish-mash of xml and markup) and figure out how to add in those other options. So, the simple CRUD application that was made easy by a wizard has now become an effort that has taken more time to complete than an equivalent application using a scripting language that doesn't get in between me and the output.

That's just one example, but I find it repeatedly when working with ASP.net. Sure, a response to that would be "don't use those controls, then!" Not a problem, except since they're made available, everyone and their mom already uses them, which means if I'm not making this thing from scratch, I still have to wade through it time and again.

Back to the whole "putting something between you and the web environment" thought. Why do they feel the need to take the simplest of concepts and wrap them in the most convoluted, wordy, eye-crossing Microsoft-ese? I want to read a table's contents and output it to an html table. To do that in ASP.net, you have to create a "data provider" (which could be something like "reporting an analysis services", or some sh*t), a "List View Control", "Bind the data provider to the control", configure the "data source parameter control values", and on and on and on. The "list view" has a header template, a selected item template, a row template, an *alternate* row template, a footer template, and FSM knows what else. Sweet jesus, man, I want to do a simple select and loop through the results.

I'm going to start using the MVC implementation of ASP.net (a completely separate environment, mind you, that won't work with the existing "forms" setup) and see if that redeems it at all in my eyes. I have high hopes, but I can't shake the feeling they'll find a way to make it harder than it needs to be.

The bottom line is this: Why does it have to be so complicated? Don't even get me started on their half-assed "AJAX" add-on. If you're a web developer, all of this crap just gets in the way. The web is the web, there's no need to pretend it's a desktop application. Trying to force it to be one is counter-productive and has wasted countless hours of my life.

Phew, that feels better. /rant

I'd take that over what I've been given, which is a spaghetti of PHP code that spans many more lines than it needs (I'm confident we have near 100k lines of code), and is a pain to maintain as it was put together by people with little care for programming standards, security concerns, database design, etc. I mean, it was designed for business use with register_globals completely overused. It was started in 2005/2006 and we're already hitting limitations with it (especially when discussing security... *shivers*) - so if I don't do something drastic in the next year or two, our business to business product is likely to have some major trouble.

Now, having professionally used PHP for 6 years as my main language, I feel like I could write a pretty hefty complaint list about the language itself. There's many reasons I could choose to move forward with that still as our main language, but seeing as .Net 4 just came out and I've been given the go ahead to start using it if it streamlines my work or helps to save me time (we have win2008 r2 servers hosting our web app through apache/mysql), I'd be a fool to stay with it. Granted, it will be side-projects and small stuff at first, but I'd be lying if I said that I wasn't excited as could be.

Being the only developer in these situations makes you appreciate certain things, and one of those is a solid IDE with a proper debugger. Another is a language that is constantly being pushed forward. But the most important is code that doesn't look like it was written by a couple of high schoolers is has decent maintainability.

So, I have a feeling I'm going to be seeing some grass-is-greener aspects from both sides (AJAX, etc). I will, however, be using ASP.net 4 w/ MVC 2 and thankfully we're able to leverage SQL Server Express so really, our buy-in is some of my time and Visual Studio 2010.

Hmm...

Well, I'm at work so I can't do a full in-depth reply just yet, but I can comment on a few things:

Dynamic HTML:

You do know you can still do this right? Sure, its a bit more work, but the entire reason asp.net was built was so the developer didn't HAVE to handle every single freaking thing as a dynamic output and could concentrate more on other things. The option is still there to do everything dynamically.

Maintaining state:

I haven't used hidden inputs in forever. I use a mix between SQL storage, serialized objects, and the viewstate for persisting anything I need. I also have access to caching mechanism on whatever server I want to cache stuff on.

Event misfiring:

What, you've never debugged a ASP.Net app before? Including using the IDE for JavaScript debugging? sh*t, VS2k10 just came out with a full tracking program for recording test cases and playing the whole thing back.

ASP.Net built in controls:

Sure, a lot of them are basic, until you learn how to use them. Creating bindable objects and binding them to controls with wired up events is bad-ass. On top of that you can easily extend the controls to suit your own needs, or even just ignore them and make your own.

Ajax:

MS integrated JSON and JQuery into the IDE. Hell, the new VS has code completion for it. Even better, you can implement your own, as I do on my projects.

I'll look over your post a bit more later on in the data but it sounds like you want a fully OOP platform that works as trivially as a scripting system.

So, I have a feeling I'm going to be seeing some grass-is-greener aspects from both sides (AJAX, etc). I will, however, be using ASP.net 4 w/ MVC 2 and thankfully we're able to leverage SQL Server Express so really, our buy-in is some of my time and Visual Studio 2010.

In case you need it both Oracle and MySql have .net libraries for database connectivity. They are WAY better than MS's implementation for those RDBMS systems.

As a language, PHP is way behind C#. I'll say that as much as anyone. The difference is the framework used and what's available. Really, ASP.net is a framework. So, compare it to, say, using PHP and CodeIgnighter. Somebody could technically use C# to write their own spaghetti application without ASP.net. The difference is, ASP.net also allows for many, many ways to do the same thing; whereas in other frameworks, there are usually only one or two. So, in ASP.net you see a lot (A LOT) of poorly-written spaghetti crap as well.

Now, if you're starting fresh and using MVC2, I can see that going well. After all, you're starting over using your tool of choice in an environment you create. You could create the same ideal world using PHP and Kohana or Django, etc.

I'm in the same boat (except ASP.net/SQL Server was a mandate) and like I said, I have high hopes. But maintaining any legacy ASP.net apps is as painful (if not *more*, believe it or not) as maintaining a legacy PHP codebase. At least PHP is almost fully backwards-compatible. I really feel for you, though, I've been there.

Dr.Ghastly wrote:

Dynamic HTML:

You do know you can still do this right? Sure, its a bit more work, but the entire reason asp.net was built was so the developer didn't HAVE to handle every single freaking thing as a dynamic output and could concentrate more on other things. The option is still there to do everything dynamically.

Yeah, I know you *can*, but my point is that nobody does. So, if I have to maintain an application (or fix it, ugh), the previous developer may have used any one of the myriad shortcuts that ASP.net makes available and encourages people to use. The problem with those shortcuts is that they end up taking more time in the long run than just doing it "the long way."

Maintaining state:

I haven't used hidden inputs in forever. I use a mix between SQL storage, serialized objects, and the viewstate for persisting anything I need.

The "ViewState" uses lots of hidden inputs. My point is they're shoehorning state into a stateless world. It's very messy behind-the-scenes.

Event misfiring:

What, you've never debugged a ASP.Net app before? Including using the IDE for JavaScript debugging? sh*t, VS2k10 just came out with a full tracking program for recording test cases and playing the whole thing back.

That would be swell to use; I'm used to just using FireBug and tracing to logs. Call me old-fashioned.

ASP.Net built in controls:

Sure, a lot of them are basic, until you learn how to use them. Creating bindable objects and binding them to controls with wired up events is bad-ass.

Another instance of trying to make the web something it isn't. I think this is the root of my beef with the whole thing.

Ajax:

MS integrated JSON and JQuery into the IDE. Hell, the new VS has code completion for it. Even better, you can implement your own, as I do on my projects.

jQuery, blech. But that's another post. I guess debugging client-side script in the development environment seems to be a very round-about solution. Why not just be able to debug in the actual environment being delivered to? And people why VS is bloated.

I'll look over your post a bit more later on in the data but it sounds like you want a fully OOP platform that works as trivially as a scripting system.

I think the word "trivially" is a bit harsh; but for the most part, yes. The web is not a desktop application, and it never will be. It's fundamentally a different way of doing things. ASP.net attempts to force it to be what it's not.

Yeah, I know you *can*, but my point is that nobody does. So, if I have to maintain an application (or fix it, ugh), the previous developer may have used any one of the myriad shortcuts that ASP.net makes available and encourages people to use. The problem with those shortcuts is that they end up taking more time in the long run than just doing it "the long way."

Why the hell would I want to when I can create a nice OOP implemented application that separates the UI from the BL and DL?

The "ViewState" uses lots of hidden inputs. My point is they're shoehorning state into a stateless world. It's very messy behind-the-scenes.

The viewstate is a name-value list in base64 attached to most asp.net pages. It can be encrypted and manipulated based on what the developer needs to do. It's also not 100% necessary to use. I don't see where you think it's messy.

Another instance of trying to make the web something it isn't. I think this is the root of my beef with the whole thing.

How? How are pre-built controls you can use, extend, or ignore completely making the web something it is not? These things get rendered as html objects. Are you saying you have never gone into php (or whatever) and made an object for rendering a html table with data you passed to it? I sure as hell don't want to cut and paste code all over the damn place when I have access to reusable code that is easier to maintain.

baggachipz wrote:
Dr.Ghastly wrote:

Event misfiring:

What, you've never debugged a ASP.Net app before? Including using the IDE for JavaScript debugging? sh*t, VS2k10 just came out with a full tracking program for recording test cases and playing the whole thing back.

That would be swell to use; I'm used to just using FireBug and tracing to logs. Call me old-fashioned.

Unfortunately this is only in VS 2010 Ultimate, from what I could tell.

baggachipz wrote:

As a language, PHP is way behind C#. I'll say that as much as anyone. The difference is the framework used and what's available. Really, ASP.net is a framework. So, compare it to, say, using PHP and CodeIgnighter. Somebody could technically use C# to write their own spaghetti application without ASP.net. The difference is, ASP.net also allows for many, many ways to do the same thing; whereas in other frameworks, there are usually only one or two. So, in ASP.net you see a lot (A LOT) of poorly-written spaghetti crap as well.

Completely understand that. I've used CodeIgniter and other PHP frameworks, but none of them have really impressed me. Add in the fact that I fell in love with C++ in college, it's easy to see that I'm quite enjoying C#.

baggachipz wrote:

Now, if you're starting fresh and using MVC2, I can see that going well. After all, you're starting over using your tool of choice in an environment you create.

That's the exciting part

Dr.Ghastly wrote:
So, I have a feeling I'm going to be seeing some grass-is-greener aspects from both sides (AJAX, etc). I will, however, be using ASP.net 4 w/ MVC 2 and thankfully we're able to leverage SQL Server Express so really, our buy-in is some of my time and Visual Studio 2010.

In case you need it both Oracle and MySql have .net libraries for database connectivity. They are WAY better than MS's implementation for those RDBMS systems.

I've been aware of the MySQL one, and that should help me with migrating to SQL 2008. Having to rebuild so much is daunting, at times, but exciting when I think of if and when I pull it off.

baggachipz wrote:

I'm in the same boat (except ASP.net/SQL Server was a mandate) and like I said, I have high hopes. But maintaining any legacy ASP.net apps is as painful (if not *more*, believe it or not) as maintaining a legacy PHP codebase. At least PHP is almost fully backwards-compatible. I really feel for you, though, I've been there.

Yeah, it stinks

IMAGE(http://imgur.com/GMH9S.jpg)

Dr.Ghastly wrote:

Why the hell would I want to when I can create a nice OOP implemented application that separates the UI from the BL and DL?

Part of the problem is that it doesn't necessarily separate those things. The datalist, for instance, allows one to put business logic on the page (the display layer) by specifying what shows up on the page in the query (er, datasource). But, that's only one example. It certainly is possible to separate the UI from the business logic. ASP.net just doesn't encourage it.

How? How are pre-built controls you can use, extend, or ignore completely making the web something it is not? These things get rendered as html objects. Are you saying you have never gone into php (or whatever) and made an object for rendering a html table with data you passed to it? I sure as hell don't want to cut and paste code all over the damn place when I have access to reusable code that is easier to maintain.

They get rendered as HTML, but you have no control over those objects under the covers. Sure, you can extend them, and that's neat. I do it all the time in this and other development environments. That wasn't my point. My point is that it creates an entire meta-language, event model, and data layer ON TOP of a language and output mechanism. I create view helpers in MVC apps all the time, and at the end of the day they're just snippets of code that use views to output html. The difference is, I can use the existing code language to make this happen. ASP.net's process is overkill and makes everything way more complex than it has to be. That's my beef.

So your issue is a framework that has basic implementation provided is too much to work with and you want to have to write everything by hand yourself. Alrighty.

Dr.Ghastly wrote:

So your issue is a framework that has basic implementation provided is too much to work with and you want to have to write everything by hand yourself. Alrighty.

Sigh. No, not at all. There is, however, a healthy and non-maddening balance between a clean slate and hand-holding with training wheels.

Good frameworks are good. Bad frameworks make things worse. Bloated, bad frameworks make me want to stab things.

baggachipz wrote:
Dr.Ghastly wrote:

So your issue is a framework that has basic implementation provided is too much to work with and you want to have to write everything by hand yourself. Alrighty.

Sigh. No, not at all. There is, however, a healthy and non-maddening balance between a clean slate and hand-holding with training wheels.

Good frameworks are good. Bad frameworks make things worse. Bloated, bad frameworks make me want to stab things.

You're coming from the standpoint that the framework sucks because it won't let you do things the way your used to in asp (or php..etc) as well as having to deal with crap other developers built.

I'm saying that not only will it let you do that, but on top of that why the f*ck would you when you have this vast library of useful code to help you out.

Ive worked in many languages and platforms. I have yet to run into one that doesn't give the developer enough rope to hang themselves and piss me off.

I guess the crux of the disagreement is whether the components and their method of implementation in ASP.net are of high quality or not. To me, it's not and it drives me nuts. You seem to like it.

If ASP.net were just C# and a bunch of libraries that allowed me to control html output *directly*, I would love it It's not; there's a ton between me and the output and if you ask me, it makes the whole process unbearable. I didn't want this thread to be a geek fight, just a geek rant!

baggachipz wrote:

I guess the crux of the disagreement is whether the components and their method of implementation in ASP.net are of high quality or not. To me, it's not and it drives me nuts. You seem to like it.

If ASP.net were just C# and a bunch of libraries that allowed me to control html output *directly*, I would love it It's not; there's a ton between me and the output and if you ask me, it makes the whole process unbearable. I didn't want this thread to be a geek fight, just a geek rant! :roll:

THUNDERDOME! TWO GEEKS ENTER, ONE LEAVES! THEN, LATER THE OTHER GEEK LEAVES!

Dr.Ghastly wrote:
baggachipz wrote:

I guess the crux of the disagreement is whether the components and their method of implementation in ASP.net are of high quality or not. To me, it's not and it drives me nuts. You seem to like it.

If ASP.net were just C# and a bunch of libraries that allowed me to control html output *directly*, I would love it It's not; there's a ton between me and the output and if you ask me, it makes the whole process unbearable. I didn't want this thread to be a geek fight, just a geek rant! :roll:

THUNDERDOME! TWO GEEKS ENTER, ONE LEAVES! THEN, LATER THE OTHER GEEK LEAVES!

And another geek sits outside yelling, "Rails is better! UNIX forever!"

*Legion* wrote:
Dr.Ghastly wrote:
baggachipz wrote:

I guess the crux of the disagreement is whether the components and their method of implementation in ASP.net are of high quality or not. To me, it's not and it drives me nuts. You seem to like it.

If ASP.net were just C# and a bunch of libraries that allowed me to control html output *directly*, I would love it It's not; there's a ton between me and the output and if you ask me, it makes the whole process unbearable. I didn't want this thread to be a geek fight, just a geek rant! :roll:

THUNDERDOME! TWO GEEKS ENTER, ONE LEAVES! THEN, LATER THE OTHER GEEK LEAVES!

And another geek sits outside yelling, "Rails is better! UNIX forever!"

IMAGE(http://iarmar.com/blog/wp-content/uploads/2009/09/bill-gates-1983.jpg)

*Legion* wrote:

And another geek sits outside yelling, "Rails is better! UNIX forever!"

Make that two geeks. Rails is freaking awesome.

Dr. Ghastly, I'm a little bit frightened by your pin-up photo of Bill Gates.

ClockworkHouse wrote:
*Legion* wrote:

And another geek sits outside yelling, "Rails is better! UNIX forever!"

Make that two geeks. Rails is freaking awesome.

Dr. Ghastly, I'm a little bit frightened by your pin-up photo of Bill Gates.

And yet another sits out there chanting "Developers, developers, developers, developers"

I love doing the things I can do with code

Microsoft took it upon themselves to shoehorn the web platform (html) into a desktop programming paradigm, complete with state and event models. It's an attempt to mask the stateless, markup-driven web environment and instead treat the web as another desktop platform. Perhaps a noble intention, but at the end of the day it falls short -- waaaay short.

You can't really blame MS for that. It wasn't their idea, they're just another implementation of that.

[ASP.net (at least, in its classic "forms" setup) relies on convoluted hidden inputs on a page to maintain state and handle events. Inputs that are placed on a page are modified (in name and functionality) before actually being output to the browser. This is all done behind-the-scenes; as far as ASP.net is concerned, you create your app in its environment and it will handle the output mechanism.

It *can* be like that, yes. And it is that way because of the VB6 target market that MS was trying to bring into the OO world kicking and screaming. (that's a little jibe, not a troll. )

That's fine and dandy, I suppose, but what if it's not working correctly? What if you need to get under the hood and understand why, say, a "event" isn't firing? (I put event in quotes because it's not a REAL event; it's a post-back with specific form parameters.) Well, too bad. You can't.

Yeah you can. But you have to, as you also mention about MS not trusting developers to know HTML/HTTP, actually know what you're doing. You have to get into some serious nitty gritty.

You're relying on a black-box that's inserted between you and the actual environment your user interacts with.

It's only a black-box if you let it be. Rather, it's a black-box by default, because that's what the old VB6 guys were used to (and thought they wanted) - you drag a "widget thingy" onto the surface of your "app thingy" and set some "values in a form thingy" and it Just Works(tm). (This is not accusative or a troll either. I've actually worked with "developers" like this.)

There's a LOT of web devs that actually work like that, and when sh*t goes wrong, regardless of platform, have no goddamn clue how to figure it out.

I've worked with CS Masters grads that looked at me like I was a one-eyed, one-horned flying purple people-eater when I asked "Well, did you alert your form values in javascript?"

If it's not in the debugger, they had no friggin' clue how to deal with it.

Anyway, my point is, you *can* get under the hood. But you (and I) probably don't want to.
Try ASP.NET MVC - it looks to be a nice middle ground between the best of what ASP3 gave us and the best of what the (wonderful) .Net platform gives us.

In my limited explorations with C#, it seems to be a very well designed language. It's too bad it is hamstringed by all the extra cruft of .NET. If you are forced into a MS/.NET environment for web development, here are two possible solutions:

IronPython
IronRuby

I do all my web dev work with Python or Ruby. I began on PHP and once I found Python, I realized what a horribly designed language PHP is.

Both Iron languages are still given short shrift in the IDE/Integration area.
Maybe VS2010 makes them 1st Class Languages, but in 2008, they fall short of "just works".

Another pseudo-solution to being required to use ASP.Net is to just not use VIEWSTATE. Or pick and choose which controls get saved to the VIEWSTATE. You'd be amazed at how zippy you can make ASP.Net by simply not having everything automatically get saved in the VIEWSTATE. And doing so brings you back to a more stateless web.

ASP.Net does a lot of things wrong, but you can get around nearly all of them by eschewing the Default on many things.

ASP.NET is really bad in my opinion.

ASP.NET MVC is excellent.

The main reason I chose ASP.NET MVC for my personal web project is that you have a TON more control over the HTML markup and what is actually being rendered. That coupled with a vastly better separation of concerns (model/controller/view), you get some really powerful control over your application.

The other thing I've discovered is jQuery. There is almost no reason to do javascript any other way.

For debugging jQuery and Javscript... Chrome Dev tools & Firefox + Firebug... all you need.

I agree with both points here. The main problem I see is that ASP .NET using Web Forms is basically a 7 year old technology. It was made in a time when AJAX didn't exist. When used as a server side technology it's great, when you try to shoehorn complicated Java script on top of it it's not so great.

PS: If your using any of the wizards, your doing it wrong.

ARISE, thread of hate!

I've been using ASP.net MVC 2 for a little bit now, and for the most part it is pretty good. It still has some maddeningly stupid things going on. Things that were taken care of in PHP MVC frameworks eons ago.

Take, for instance, checkboxes. Any other framework has a simple helper where you can construct an array of checkboxes with the same form name, and populate it with an array of different values. These helpers usually include label generation and all that fun stuff.

However, in ASP.net MVC, the Html.CheckBox acts completely different. Instead of simply making a checkbox, it creates a checkbox with a hidden form field value, and when you get that value back in your controller, the values either come back as an array of "true, false" if the user selected the checkbox or a one-item array of "false" if it was not selected. I am not making this up. This sort of thing is so maddeningly stupid, so easy to implement. I'm half astonished at this glaring stupidity/oversight and half enraged by it. Only ASP.net could take something as simple as a checkbox value and turn it into an exercise in frustration. This is exactly what I'm talking about in this whole discussion.

The defenders will say something like "well then, you can write your own helper!" That's not the point. The point is, a framework is SUPPOSED to make things faster for me, not slower.

NERD RAGE RAAAWWWWRRRRRRR

Also, another thing. The documentation that readily exists is sub-par at best. The only real official example to go on is the "Nerd Dinner" sample application which is nothing but a simple CRUD application with textboxes. Whooptie-freakin'-do. I've had to rely on searching around all over the place, and that task is made excruciating because even though ASP.net forms and ASP.net MVC are completely different (the latter assumes you abandon the former entirely), their similarity in names ensures that all search results are mixed. This means I get to dig through search results and find the one in 15 links that actually pertains to the MVC package and not the old "classic" one. Boy, I sure do love things that waste my time. /s

However, in ASP.net MVC, the Html.CheckBox acts completely different. Instead of simply making a checkbox, it creates a checkbox with a hidden form field value, and when you get that value back in your controller, the values either come back as an array of "true, false" if the user selected the checkbox or a one-item array of "false" if it was not selected. I am not making this up.

I read the link, read why they do it, and it makes sense to me.

Dr.Ghastly wrote:

I read the link, read why they do it, and it makes sense to me.

OK, you've left me no choice:

IMAGE(http://www.ecoshuttle.net/wp-content/uploads/2007/09/small-web-plant.jpg)

Anyway, I created a custom CheckBoxList control that does what I want. If anyone would like the code let me know. It could also be made into a RadioButtonList control pretty easily.

Dr.Ghastly wrote:
However, in ASP.net MVC, the Html.CheckBox acts completely different. Instead of simply making a checkbox, it creates a checkbox with a hidden form field value, and when you get that value back in your controller, the values either come back as an array of "true, false" if the user selected the checkbox or a one-item array of "false" if it was not selected. I am not making this up.

I read the link, read why they do it, and it makes sense to me.

Didn't read the link, but that sounds really nice for some applications, such as loading data into a webform and knowing if the user changed it or not.

TriggerHappy wrote:
Dr.Ghastly wrote:
However, in ASP.net MVC, the Html.CheckBox acts completely different. Instead of simply making a checkbox, it creates a checkbox with a hidden form field value, and when you get that value back in your controller, the values either come back as an array of "true, false" if the user selected the checkbox or a one-item array of "false" if it was not selected. I am not making this up.

I read the link, read why they do it, and it makes sense to me.

Didn't read the link, but that sounds really nice for some applications, such as loading data into a webform and knowing if the user changed it or not.

That's pretty much the reason for why they did it, especially for stuff like gridviews and other bubble event type objects.

Dr.Ghastly wrote:
TriggerHappy wrote:
Dr.Ghastly wrote:
However, in ASP.net MVC, the Html.CheckBox acts completely different. Instead of simply making a checkbox, it creates a checkbox with a hidden form field value, and when you get that value back in your controller, the values either come back as an array of "true, false" if the user selected the checkbox or a one-item array of "false" if it was not selected. I am not making this up.

I read the link, read why they do it, and it makes sense to me.

Didn't read the link, but that sounds really nice for some applications, such as loading data into a webform and knowing if the user changed it or not.

That's pretty much the reason for why they did it, especially for stuff like gridviews and other bubble event type objects.

I'll continue to incredulously furrow my brow at such assertions, but I will say that most of the rest of ASP.net MVC has been a relatively pleasant experience (excepting the rants I've had above). Strong type-hinting and step-by-step debugging have been life-savers. As long as I stay away from pseudo-event-driven controls and other nonsense, I'm pretty happy.

No! Back to ASP.net hate! Far more entertaining to read.