I am as of yet reasonably noobish as far as Asp.Net is concerned, but am I spouting complete bollocks when I think it's strange that the .Net framework has provisions for outputting HTML? I thought the codebehind was so that the business code was behind the presentation layer. Instead, developers are apparently (implicitly) invited to interweave presentation with business code, making changes harder. Isn't this why the aspx/cs paradigm was invented in the first place?

Of course, the whole separation of presenation/business/data is an ideal that can be approached but never fully reached because the world is imperfect etc, but seriously, HtmlWriterElementOutputterTag() and the specific html-tag classes like Table and its subsidiaries really need to die in a bright fire with the intensity of a hot proton soup the weight of a million compacted suns.

dhromed:

... but seriously, HtmlWriterElementOutputterTag() and the specific html-tag classes like Table and its subsidiaries really need to die in a bright fire with the intensity of a hot proton soup the weight of a million compacted suns.

 

 You surely do know that "weight of a million suns" isn't that heavy, do you?

 

BTW, there has been such a nice thread in the past few months ... with pictures of wooden tables and something on them, recursively ... but I can't find it anymore.
Is there something like a "thread purge" going around?

 

The idea of CodeBehind (which is just a class that your .aspx page inherits from) is to make UI manipulation easier. And since the UI is in HTML, things need to be HTML-centric. But... aspx/cs is all still just the UI.

dhromed:

Of course, the whole separation of presenation/business/data is an ideal that can be approached but never fully reached because the world is imperfect etc, but seriously, HtmlWriterElementOutputterTag() and the specific html-tag classes like Table and its subsidiaries really need to die in a bright fire with the intensity of a hot proton soup the weight of a million compacted suns.

Well, there are a few use-cases that you can't really cover with templates/widgets. In particular, suppose you want to write a forum, where people can submit HTML-formatted posts. You'd have to build some pretty complex logic to assemble all the formatting out of widgets - or you can just clean(!) the user's HTML and output it straight away.

Our FOS team was creating a bunch of label objects with html as opposed to binding a repeater element :(

PSWorx:

dhromed:

Of course, the whole separation of presenation/business/data is an ideal that can be approached but never fully reached because the world is imperfect etc, but seriously, HtmlWriterElementOutputterTag() and the specific html-tag classes like Table and its subsidiaries really need to die in a bright fire with the intensity of a hot proton soup the weight of a million compacted suns.

Well, there are a few use-cases that you can't really cover with templates/widgets. In particular, suppose you want to write a forum, where people can submit HTML-formatted posts. You'd have to build some pretty complex logic to assemble all the formatting out of widgets - or you can just clean(!) the user's HTML and output it straight away.

I'll give you a more simple and fundamental example: what do you think was used to create the set of System.Web.UI.WebControls 'widgets'?

The tag writing classes exist because they are what should be used when authoring those kind of controls, commonly refered to as 'custom controls'. The tag writing classes make sure that all HTML output is well-formed, that attributes are properly escaped and don't appear more than once on a tag, etc. Basically it's the well structured alternative to error-prone string concatenation.

This is also why they never should be removed from the .NET framework or be put into an internal scope. Whoever is suggesting otherwise is indirectly suggesting use of low-level string concatenation for writing custom controls. I hope we can all agree that this would be The Real WTF ™.