Making asp:TextBox do HTML5 input types

I was watching a presentation on HTML5 from one of my coworkers a few weeks ago and we were talking about the new input types in HTML5, like numbers and dates. They’re backward compatible with non-HTML5 browsers (which render them as text boxes), but provide very useful UI features particularly to smartphones where the on screen keyboard can change to be more appropriate.


Anyway, let’s just say they’re a good idea. A good idea that, much as I like ASP.NET, are not likely to make an appearance any time soon in the core framework. So, I looked around to see if I could figure out a way to patch a standard asp:TextBox to render these new HTML5 types. Yes, you MVC types already can do this easily. For the rest of us that are using third party CMS tools, WebForms is still the way of life :)


I came across a post by Phil Haack about a sneaky method of overriding HtmlTextWriter to change the attributes output by WebControls, and repurposed it to accomplish the HTML5-ization. Basically you override the AddAttribute() method and make it ignore the attribute you want to manually handle - in this case, the type attribute of the TextBox. Then I made a new TextMode-style enum that encompasses the HTML5 types and wrote a bit of logic that manually creates the right type attribute. The new enum is exposed in the Html5TextMode property, and the value is proxied back into the default TextMode property if it’s compatible with it.


So how do you use it? It’s pretty simple:

<prefix:Html5TextBox runat="server" Html5TextMode="Tel" ID="telephone" />

And the code for the control itself:

public class Html5TextBox : TextBox
{
 /// <summary>
 /// When using non-HTML5 constructs this mode will be accurate. If using HTML5, it will return SingleLine.
 /// </summary>
 public override TextBoxMode TextMode
 {
  get
  {
   try
   {
    return (TextBoxMode)Enum.Parse(typeof(TextBoxMode), Html5TextMode.ToString());
   }
   catch(ArgumentException) { return TextBoxMode.SingleLine; }
  }
  set
  {
   Html5TextMode = (Html5TextBoxMode)Enum.Parse(typeof(Html5TextBoxMode), value.ToString());
  }
 }

 /// <summary>
 /// Sets the text mode of the control including HTML5 text modes such as Num and DateTime
 /// </summary>
 public Html5TextBoxMode Html5TextMode
 {
  get
  {
   object textMode = this.ViewState["5Mode"];
   if (textMode != null)
   {
    return (Html5TextBoxMode)textMode;
   }
   return Html5TextBoxMode.SingleLine;
  }
  set
  {
   this.ViewState["5Mode"] = value;
  }
 }

 /// <remarks>
 /// Adds the normal attributes (since the writer is actually a PatchedHtmlTextWriter from Render() the type attribute won't be rendered),
 /// then explicitly adds the appropriate type attribute including the HTML5 extensions
 /// </remarks>
 protected override void AddAttributesToRender(HtmlTextWriter writer)
 {
  base.AddAttributesToRender(writer);

  string type = null;
  if (Html5TextMode == Html5TextBoxMode.SingleLine)
   type = "text";
  else if (Html5TextMode == Html5TextBoxMode.DateTimeLocal)
   type = "datetime-local";
  else type = Html5TextMode.ToString().ToLowerInvariant();

  if (type != null)
   (writer as PatchedHtmlTextWriter).AddTypeAttribute(type);
 }

 /// <remarks>
 /// Patches the type of HtmlTextWriter that the control renders to
 /// </remarks>
 protected override void Render(HtmlTextWriter writer)
 {
  base.Render(new PatchedHtmlTextWriter(writer));
 }

 /// <summary>
 /// A version of HtmlTextWriter that intentionally ignores the "type" attribute when it is added.
 /// </summary>
 /// <remarks>
 /// Technique courtesy of Phil Haack
 /// http://haacked.com/archive/2006/01/18/UsingaDecoratortoHookIntoAWebControlsRenderingforBetterXHTMLCompliance.aspx
 /// </remarks>
 private class PatchedHtmlTextWriter : HtmlTextWriter
 {
  internal PatchedHtmlTextWriter(HtmlTextWriter basis) : base(basis) { }

  public override void AddAttribute(HtmlTextWriterAttribute key, string value)
  {
   if(key != HtmlTextWriterAttribute.Type)
    base.AddAttribute(key, value);
  }

  public override void AddAttribute(string name, string value)
  {
   if(name != "type")
    base.AddAttribute(name, value);
  }

  /// <summary>
  /// Manually adds a type attribute
  /// </summary>
  public void AddTypeAttribute(string value)
  {
   base.AddAttribute(HtmlTextWriterAttribute.Type, value);
  }
 }
}

/// <summary>
/// Extends the TextMode enum with additional HTML5 types
/// </summary>
public enum Html5TextBoxMode { MultiLine, SingleLine, Password, DateTime, DateTimeLocal, Date, Month, Time, Week, Number, Range, Email, Url, Search, Tel, Color }

Sitecore multi-site installations and output caching

When running Sitecore in a multi-site configuration you may run into an odd issue: output caching may seem to get too greedy and not clear when you’d expect it to.

There’s a simple culprit: the default Sitecore setup includes an event handler, Sitecore.Publishing.HtmlCacheClearer, that is invoked on the publish:end event. This event handler has a list of sites assigned to it, and the default is “website” - great, until you need to have more than one site and publishing doesn’t clear your site’s output cache. Fortunately it’s easy to configure more sites: just add more site nodes to the XML. You cannot however use config includes to allow each site to individually add itself to the list from its own config file.

There’s also a nuclear option: you can implement your own event handler that clears all sites’ caches. I’m not sure if this would have a detrimental effect on any of the system sites (i.e. shell), but you could exclude it. An example of doing that:

string[] siteNames = Factory.GetSiteNames();
for (int i = 0; i < siteNames.Length; i++)
{
   SiteInfo siteInfo = Factory.GetSiteInfo(siteNames[i]);
   if (siteInfo != null)
   {
        siteInfo.HtmlCache.Clear();
   }
}

Making Visual Studio 2010 Web.config Transformations Apply on Every Build

Disclaimer: This was written about Visual Studio 2010 RC. I suspect the same approach will continue to work with the final release but there are no guarantees.

When I first heard about Web.config transformations in Visual Studio 2010 I was excited. Our build process involves keeping a working build in SVN such that our dev servers may merely check out a working copy and go, and the problem of people committing their own, or the dev server's, web.configs had been a problem. Someone else's settings would come to your machine, causing explosions and other hijinks. Wouldn't it be great, I thought, to have each developer keep a delta for their own web.config settings and apply them only on their box, so not only would the commit problem be solved, we could also keep everyone's personal configs safe in SVN.

My problem was that I assumed the transformations would apply more or less at runtime. Their dirty secret is that they're only applied when you publish the site. We don't use VS publishing ever, as our release process is entirely based around SVN tags. This also kills its utility for the situation of having multiple developers with disparate web.configs being able to maintain individual transformations that apply to their computer only.

Feeling disappointed, I set out to remedy the situation. As I knew this was all handled by MSBuild thanks to Hanselman's talk at MIX10, I went spelunking in the global targets files. I found the definition of the TransformWebConfig target, which I learned about from this blog post, in the C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web\Microsoft.Web.Publishing.targets file. With a little fooling around, I began to understand how it works in its essential nature: the Microsoft.Web.Publishing.Tasks.TransformXml task (defined in an assembly in the same directory as the targets file).

Armed with the knowledge of how the task works by example and Reflector, I set out to try and make it do what I wanted: after a build, apply the correct transformation file and overwrite the Web.config. Since there had to be a source file other than the Web.config to transform on, I settled on "Web.generic.config" as a name for the untransformed config.

It turned out to be quite simple to implement. In my project's .csproj file, there lies at the bottom a commented out section with BeforeBuild and AfterBuild tasks already skeletoned out.

I uncommented the AfterBuild task and added the TransformXml task to it, like so:

<target name="AfterBuild">
    <TransformXml Source="Web.generic.config"
             Transform="$(ProjectConfigTransformFileName)"
             Destination="Web.Config" />
</target>

Voila - after each build, publishing or no, the Web.generic.config has the active solution configuration's transformation applied to it and copied to the Web.config. Note that unlike the version run during publishing, this one only checks the root Web.config. Subdirectories' config files are ignored. Someone better than I with MSBuild could probably remedy that shortcoming :)

I suspect that with the right importation of tasks into your project file, this solution could be made to work against regular old App.config files as well as Web projects, but I don't do enough app development to dive particularly deeply into it.