I meant more overhead in terms of creating instances of objects that ultimately take up system resources. If I want to create a simple anchor tag, with the HTMLTextWriter, I am creating instances of two objects the HTMLTextWriter and the StringWriter which is required by the HTMLTextWriter constructor. With the helper class I simply call a static method that returns a string.

Don't get me wrong. I know there is a time in which the HTMLTextWriter should be used. This helper class is not designed to be used in those circumstances. Just a simple helper to quickly generate some HTML quickly.

This is great! I think too many developers underrate the use of patterns. Design patterns provide you with so many great things (e.g. leaner code, faster ramp-up time for new developers, just to name a couple).

Great article! True moral character is uncommon these days.

COFFEE==)

severe

I've only had a few published but seemed to have taken a sever beating on this one.

I guess what everyone is not understanding is that there are few cases in some of my applications where I just need a quick peice of HTML generated and I would rather not have the overhead of generating an instance of an HTMLTextWriter and the StringWriter required for it's constructor. If I were building an application that generated large amounts of HTML on a consistent basis I would agree - ( As I stated above) that the HTMLTextWriter is the appropriate way to do this.

This is typical developer ego in action - try to trump the other developers. This attitude is what complicates software development in almost every shop. There is always more than one way to do something, and there is always the right and wrong way but all should be evaluated within the context of the application.

Man! You guys are ruthless. I have a simple class here that I use to generate some simple HTML. As I stated before - it is NOT the end all be all. What is the result of the HTMLTextWriter.Innerwriter.ToString() (which is what has to be called to get the resulting HTML) OMG it's a string! The same as the Helper output. You guys are wack. I am not trying to build the fastest most secure HTML generator on the face of the earth, this is just a class that I use occassionaly and thought most people here would be wise enough to take it with a grain of salt.

After reading these comments I am realizing that it is the tendency of most developers to over-complicate almost everything. You should realize that this class is just a simple helper class to generate limited html. I am not suggesting that you generate all of your HTML with this class. Ther are always cases where an HTMLTextWriter would be a better solution. In terms of encoding, in my use of this class my Ajax class and my server side aspx page manage the encoding and un-encoding of the information going back and forth. This is not by any means and end all be all. Just a helper that might save a few folks some time. Remember KEEP IT SIMPLE. All of these points brought up should be addressed based on your individual use of HTML generation.

But they are all valid points. Don't get me wrong, I am not discounting anyones opinions here.

I'm not sure what you mean by that. Are you saying that the HTML Helper class doesn't encode attributes? When using the HTMLTextWriter to render a control, you get the same output HTML. With or without attributes.

Good point. I would agree, probably the way to go with limited usage.

You do, however, need to use HTMLTextWriter when rendering asp.net server controls as html.

There is more overhead associated with HTMTextWriter

That is a good point.