@this.DataList("countriesList").Options(countries)
@this.TextBox(x => x.Countries).List("countriesList").Autofocus()
@this.SearchBox(x => x.Term).Placeholder("Enter search terms").Novalidate(shouldValidate)
@this.DatePicker(x => x.CompletedDate).Required(true).Limit(minDate, maxDate) //min, max
@this.TimePicker(x => x.StartTime).Limit(TimeSpan.FromHours(10), TimeSpan.FromHours(14), 60) //min, max, step
@this.NumberBox(x => x.CompletedDate).Limit(0, 100, 10) //min, max, step
@this.EmailBox(x => x.Email).Multiple(true).Autocomplete(false)
@this.SubmitButton("Submit").TargetBlank()

The above is just an example. There’s a lot more too. You know of course that a lot of this stuff is not yet supported by many browsers.  But it’s coming, and we wanted to be ready.  It might be some time before this is in the NuGet distro, but you can build the trunk and try it out now.

@inherits MvcContrib.FluentHtml.ModelWebViewPage<MyApp.WebUI.Models.MyModel>

If you decided to put the ModelWebViewPage class into your app directly, of course, adjust the namespace accordingly.  You should also remove any @model directive because the @inherits directive tells the view what the model is.

You probably also want to add this to the namespaces section of your Views web.config file (not the app level web.config):

<add namespace="MvcContrib.FluentHtml"/>

Use the fluent helpers just like you would in an aspx file, except with Razor syntax of course. For example:

@this.TextBox(x => x.FirstName).Id("firstName").Class("someClass").AutoLabel()

Enjoy!

Last spring I revealed my alter-ego as an iPhone app developer when I announced my first iPhone app, Bill It.  Today I am proud to announce that my second iPhone app, Better Do, is for sale in the App Store.  It’s free.  There are ads, which can be turned off for a low price.

Better Do is a To Do list app.  Yeah, I know, another To Do list app?  Aren’t there hundreds of those?  Indeed there are.  But none of them work for me.  There are generally two types of To Do list apps: too-snazzy and too-simple.  The first type promises to totally manage all of your tasks as long as your enter a whole bunch of information, including a fixed due date for each.  The second type is a basic list, maybe with categories, and maybe it lets you re-order tasks.

Better Do assumes that tasks fall into typical time-frames.  When you think of a task, you want to write it down before you forget.  At that moment you don’t care about setting an exact due date, but you do have an idea of the time-frame:

• Today (Go to post office, Reply to Jim)
• Tonight (Call mom, Take out the trash)
• This Weekend (Fix the fence, Holiday shopping)
• Some Day (Learn Japanese)

At the start of a day you might want to review all your tasks and move certain items to Today.  But if you’re like me, as the day unfolds you realize that maybe you were a little…ambitious.  You decide to push certain things.  Now you don’t want those deferred tasks staring you in the face all day, do you?  No problem.  Move them to:

• Tomorrow
• This Week
• Next Week

My favorite thing about Better Do is that it’s very easy to move, sort and generally mange your tasks with minimal taps.

Give it a try, and please rate it or review it.

Should Assertion Library (“Should” for short) is a library of test assertion methods for .NET.  It is totally independent of, and completely compatible with any testing framework.  It was created by Eric Hexter, and I subsequently added a fluent interface which I ported from ShouldIt.  ShouldIt is now deprecated.

Should comes in two flavors:

• normal (Should.dll)
• fluent (Should.Fluent.dll).

Get It

You can get the latest binaries from NuPack or the project site.

By the way, if you haven’t tried NuPack yet, go get it right now!  You’ve got it? Okay, open the Package Management Console and enter:

> Install-Package Should

or

> Install-Package ShouldFluent

This will install Should as a package in the current solution.  You probably want to use either the fluent API or the normal API in any given test project – but not both.  Choosing one or the other will promote a consistent practice within your team.  Obviously, I prefer the fluent API.

Use It

There’s not much to say about usage.  It’s really pretty intuitive and discoverable.  Just start typing “.Should” after your actual object, and you will see what’s available.  To give you a taste, here’s a simple example:

actual.ShouldNotBeNull();
actual.ShouldBeType<Foo>();
actual.ShouldBeSameAs(expected);

Or fluently:

actual
    .Should().Not.Be.Null()
    .Should().Be.OfType<Foo>()
    .Should().Be.SameAs(expected);

There are several examples of both the normal and the fluent syntax here.

Enjoy!

A Note To ShouldIt Users: If you have been using ShouldIt, just remove the ShouldIt DLLs, add Should.Fluent.dll, and change the namespaces.  Everything should just work. Of course depending on which test framework you were using with ShouldIt, the underlying assertion behavior could change slightly. It should be pretty easy to spot the differences and make any small corrections as needed.

Almost a year and a half ago I created ShouldIt.   Soon after I added a fluent API.  My goal was to create a test assertion library that would be portable across all major test frameworks.  This would allow me to move from project to project using the same nice test assertions without the sick feeling I was getting from copy-paste reuse.  So I created the API, sprinkled in a little MEF, stirred, and ShouldIt was born.  It felt really good.

My joy was dampened however by one nagging issue.  Although ShouldIt plugged nicely into any framework I might ever use, it carried with it a binary dependency to some particular version of each testing framework.  This made it really hard to distribute, and thus hard to achieve any kind of adoption.  This is probably why Eric Hexter yawned when I told him about ShouldIt.  He went looking for a better way.

Then Came Should

Recently he found it, and created Should Assertion Library (or “Should” for short) .  Whereas ShouldIt leveraged the assertion machinery of whatever test runner you might be using, Eric created a library with it’s own machinery, thus completely breaking any dependence on a testing framework.  On a side note, I had briefly considered doing this myself with ShouldIt.  I was cured of this notion by perusing the assertion source code in NUnit.  It is, uh, non-trivial.  So how did Eric pull it off?  Is he a more talented and dedicated programmer than I am?  Probably yes, but he did not create it either.  Rather, he forked the assertion machinery of xUnit (with the blessings of the xUnit folks).  Brilliant!

They Get Married

When I saw Should Assertion Library I knew immediately that this was the way to go.  My only complaint was that ItUsedVeryLongPascalCaseNamedAssertionMethods.  Okay, you either love the fluent style of assertions or you hate it.  I love it, and I refuse to go back.  So I decided to see how hard it would be to port ShouldIt’s fluent API bits into Eric’s project.  It turned out to be very easy, so I suggested to Eric that Should Assertion Library might support two styles: fluent and long name.  He agreed, and very soon the Should.Fluent assembly was created.

More: Getting Started With Should Assertion Library.

I have a secret. I have been working on an IPhone app. I am proud to announce that it’s finished and for sale in the App Store. Current price: $4.99. It’s called Bill It.

The Problem

I created Bill It because I needed it myself. I am a consultant, and I use QuickBooks to bill my clients. The edition of QuickBooks that I use comes with a nice time entry feature that makes it pretty easy to bill my clients based on time and materials. But it’s inconvenient to open QuickBooks whenever I want to record my time. But if I wait, I forget, and that’s bad. I have used various mobile apps to capture my time — first on a Palm device, then on my IPhone. But this presents a different problem: double entry. It’s a hassle to transcribe hours from one screen to another, but the real problem is accuracy. Each transcription carries with it a small risk of error. Billing errors are bad.

The Solution

So I created Bill It. Bill It lets me enter my time on the go with no friction. The time is accurate because I enter it when it’s fresh in my mind. When billing time rolls around, it’s a couple of taps to send myself an email with a file attached. I open QuickBooks, and with a few clicks the time is imported. No fear of errors, and very little hassle.

Bill It Lite

A pet peeve of mine is paying for an app that I will never use. Even if it’s only a buck. On the other hand I don’t mind paying a premium price for an app I will use regularly. So I created Bill It Lite, which lets users try out every aspect of Bill It before they pay for it. Another pet peeve is when I try out a lite version only to realize that I must redo a bunch of setup and data entry when I buy the full version. Not with Bill It Lite. Users can buy the full version right in the app. No new app. No redoing setup and data entry.

You might also be interested to know that I developed Bill It using MonoTouch and Catnap.

So far ShouldIt has met that goal, well mostly. One small friction point is the need to reference four DLLs (not counting the testing framework itself) in my test projects. No more. I have added an automated build that ILMerges all the required assemblies. And to make it easy for others to adopt ShouldIt, the download page now has a single file download for each testing framework.

It turns out that FluentHtml’s select helper lets the user express his intent vaguely.  Consider whether this test should pass:

[Test]
public void when_determining_selected_values_select_should_ignore_selected_method_if_any_options_are_marked_selected()
{
    var list = new List<SelectListItem>
    {
        new SelectListItem { Text = "Acura", Value = "1", Selected = true },
        new SelectListItem { Text = "BMW", Value = "2" },
    };

    var select = new Select("foo.Bar").Selected(2).Options(list);

    var optionNodes select.ToString().ShouldHaveHtmlNode("foo_Bar").ShouldHaveChildNodesCount(2);
    optionNodes[0].ShouldBeSelectedOption(1, "Acura");
    optionNodes[1].ShouldBeUnSelectedOption(2, "BMW");
}

See what we have done here? We have allowed the user to express which options should be selected in two, possibly contradictory ways. In the call to Options, the user has specified that Acura should be selected. In the call to Selected, she has specified that BMW should be selected. How should we interpret what she really wants?

The first path to consider is to change the API to remove the chance for vaugeness. In most cases this is highly preferable. In this case, however, the cat is already out of the bag so to speak. That is, changing the API in this way would be a big breaking change.  Furthermore, it is deliberate and I believe very useful that the API offers a lot of ways to specify select options.

That leaves us to invoke the Rule Of Least Surprise. When a user specifies vague intent, in the manner that we have described, I can see five reasonable outcomes:

1. Selected items are only those expressed via Selected
2. Selected items are only those expressed via Options
3. Selected items are a union of those expressed via Selected and Options
4. Selected items are only those expressed via Options or Selected, whichever is called last
5. Selected items are only those expressed via Options unless none, then those expressed via Selected

I will reject #4 out of hand.  FluentHtml helpers are essentially builders.  And with builders, order should never be important.  #1 and #2 are the next to go.  I cannot think of a better argument for either, and so the choice would be arbitrary.  It’s a rather close call between #3 and #5, but I will choose #5.  Here is the thinking.   If the user has specified selected items within the options themselves, then calling Selected is clearly a mistake on his part and he should expect it to be ignored.  On the other hand, if he did not specify selected items within the options list, then he could reasonably expect the call to Selected to be honored.

Would you make a different choice?