It feels dirty. But maybe it isn’t… is it ok to use a StringBuilder for writing XML? My gut instinct says “although this feels wrong, it’s probably pretty darn performant because it’s not loading extra libraries and overhead it’s not doing whatever extra method calls XmlWriter invokes.” It also seems like it’s just less code in general. What’s the benefit in XmlWriter?
Here’s what it looks like. I’m building an OpenSearch XML doc based on the domain you come in from.
public void ProcessRequest(HttpContext context)
{
context.Response.ContentType = "text/xml";
string domain = WebUtils.ReturnParsedSourceUrl(null); //returns something like www.sample.com
string cachedChan = context.Cache[domain + "_opensearchdescription"] as String;
if (cachedChan == null)
{
StringBuilder sb = new StringBuilder();
sb.Append("<?xml version=\"1.0\" encoding=\"UTF-8\"?>");
sb.Append("<OpenSearchDescription xmlns=\"http://a9.com/-/spec/opensearch/1.1/\" xmlns:moz=\"http://www.mozilla.org/2006/browser/search/\">");
sb.Append(" <ShortName>Search</ShortName>");
sb.Append(" <Description>Use " + domain + " to search.</Description>");
sb.Append(" <Contact>contact@sample.com</Contact>");
sb.Append(" <Url type=\"text/html\" method=\"get\" template=\"http://" + domain + "/Search.aspx?q={searchTerms}\" />");
sb.Append(" <moz:SearchForm>http://" + domain + "/Search.aspx</moz:SearchForm>");
sb.Append(" <Image height=\"16\" width=\"16\" type=\"image/x-icon\">http://" + domain + "/favicon.ico</Image>");
sb.Append("</OpenSearchDescription>");
cachedChan = sb.ToString();
context.Cache.Insert(domain + "_opensearchdescription", cachedChan, null, DateTime.Now.AddDays(14), TimeSpan.Zero);
}
context.Response.Write(cachedChan);
}
Followup, ~2 years later
I realized that what I meant to say, and completely failed to say it is: what is the benefit of gobs of code using XML classes to generate this file, vs. just using strings? Is there one? Is this worse than (for example) John Saunder’s example?
I used Jim Schubert’s method, opting for ‘I can read this and it makes sense’ rather than vying for ‘correctness’. I’m glad I did. There’s nothing wrong with John Saunder’s example- but I felt that it was way overbearing for what I was trying to accomplish. Pragmatism? Maybe.
That’s very wrong. Use one of the .NET APIs which understand XML to write XML.
Using a
System.Xml.XmlWriterwill not cause any performance problem by loading “any extra libraries”.The reason to use the XML APIs is that they understand the rules of XML. For instance, they’ll know the set of characters that need to be quoted inside an element, and the different set that need to be quoted inside an attribute.
This might not be an issue in your case: maybe you’re certain that
domainwill not have any characters in it that will need to be quoted. In any broader situation, it’s best to let the XML APIs do XML – which they know how to do – so you don’t have to do it yourself.Here’s an example of how easy it is to produce valid XML using LINQ to XML: