Reflecting on our HTML conventions

In post 4 years ago, I detailed how we used FubuMVC’s HTML conventions with ASP.NET MVC to simplify building views. While these were extremely helpful early on, they have started to fall apart in recent years. I love the Fubu conventions because unlike the default MVC input builders which only rely on the property type, the Fubu conventions model allows rules to be set based on a large number of factors including the property type, the property’s value, attributes, names, other properties, and configuration data. In the primary codebase I work on today I’ve assembled over 40 rules for building inputs. Unfortunately, our inputs have broken down around our increased usage of Knockout. With Knockout, I find myself building more custom (and less reusable) views which means I’m not taking the time to wire them into the convention setup. There are several other factors at play too:

  • We hired a designer and they need access to the raw HTML to style it.
  • They were not well documented for new devs.
  • Increased dependencies on jquery plugins.
  • Core conventions were stored in a Nuget package, but there was no standard procedure for updating them. Sometimes commits from one project interfered with conventions in other ones.
  • Some of my new projects are in NancyFX but the conventions have a dependency on the Microsoft MVC DLLs.

All combined, this has been a significant source of friction against using and maintaining our conventions. As part of my back to the basics push, I want to revisit our convention framework and find a better way to manage this. My goals for future conventions/best practices include:

  • Easily editable html
  • Easy to nest with divs for styling
  • Support custom ko bindings
  • No mandatory javascript dependencies
  • Each project defines its own conventions
  • Debugging for when conventions go wrong (fubu-debug style)
  • Break dependency on ASP.NET MVC libs

I’ll be sure to post here when we find a better solution.