I agree that webforms are unmaintainable myself, but for the following reasons:

To me webforms when used with its server controls is just a leeky abstraction of HTML. Id much rather be able to see the actual html when I am looking at the aspx code file as is the case with MVC. But overcoming this issue whats worse is that, In order to understand what the page is trying to render one has to be flicking between the markup and the codebehind, since they are just so tightly coupled together. The codebehind needs to know all the controls on the ui and needs to set all their values etc. Personally I dont see how this makes a maintainable frontend.. Multiply this by the number of pages that you have in your site...

Viewstate is just being abused too much, in my opinion it should have just been off by default so that users have to explicitely enable it for the controls that actually need it. That way it saves us from having to toss around 1MB+ of viewstate data. Again the __dopostback paradigm means that we are completely ignoring the 5% of the users that dont have javascript disabled, (this is 5000 for every 100k visitors) as well as any WAI and WCAG accessibility guidelines...

I much rather prefer the tidyness of the proposed MVC approach where the UI is simply 'pulling' the information it needs from the viewdata, and the controller is not pushing this info to specific controls, it doesnt need to know them, its just pushing it to the viewdata - the UI logic in our markup kicks in to put the right viewdata at the right places. (sweet :-) At a glance you can understand how the page is about to be rendered without having to flick between controller and markup as you need to do with webforms...

Simple is better, all we are talking about is HTTP request... all the page lifecycle events just adding to the complication where things could have just been simpler, (again take a look at MVC lifecycle http://weblogs.asp.net/stephenwalther/archive/2008/03/17/asp-net-mvc-in-depth-the-life-of-an-asp-net-mvc-request.aspx)


just my 2c

by the way, didnt mark it as spam!

Tried seeing the blog but it was down at the time...
Here is the direct link: http://labs.live.com/volta/

Sorry, I guess I was a little to hasty on the keyboard there! Thats true, stepping back a little and looking at the overall picture what counts is that you have some information about the error. In fact, if you are the only guy working on the development of the application this is perfectly ok. But I think it is quite important for example, in a scenario where you are creating a reusable library or component, It is good practice to make use of InnerExceptions to rethrow errors in a way this post describes. When you wrap up the exceptions like this you are more likely to throw a more meaningful error to the developers who are trying to use your library in their application. More meaningful errors = better debugging experience for those developers.

Yeap, this is the right way,
The other previous article saying the 'rethrowing exceptions the right way' kicked to the front page needs burying in my opinion (if there was such an option..) Simply for the reason that it mislead people to believe that, that was the right way when in fact the one described here is

Edelman, you cant get any clearer than that, and I have to admit that your solution is elegantly right!:)

I was missing the point you were trying to make but this example is pretty clear, didnt expect it to work in all honesty, I was pretty sure that, the layout would break but of course it didnt!
Maybe you should include this example in your post to make it a bit clearer for annoying people like me and save you from some future arguments :D

@Edelman:
I dont think I fully understood what you are trying to say, but if I understand correctly, you are providing different class names to your divs (with the rationale that future changes could occur) , and because of this your solution is different to the one posted here.
In my personal opinion using the naming convention you have employed is misleading, because looking at the html one gets the impression that they can write text between the other three surrounding divs and at the same time retain the layout and the rounded corners. However if some tried to go ahead and add text to those divs as you say, the layout would brake.

One could use the divs as wrapper divs containing textual content only in the case when they eventually decide to ditch the rounded corners. As far as I can see in your example the sole purpose of each individual div is to hold one rounded corner, so you might as well name have named them as blue-top-left etc, at least then it will not potentially mislead a third developer into thinking that they can write content into those divs without breaking the layout.
Please let me know if I am missing something here, and what else is different in your proposed solution than this one posted here.

@Edelman: I dont see how your solution is sematically any different than the one proposed in this post. From the point that empty nested divs are being emplyed to accomodate a visual effect semantics have been broken. I agree that round corners on a *fluid* layout arent worth it really as the standard support stands currently.

Oh, if you simply want rounded borders, as an alternative you can do this the CSS way also (mozilla/FF and safari only)
-moz-border-radius: 15px; /* mozilla/FF */
-webkit-border-radius: 15px; /* safari */

Again there is a W3C CSS3 recommendation of border-radius
http://www.w3.org/TR/2002/WD-css3-border-20021107/#the-border-radius

And that draft has been around since 2002...
I wonder Is this such a demanding feature that the browsers have not implemented it yet (5 years later and counting)
and when they do implement it, it is with some custom css markup instead of the proposed... ah the joy of browsers!

trying to have round corners using the background-image technique for a fluid layout I'd say that this article shows the way to do it,
but admittedly having to code 4 levels of empty divs for every 'box' that requires round corners just seems a little bit too much.

Ideally what we want to accomplish here is to have multiple backgrounds on one div. This scenario is specified in the CSS3 draft
ref: http://www.w3.org/TR/css3-background/#layering
but the only browser that supports this feature at the moment is safari.

There is an alternative if you need rounded corners and you feel like cheating a bit , check this out if you havent seen it already:
http://acko.net/blog/anti-aliased-nifty-corners

I only call it a cheat because it uses javascript
;)

Well I guess im not, now im getting a different error:
[HttpException (0x80004005): Server Too Busy]

I guess this was to be expected to some extent.

Am I the only one getting an error trying to access the microsoft subscription page?

It seems to be redirecting through
https://msdn.one.microsoft.com/home.aspx

Error: The file '/home.aspx' has not been pre-compiled, and cannot be requested.

Indeed not .NET related directly... But given the skillset of most Net devs (CSS, HTML javascript even web design!), this place is something of value for those .Net developers :)

eeek - its supposed to be iterator not itirator!

Not quite the way I posted it, maybe DNK should replace the LineBreaks should with <br> tags when someone submits a story. It would make the post more readable.

@offwhite: IMHO having the ad at a fixed position as you have it I find more distracting rather than have it flow naturally with the content. Its just screeming for attention and distracts the user from the actual content. Is the adsense revenue really worth doing this to your site?

@Powerrush: You can click on the 'View Entire Article' link

Still, I agree that, that site seems to be over bloated with screaming ads