How To Destroy Your Web Developer Reputation in One Line, Guaranteed

11 Comments

• 
  If I just want to return XML that is in-memory to the browser what's the way of doing that without using Response.Write?
  

• Anon,
  
  
  
  I believe Daniel is after the misuse of Response.Write in pages, controls and the like. There are tons of apps out there that i.e. output giant parts of its UI by using a single call to Response.Write, thats *ugly*.
  
  
  
  There are specific cases when using Response.Write may be justified, i.e. when writing a handler.
  
  

• I have a custom server side control, why shouldn't I use Response.Write? Do I have to use tons of plaeholders and literals just because you thik we have to use them if Asp.net offers them?
  

• 
  Jerry I get the impression he is railing against people that do
  
  
  
  Response.Write( "<SCRIPT>window.location='sdfsdf';</SCRIPT>" );
  
  
  
  rather than ALL uses of Response.Write. I could be wrong :P
  

• Real world exception: web apps that are being iteratively ported to ASP.NET from ASP - could legitimately have response.write in there simply because the site is a work in process. This is a perfectly valid approach to migrating a site.
  

• Laurence, you're right. It's a legacy feature.
  
  Jerry and Anon (I'd like to know your name ;)):
  
  you shouldn't use Response.Write because that makes adaptive rendering of your control impossible. Your control will NEVER render anything targeted to specifc clients.
  
  And maintaining huge Response.Write statements is plain crazy. Any minor typo, improper indenting, etc, can completely break its layout. So unless your control is really trivial, it's going to be a pain in the ass of whoever will maintain it. Does spaghetti code mean something to you?
  

• You're definitely right there Ross!
  
  How about a [UglyCode] ? :)
  

• Hi,
  
  I was so concerned about my reputation that I try to replace a simple
  
  Response.write("<b>Something goes wrong<br/><textarea rows=\"5\" cols=\"40\">Some details</TextArea></b>");
  
  
  
  So I first found that the samples around uses the .render method (I want to put my message in a spcific point).
  
  
  
  So I added a literal control (MessaggioErrore) and use it as the rendering target.
  
  
  
  StringBuilder myStringBuilder = new StringBuilder();
  
  StringWriter myStringWriter = new StringWriter(myStringBuilder);
  
  
  
  string s = "Some details";
  
  HtmlTextWriter myHtmlWriter = new HtmlTextWriter(myStringWriter);
  
  myHtmlWriter.RenderBeginTag(HtmlTextWriterTag.B);
  
  myHtmlWriter.Write("Something goes wrong");
  
  myHtmlWriter.RenderBeginTag(HtmlTextWriterTag.Br);
  
  myHtmlWriter.RenderEndTag();
  
  myHtmlWriter.AddAttribute("rows", "5");
  
  myHtmlWriter.AddAttribute("cols", "40");
  
  myHtmlWriter.RenderBeginTag(HtmlTextWriterTag.Textarea);
  
  myHtmlWriter.Write(s);
  
  myHtmlWriter.RenderEndTag();
  
  myHtmlWriter.RenderEndTag();
  
  MessaggioErrore.Visible = true;
  
  myHtmlWriter.Flush();
  
  myStringWriter.Flush();
  
  
  
  MessaggioErrore.Text = myStringBuilder.ToString();
  
  
  
  Now I don't know how to render the "BR" tag... how can i told the writer that it should render as <br/>?
  
  The docs is very poor (compare WriteBeginTag with WriteFullBeginTag same description!!!!!)
  
  
  
  The difference from RenderBeginTag and WriteBeginTag isn't too clear to me :$
  
  The second seems more useful to me because is kind of a typed ones (there's a check for begin/end tags).
  
  I didn't realize how to use attribute with it!
  
  
  
  My reputation is safe, but I lost a couple of hours!
  
  
  
  Ciao
  
  CArlo
  

• Carlo: using a writer, while better than string concat with Response.Write, is still a risky proposition. The ideal way to build your UI is by composition of existing controls. If you need a label, create one and add it to your custom control child controls. Need to place then in a specific place in the page? Use a placeholder. And so on.
  
  John: first, I'm assuming you're emitting a dialog that should appear as soon as the page renders, as something wrong happened on the server. In that case, you should be using Page.RegisterStartupScript instead. What will it buy you? Well, if something can go wrong in multiple places, you only want ONE control rendering the alert. You don't want the user to receive multiple alerts just because you did Response.Write in each control that detected something wrong.
  
  In rendering controls, not using Response.Write is much more evident (and will be more so as newer versions of ASP.NET come along, with more and more control rendering adapters that can render your pages in multitude of target platforms). It's not too stretched to think that one day your server controls will render straight Windows Presentation Foundation code if the client happens to support it, therefore giving your site a much more compelling look in that platform. If you used Response.Write, you're out of the game.
  
  

• i think nick said it best. writing a ton of code to get the same functionality of reponse write is just turd polishing.
  

• I think there are valid occassions to use Response.Write. For example, let's say you want to create a tab-delimited file for the user to save. Something as follows seems reasonable to me:
  
  Response.ContentType = "application/excel";
  Response.AddHeader( "content-disposition","attachment; filename=AmazonShipmentNotification.csv");
  Response.Write("Qty\tItem\r\n");
  Response.Write("1\tHarry Potter Book\r\n");
  Response.End();