The requirement from the customer was fairly straight forward: on a page an editor should be able to choose any number of categories (not the built-in kind). The selectable options should be editable in episerver. Since we’re using EPiServer CMS 6 R2 I thought that this requirement was a good match for the new PropertyCheckBoxList (described in this blog post by David Knipe). This was the first time I worked with the new property settings functionality and while I really like the concept of property settings I still feel that the accessing part is a bit clunky. The accessing might be easier when using PageTypeBuilder 2 but I haven’t tried that.
The requirements change
Anyway, as you can probably guess the requirement changed as the customer discovered that they also needed to have a (lengthy) description associated to each of the selectable options. Since the built-in property I used for storing the data only consisted of a key / value store I tried various approaches like extending the property or storing the description as a custom property setting. None of the approaches seems ideal but since I’ve already invested some time in the solution I felt that I owed it to myself to at least try to, as Tim Gunn would have said, make it work.
Luckily my colleague Oskar bitch slapped me back to reality by simply asking “Why don’t you store the options as pages and simply use an editor for the description?”. But of course.
Sometimes it’s so easy to strive to continue down the wrong path (even when you know it’s the wrong one) simply because you’ve already invested so much in it. Especially if you’re working on your own. This is one of the reasons I value pair programming. Changing my code to use pages as categories instead of the built in property was perhaps not awesome fun but it was the right thing to do. The code ended up being more simple and it’s much easier to extend.